Npm package nolimit-agent turns device-code phishing into supply chain risk

At a glance

What this is: This is a supply chain abuse case where an npm package concealed a phishing and mail-exfiltration framework that abused Microsoft 365 device-code flow and Graph access.

Why it matters: It matters because software installation, identity verification, and mailbox access are now part of the same attack surface, so IAM and NHI teams must treat package trust as identity risk.

By the numbers:

• The package line spanned versions 1.0.299 through 1.0.307, released over four days from 2026-06-26 to 2026-06-29.
• The hidden module set contained roughly 4,293 encoded-payload spans across the .ad directory.
• The package’s main entry resolved to .ad/x0.js, one of about 86 files in the hidden directory.

👉 Read Xygeni's analysis of the nolimit-agent npm supply chain attack

Context

Npm supply chain abuse is no longer limited to credential theft from developer environments. When a package hides operational code behind a clean install hook and then pivots into identity-controlled workflows such as Microsoft 365 device-code approval, the compromise path moves from code execution into mailbox access and impersonation.

In this case, the key governance problem is trust separation. Developers expect package installation to load code, not to open a phishing framework that can harvest mail, send bulk messages, and fingerprint infrastructure. The identity bridge is direct: the package does not merely run on a workstation, it tries to turn a user-approved device code into delegated mailbox access, which is a familiar NHI-style abuse pattern in a new delivery channel.

For IAM and NHI programmes, this is a supply chain event with identity consequences rather than a pure malware story. The starting position, where package trust is treated separately from authentication risk, is increasingly atypical.

Key questions

Q: How should security teams handle package installs that can trigger identity flows?

A: Treat any package that can initiate OAuth, SSO, or device-code flows as a potential identity control boundary, not just a software artifact. Require provenance review, runtime entry-point inspection, and telemetry that links installation activity to authentication events. If the package can request delegated access, it should be assessed like an untrusted service integration, not a routine dependency.

Q: Why do device-code approvals create risk when the requester is untrusted?

A: Device-code flow shifts trust from a password to user approval, which is useful for constrained devices but dangerous when the requester is malicious. A user can approve access without understanding the downstream scope, and the resulting token may allow mailbox or data access that looks legitimate in logs. The risk is consent laundering, not brute-force compromise.

Q: What breaks when package metadata does not reflect the real runtime path?

A: Security review becomes misleading because install hooks, readme text, and visible files can look harmless while the actual code executes elsewhere. That breaks assumptions in dependency scanning, code review, and supply chain approval. Teams need to inspect hidden directories, obfuscation patterns, and exported entry points before they trust the package as low risk.

Q: Who is accountable when delegated mailbox access is abused through a third-party package?

A: Accountability usually spans software supply chain owners, identity platform teams, and the business owner that approved the application or workflow. If device-code access or Graph permissions were not constrained, the identity team owns the control gap. If the package was approved without provenance review, the software governance process also failed.

Technical breakdown

Hidden package structure and obfuscated runtime code

The package separates what reviewers see from what actually executes. A harmless-looking postinstall hook installs a Windows shim and exits, while the real logic sits in a dot-prefixed .ad directory referenced by main and bin fields. That structure reduces casual inspection, especially when the module set is dominated by obfuscated string-array blobs produced with javascript-obfuscator. In practical terms, the code path is designed to evade a quick registry skim and defer malicious behavior until runtime entry points are invoked.

Practical implication: Treat hidden first-party execution paths and dense obfuscation as review failures, even if the install hook appears benign.

Microsoft 365 device-code flow as delegated access abuse

The most important mechanism is device-code phishing by consent. A service requests a code from Microsoft, the user enters it on a second device, and the service receives tokens if approval succeeds. That flow is legitimate when the user is interacting with their own service, but it becomes an abuse path when an attacker-controlled package gets the code approved. Once tokens exist, Graph can be queried for inbox and sent items, which turns a one-time approval into delegated mailbox access.

Practical implication: Restrict device-code authentication where it is not required and monitor for sign-ins followed by immediate mailbox enumeration.

Mail delivery, impersonation, and reconnaissance inside one framework

The package combines reconnaissance and delivery rather than relying on a separate phishing kit. It queries DNS, WHOIS, GitHub code search, and archived web data to find plausible relay infrastructure, then uses SMTP and SMS engines with sender templates and URL-ambiguation tricks such as trusted-looking authority strings before an @ symbol. This is operationally important because it links targeting, delivery, and mailbox abuse into one package lifecycle instead of three distinct tools.

Practical implication: Correlate package install events with outbound C2, mail-gateway anomalies, and identity logs to spot multi-stage abuse earlier.

Threat narrative

Attacker objective: The objective is to weaponise package installation into mailbox access, impersonation, and phishing at scale while preserving operator control of the delivery channel.

1. Entry occurs when a developer or CI system installs the npm package and loads the hidden .ad payload instead of the clean-looking hook.
2. Escalation occurs when the framework solicits Microsoft 365 device-code approval and converts that approval into Graph tokens for mailbox access.
3. Impact occurs when the package reads inbox and sent items, sends bulk mail or SMS through operator-controlled relays, and beacons to fixed infrastructure for continued abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply chain trust is now an identity control surface: packages that conceal phishing logic inside runtime code are no longer only malware risks. They can become a path into OAuth approval, delegated mailbox access, and downstream impersonation. For IAM teams, that means registry trust and identity governance now overlap, especially where developer tooling can trigger authentication flows on behalf of a user. The practitioner conclusion is simple: dependency review must account for identity abuse potential, not just code safety.

Device-code approval is a weak boundary when the requesting party is untrusted: the flow was designed for constrained devices, but in adversary hands it becomes a consent laundering mechanism. This package shows why approval-based delegation needs tighter contextual controls, better sign-in telemetry, and clearer user assurance about who is requesting access. The specific governance gap is not token strength, but trust in the requester. Teams should treat delegated approval as a privileged event, not a routine login.

Hidden execution paths create governance debt for security review teams: a benign install hook can coexist with a concealed operational module set, which breaks the assumption that package metadata and first-run behavior tell the same story. That gap is especially relevant for NHI governance because hidden automation can still interact with OAuth, SMTP, and Graph as if it were a legitimate service account. The field should recognise this as package-level identity masquerading, and review workflows should inspect runtime entry points, not only install scripts.

Mailbox access is becoming a post-install privilege escalation path: the package does not need password theft if it can persuade a user to approve a device code and then enumerate inbox and sent items through Graph. That shifts the security question from credential secrecy to delegated scope, session context, and auditability. Practitioners should conclude that mailbox telemetry, Conditional Access, and dependency control must be linked in one governance model, not run as separate programmes.

Machine identity patterns are appearing in human workflows: this is not a classic service account breach, but it behaves like one once the package acquires delegated tokens and performs automated mailbox actions. That crossover matters because it shows how non-human behaviors can emerge from software distribution channels that IAM teams often treat as unrelated. The practitioner takeaway is to extend NHI-style monitoring to any software path that can obtain and reuse delegated access.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Secrets exposure and immediate abuse are already operationalised by attackers, which is why leaked credential windows should be measured in minutes rather than days.
• The same speed logic applies to identity abuse in software supply chains, so teams should pair The State of Secrets in AppSec with dependency telemetry and Graph sign-in monitoring.

What this signals

Consent-based identity abuse is moving into software delivery channels: the practical lesson is that authentication controls can no longer stop at the identity provider. When packages can trigger device-code approval and then act on delegated tokens, programme owners need shared monitoring across IAM, software supply chain, and mail security. That is a governance shift, not just a detection problem.

Package provenance now needs the same scrutiny as secret provenance: hidden entry points, obfuscation, and external call-home domains are indicators that a dependency may be carrying runtime behaviour unrelated to its stated purpose. For teams using NHI-style governance, the important next step is to align dependency review with access telemetry, because code trust and identity trust are converging.

The control story is not just about blocking a bad package. It is about reducing the time between installation, delegated approval, and mailbox access so that suspicious sequences are visible before the attacker can use them.

For practitioners

• Restrict device-code authentication where it is not operationally required Apply Conditional Access and sign-in policies to block or challenge device-code flows for user populations and environments that do not need them, especially developer and build contexts.
• Inspect packages with hidden runtime entry points Flag npm packages whose main or bin fields resolve into dot-prefixed directories, especially when those directories contain dense obfuscation or code-decoding patterns.
• Correlate device-code sign-ins with mailbox enumeration Alert when a successful device-code sign-in is followed quickly by Graph reads of inbox and sent items, because that sequence indicates delegated mailbox abuse.
• Block known operator infrastructure and hunt for it in logs Add api.nolimitent.xyz to network controls and search DNS, proxy, and build logs for outbound access from developer systems and CI agents.
• Review package trust as part of identity governance Include dependency provenance, runtime entry paths, and delegated-access abuse indicators in software approval workflows so package review is not separated from identity risk review.

Key takeaways

• This package turns npm installation into a delivery path for phishing, mailbox access, and impersonation, which makes supply chain review an identity governance problem.
• The most dangerous mechanism is not classic credential theft but device-code consent abuse followed by Graph mailbox enumeration and outbound messaging.
• Teams should connect dependency provenance, Conditional Access, and mailbox telemetry so delegated access abuse is detected as a single attack path.

Key terms

• Device Code Flow: A device code flow is an OAuth pattern for clients that cannot host a browser. The application gets a user code and polling credential, while the user completes login in a separate browser session. In CLI contexts, it shifts risk into token handling and session boundary control.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Hidden execution path: Code that is not visible in the obvious install or entry files but executes through alternate directories, obfuscated modules, or runtime loaders. Hidden execution paths complicate code review because the security-relevant behavior is separated from the surface that reviewers are most likely to inspect.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

What's in the full analysis

Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:

• The package layout, hidden directory structure, and file-level indicators that reveal the malicious runtime path.
• The Microsoft 365 device-code and Graph sequence used to turn user approval into mailbox access.
• The operator infrastructure, URL-spoof patterns, and reconnaissance routines that support delivery and impersonation.
• The indicator list and hunting guidance needed for npm, proxy, DNS, and Microsoft 365 telemetry.

👉 Xygeni's full post covers the obfuscated package structure, device-code abuse, and hunt indicators in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that must govern delegated access and runtime abuse.