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

At a glance

What this is: Xygeni identifies a malicious npm package whose hidden payload combines device-code phishing, mailbox enumeration and bulk messaging inside versions 1.0.299 through 1.0.307.

Why it matters: It matters because package intake, Microsoft 365 authentication policy and identity telemetry now need to be treated as one control surface when software delivery can hide mailbox-abuse capability.

Context

Npm packages can be more than code dependencies when their install path hides a separate operational payload. In this case, the security problem is not simply malware in a registry entry but the blending of package distribution, OAuth device-code consent and mailbox abuse into one delivery path. For identity and access teams, that means the trust boundary extends from software intake into Microsoft 365 authentication controls and post-authentication monitoring.

The article describes a supply chain delivery mechanism that uses a hidden directory, obfuscated JavaScript and a legitimate Microsoft device-code flow to reach mailbox data. The identity angle is real because the abuse depends on a human approving a code, after which the package can read mail through Graph and use the resulting access for impersonation or reconnaissance.

Key questions

Q: What breaks when an npm package hides its real code behind a clean install hook?

A: The review model breaks because security teams often inspect lifecycle scripts more closely than resolved runtime entry points. If the executable path sits in a hidden, obfuscated directory, the package can look routine during install while still executing malicious code after dependency resolution. That shifts control failure from the hook to the actual entry path.

Q: Why do device-code approvals create risk in Microsoft 365 environments?

A: They let a user complete authentication on a separate device and hand a requester usable tokens without ever exposing a password. If the requester is malicious, the approval event becomes the attack. That is why device-code flow needs policy constraints, strong user awareness and post-sign-in monitoring.

Q: What are the signs that mailbox access is being used for phishing preparation?

A: Watch for successful device-code sign-ins followed quickly by Graph reads of inbox and sent items, especially when the session is unfamiliar or originates from a developer or build host. That sequence suggests the token is being used to map correspondents and prepare impersonation, not just to authenticate normally.

Q: Should teams prioritise package provenance or authentication controls first?

A: They need both, but package provenance comes first when the package itself can trigger identity abuse. In this case, the dependency was the delivery vehicle for a Microsoft 365 consent flow, so the safer order is to block suspicious packages at intake and then harden the authentication path they try to exploit.

Technical breakdown

How the hidden npm payload survives install review

The package separates appearance from execution. package.json points to a harmless-looking postinstall hook, while the real entry point resolves into a dot-prefixed directory whose files are heavily obfuscated. That pattern defeats casual review because the install script appears routine, yet the operational code is only reached through the package's exported main and bin paths. The result is a supply chain control problem, not just a malware scanning problem. Reviewers who inspect only lifecycle hooks can miss the actual runtime path. Practical implication: inspect resolved entry points, hidden directories and obfuscation patterns before allowing a package into build or developer environments.

Practical implication: block packages whose runtime entry resolves into hidden, obfuscated first-party code until the payload is unpacked and reviewed.

Why device-code approval becomes an abuse path

Microsoft's device-code grant is legitimate when a user needs to authenticate on a second device, but it is dangerous when the requester is not the mailbox owner. Once the user approves the code, the requesting application receives tokens that can access Microsoft Graph on that user's behalf. In this package, that means the attacker does not need to steal a password; the human approval is enough to mint usable access. The control weakness is consent granted in the wrong context, not credential cracking. Practical implication: treat device-code sign-ins as a high-risk authentication path and constrain them with policy where interactive use is not required.

Practical implication: constrain device-code authentication with Conditional Access and review every successful device-code sign-in for follow-on mailbox activity.

How mailbox enumeration turns consent into reconnaissance

After token issuance, the package reads inbox and sent items through Graph to extract sender and recipient relationships. That creates a social graph of correspondents that can feed impersonation, targeting and bulk-mail generation. The mail-reading step is not a side effect, it is part of the abuse chain because it gives the operator the raw material for believable follow-on messages. The combination of consented access and mailbox enumeration is what makes this more than simple spamware. Practical implication: monitor Graph access to mailFolders/inbox and mailFolders/sentitems immediately after authentication events that use device-code flow.

Practical implication: alert on Graph reads of inbox and sent items that occur directly after a device-code authentication event.

Threat narrative

Attacker objective: The attacker aims to convert package installation and user approval into mailbox access, impersonation capability and a scalable phishing platform.

1. Entry occurs when a developer or build agent installs the npm package and executes its hidden obfuscated runtime instead of the benign-looking postinstall hook.
2. Credential or token access follows when the malware drives Microsoft 365 device-code authentication and a user approves the code, giving the requester usable access without password theft.
3. Escalation and collection happen when the package uses the resulting Graph token to read inbox and sent items, map correspondents and assemble phishing or impersonation material.
4. Impact comes when the operator can send bulk mail and SMS, impersonate trusted brands and beacon to fixed infrastructure from a package that looked like a normal dependency.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package distribution has become an identity-abuse channel, not just a code-delivery channel. This article shows a malicious registry package using a legitimate OAuth consent flow to reach mailbox data after installation. That collapses the old separation between software supply chain review and identity control, because the dangerous action happens after the package is already trusted enough to run. Practitioners should treat package intake as an authentication-risk decision, not only a software provenance decision.

Device-code consent creates a verification trust gap when the requester is untrusted. The package does not need to steal credentials because it can induce a human to complete the second step of authentication. That makes approval the security boundary, and any environment that allows device-code sign-ins without tight policy inherits the risk of consent-driven token issuance. The control lesson is to govern consent paths, not just passwords.

Mailbox access is being weaponised as a reconnaissance substrate for phishing. Reading inbox and sent items gives attackers relationship data that makes impersonation more believable and more targeted. In identity terms, this is where post-authentication access scope matters: the abuse is not in login alone, but in what the authenticated token can read and reuse. Security teams should align Graph permissions, Conditional Access and mail telemetry around that post-authentication blast radius.

Hidden runtime code is a stronger trust signal than package metadata. A clean-looking install hook did not mean the package was safe, because the true behaviour lived in a hidden directory and obfuscated modules. That is a governance problem for software intake and build systems alike, because static metadata can be staged while the operational path remains concealed. Practitioners should privilege resolved execution paths over declared package intent.

Mail and identity telemetry now need to be correlated at incident triage. Device-code approval followed by Graph reads of inbox and sent items is the operational signature here, and it is more useful than any single indicator in isolation. The named concept is consent-to-mailbox abuse: a consent event that immediately becomes data access and phishing preparation. Teams should build detection around that sequence, not around one alert type in isolation.

From our research library:

• Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.

What this signals

Consent-driven access is now part of the supply chain threat model. When a package can induce a device-code approval, the resulting token scope matters as much as the package hash. Programmes that separate software intake from identity policy will miss the moment where consent becomes mailbox access, so the control plane has to span both.

Consent-to-mailbox abuse: the important pattern here is not password theft but a consent event that immediately turns into mailbox enumeration and message impersonation. That means security teams should anchor detections on authentication followed by sensitive Graph activity, not on login events alone.

For practitioners

• Tighten device-code authentication policy Restrict Microsoft 365 device-code flow wherever interactive use is not required and log every successful approval for review against mailbox access that follows immediately after.
• Block hidden obfuscated runtime paths Treat packages whose main or bin resolves into dot-prefixed, obfuscated directories as high risk and require unpacked code review before promotion into developer or CI environments.
• Hunt for the operator beacon host Search proxy, DNS and endpoint logs for api.nolimitent.xyz on developer workstations and build agents, then quarantine systems that contacted the host while installing the package.
• Correlate Graph reads after approval Flag Graph access to mailFolders/inbox and mailFolders/sentitems when it occurs directly after a device-code sign-in, because that sequence matches mailbox reconnaissance after consent.
• Review package intake as identity risk Add dependency review criteria that consider whether a package can trigger authentication flows, not just whether it ships a malicious script or a suspicious install hook.

Key takeaways

• A malicious npm package can hide real capability behind an apparently routine install path and still execute a full phishing workflow after installation.
• The article shows that Microsoft 365 device-code consent can be abused as a token issuance path, which turns user approval into access rather than just login.
• Teams need to align package review, Conditional Access and Graph telemetry because the risk now spans software provenance and identity abuse at the same time.

Key terms

• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• Consent-driven access: A control model where a machine or partner may access data only within an explicit approved scope. In banking APIs, this replaces credential replay with auditable permissions that can be revoked, reviewed, and limited to the exact data and actions required.
• Hidden payload: Malicious code that is present in a package or application but is kept out of the obvious execution path through obfuscation, nested directories or misleading install hooks. It is designed to survive casual inspection while remaining operational at runtime.
• Mailbox reconnaissance: The post-compromise reading and sorting of email, contacts and directory context to identify financial conversations, trusted relationships and fraud opportunities. In OAuth abuse cases, mailbox reconnaissance often follows token issuance and is a strong indicator that the compromise has become operational.

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 security practitioners connect identity controls to the software supply chain and adjacent access risks.