Runtime-decrypted npm infostealers expose the trust gap in supply chain

At a glance

What this is: Xygeni says malicious npm packages consolelofy and selfbot-lofy conceal an AES-encrypted payload that decrypts only at runtime, letting the stealer evade static package inspection.

Why it matters: This matters because dependency trust now extends beyond install-time checks into runtime behaviour, which directly affects supply chain controls, secrets exposure, and the security of developer and machine credentials.

Context

Runtime-decrypted malware is code that stays opaque until the package is imported and executed, so conventional source review and string-based scanners only see the loader, not the real payload. In supply chain terms, that shifts the control problem from package approval to behavioural trust in execution paths, which is where identity and credential risks start to surface.

The article is centred on a software supply chain gap, but it intersects with identity security because the payload targets authentication tokens, browser credential stores, wallet secrets, and a desktop session used for persistence. That is a classic example of why secret exposure and non-human credential governance cannot be treated as separate from package integrity.

Key questions

Q: What breaks when npm packages hide malicious logic until runtime?

A: Source review and install-time scanning lose most of their value because the harmful behaviour is not visible until the dependency is imported and decrypted. Security teams need runtime behavioural detection, execution tracing, and package provenance controls to catch code that looks benign on disk but becomes hostile in memory.

Q: Why do runtime-decrypted packages create more risk for credentials and sessions?

A: They let an apparently normal dependency turn into a secret harvester only after trust has already been granted. That matters because browser credentials, API tokens and desktop sessions can be stolen without exploiting the application itself, which makes dependency trust a direct identity-security issue.

Q: What do organisations get wrong about npm supply chain attacks?

A: They often focus on package provenance while underestimating runtime behaviour and local secret exposure. A malicious dependency is dangerous because it executes inside a trusted identity context and can read whatever that context already stores. Governance has to cover execution, storage, and revocation together.

Q: What should teams do when a package modifies a trusted desktop client?

A: Treat that as a persistence and containment problem, not just a package removal task. Rebuild trust in the affected endpoint, verify the client binaries and configuration, invalidate any tokens or sessions that may have been exposed, and assume the attacker may still control access through the modified application.

Technical breakdown

Runtime decryption hides malicious logic from static inspection

The core trick is simple: ship a small loader and keep the malicious body encrypted until execution. In this case, the package uses AES-256-CBC with a SHA-256-derived key, then feeds the decrypted JavaScript into a Node.js VM. Static scanners that search for obvious strings, URLs, or credential-stealing functions never see the payload in repository form, because the code only exists in memory after decryption. That is not just obfuscation. It is deliberate removal of the malicious logic from pre-execution visibility. The control gap is therefore behavioural, not syntactic. Practical implication: package review must include runtime-aware analysis, not just source-tree inspection.

Practical implication: evaluate dependencies for encrypted loaders and dynamic execution paths, not only for suspicious text or lifecycle scripts.

Dynamic VM execution turns a library import into a runtime event

vm.runInNewContext() is not inherently malicious, but in this pattern it becomes the execution trampoline for concealed code. The sandbox still exposes require, process, Buffer, timers, module and exports, which means the decrypted payload can spawn processes, read files and make network calls with normal Node.js capabilities. That matters because the trust boundary has already been crossed when the module is imported, so install-time controls are too early and source-code controls are too shallow. The real risk is that a package can look inert until a caller exercises it. Practical implication: treat dynamic execution in dependencies as a high-risk behaviour and inspect what runtime primitives are passed through.

Practical implication: flag any dependency that combines decryption with VM execution and full access to runtime primitives.

Credential theft and persistence follow compromise of the trusted workstation

Once decrypted, the payload targets Discord tokens, browser credential stores, wallet extensions and desktop sessions, then attempts persistence by modifying the local Discord client. That is a supply chain attack that moves quickly from code execution to identity abuse, because stolen tokens and session data let the attacker act as the user without needing fresh authentication. The persistence step matters because it keeps producing new tokens even after the package is removed. In other words, the malware does not just harvest secrets, it converts the workstation into an ongoing identity compromise point. Practical implication: assume credential theft may outlive package removal if local applications were modified.

Practical implication: investigate whether the dependency touched local application files or session material, not just whether the package was uninstalled.

Threat narrative

Attacker objective: The attacker aims to steal reusable credentials and wallet secrets while maintaining persistent access through a compromised desktop application.

1. Entry occurs when a developer installs or imports a seemingly legitimate npm package that contains an encrypted loader rather than visible malware.
2. Credential access begins after the loader decrypts the hidden payload, which then harvests browser secrets, Discord tokens and wallet material from the host.
3. Escalation and persistence follow when the payload modifies the local Discord client so future sessions continue leaking authentication material even after the package is removed.
4. Impact is the theft and reuse of sessions, credentials and wallet secrets, giving the attacker durable access to the victim's accounts and crypto assets.

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

Runtime-decrypted dependencies create a trust gap that static controls cannot close. If the malicious body only appears after import, then package approval, grep-based scanning and install-time checks are all looking at the wrong layer. The control problem becomes behavioural inspection of code after decryption, which is a different governance model entirely. Practitioners should treat runtime transparency as part of software supply chain assurance, not as an optional detection enhancement.

Identity exposure is now a supply chain outcome, not just an IAM misconfiguration. This campaign is valuable because it converts a package compromise into token theft, session hijacking and wallet access, which means machine credentials and user credentials fail together when trust in a dependency is misplaced. That is the kind of cross-domain convergence NHI teams should watch closely. The practical lesson is that secret governance must assume code paths can become credential harvesters.

Application-level persistence is a more durable failure mode than package removal. Once the malware modifies a trusted desktop client, simply deleting the dependency does not restore assurance. The governance gap is persistence inside the application layer, where ordinary software inventory tools may not look for tampering. Practitioners should therefore treat post-execution client modification as a separate containment problem, not as a routine cleanup task.

Encrypted loaders should be treated as an indicator of concealment, not just sophistication. Security teams often overvalue package metadata and underweight execution patterns, but a library that ships a large encrypted payload and immediately invokes dynamic execution is telling you that visibility is part of the attack surface. That pattern belongs in supply chain risk scoring and in code review escalation paths. The right conclusion is to inspect for behaviour that exists only at runtime, because that is where the compromise actually lives.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

Runtime transparency is becoming a prerequisite for software supply chain trust. The important shift in cases like this is that package approval alone no longer tells you whether the dependency is safe to execute. Teams need to evaluate what code becomes visible only after import, because that is where credential theft and application tampering now hide. The right control posture is behavioural before it is static.

Secret governance and dependency governance are converging. When a package is built to steal browser tokens, wallet material and desktop sessions, the line between supply chain security and identity security disappears. That means NHI and IAM teams should treat developer endpoints, session tokens and local application state as part of the same risk surface, not separate programmes.

Identity discovery remains weak enough to leave machine and service accounts exposed. Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. Runtime malware that hunts for reusable secrets only becomes more dangerous when the estate itself is poorly inventoried.

For practitioners

• Inspect for encrypted loaders in dependency code Prioritise packages that combine large ciphertext blobs, key derivation and immediate runtime decryption in the entry path. Those features are stronger warning signs than suspicious strings alone because they indicate the malware is hiding until execution.
• Block dynamic execution in untrusted packages Review any dependency that uses vm.runInNewContext(), eval-like flows or similar runtime execution primitives, especially when those calls receive require, process or filesystem access.
• Hunt for post-import credential access behaviour Look for Node-based packages that trigger browser secret access, DPAPI use, token validation or wallet directory enumeration after import rather than during installation.
• Check for client tampering after dependency execution Validate whether desktop applications such as Discord had local file replacements, injected scripts or unexpected webhook logic written into installed client directories.

Key takeaways

• Runtime-decrypted npm packages shift the detection problem from source inspection to behaviour at execution time, which is where hidden payloads become visible.
• The campaign is more than malware delivery because it connects package trust failures to token theft, browser credential access and desktop persistence.
• The most relevant control question is whether teams can spot concealed execution paths and isolate local application tampering before stolen sessions are reused.

Key terms

• Runtime Decryption: Runtime decryption is a technique where malicious code is stored in encrypted form and only becomes readable when a program executes. It reduces static visibility and forces defenders to observe behaviour in memory, where traditional source scanning often cannot see the true intent.
• Execution Trampoline: An execution trampoline is a wrapper that passes control to another payload while preserving enough runtime capability for that payload to act. In Node.js malware, this often means dynamic evaluation with access to process, require, or module, which turns a small loader into a launch point for broader abuse.
• Post-Import Credential Access: A pattern where a dependency does not steal secrets during installation, but only after the package is imported and allowed to execute. This matters because the attack hides behind ordinary application behaviour and can target tokens, sessions and local secret stores after trust has already been granted.
• Application-Level Persistence: Application-level persistence occurs when malware modifies a trusted client or application so it survives beyond the original infection vector. Unlike a simple dropped file, this approach can keep leaking credentials after package removal and often requires file integrity checks to detect and remove.

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 supply chain and runtime risks their programmes now face.