TL;DR: Malicious npm packages consolelofy and selfbot-lofy hide a 216KB AES-encrypted payload that only becomes visible at runtime, bypassing static inspection and enabling credential theft, wallet targeting, and Discord persistence, according to Xygeni. The pattern shows why dependency trust assumptions now need behavioural analysis, not just install-time scanning.
At a glance
What this is: This is an analysis of an npm infostealer campaign that hides its payload until runtime, then steals credentials, wallet data, and Discord sessions.
Why it matters: It matters because software supply chain governance now has to account for encrypted payloads, runtime execution, and application-level persistence, not just package installation risk.
By the numbers:
👉 Read Xygeni's analysis of the runtime-decrypted npm infostealer campaign
Context
This npm infostealer case is a supply chain governance problem before it is a malware story. A package can look routine at install time and still execute hostile logic only after import, which defeats controls that rely on lifecycle hooks, string scanning, or manual review of visible source.
The identity angle is direct because the payload targets secrets, session tokens, browser credential stores, and application persistence paths. In practice, that means non-human identity material such as tokens and application credentials can be harvested through the software delivery chain, while the compromise then spreads into human accounts and downstream sessions.
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 developer secrets make supply chain incidents much harder to contain?
A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.
Q: What do security teams get wrong about sandbox evasion in malware?
A: They often treat evasion as a sign that a sample is harmless if it fails in the lab. In reality, sandbox and VM checks are proof the malware is trying to protect its payload from analysis. Teams should use those checks as detection signals and hunt for the same behaviour on enterprise endpoints.
Q: How should teams respond when a developer endpoint may have been exposed to npm malware?
A: Revoke likely stolen sessions, rotate any affected tokens or API keys, and inspect local application files for persistence mechanisms before the endpoint returns to service. Package removal is only the first step, because the malware may have modified trusted clients or left credentials outside the package itself.
Technical breakdown
Runtime decryption inside npm packages
The core trick here is to move malicious code out of plaintext and into ciphertext until the package is executed. A loader derives an AES key, decrypts the payload in memory, and runs it through vm.runInNewContext(). That means static tools may only see a decryptor, not the stealer logic. The security problem is not encryption itself, but using encryption to hide intent until execution time, especially in a dependency that users assume is inert.
Practical implication: inspect dependency behaviour at runtime, not just source text or install scripts.
Dynamic execution as an execution trampoline
vm.runInNewContext() is not a sandbox in any meaningful defensive sense when the caller passes through require, process, Buffer, and module. Those primitives allow file access, process spawning, and network activity from inside the decrypted payload. In other words, the VM becomes an execution trampoline that preserves most Node.js capabilities while obscuring the attack surface. That is why behavioural correlation matters more than signature matching in this pattern.
Practical implication: flag dependencies that combine dynamic evaluation with access to privileged runtime objects.
Persistence through application-level modification
The post-infection stage is more worrying than the initial theft because the malware modifies Discord client files to persist outside package removal. By overwriting application internals, the attacker can keep harvesting tokens even after the original npm package is deleted. This is a supply chain compromise that crosses from package abuse into local application tampering, which raises the containment bar for endpoint and identity teams alike.
Practical implication: include application-file integrity checks in incident response for developer workstations and build hosts.
Threat narrative
Attacker objective: The attacker wants durable access to high-value credentials and sessions that can be monetised through account takeover, token abuse, and wallet theft.
- Entry occurs when a developer imports a malicious npm dependency that contains an encrypted payload rather than visible stealer logic.
- Credential access begins after runtime decryption, when the payload extracts browser stores, Discord tokens, wallet data, and DPAPI-protected secrets.
- Escalation and persistence follow when the malware modifies the local Discord client so future sessions continue leaking authentication material.
- Impact is credential resale, account takeover, wallet theft, and long-lived compromise of trusted developer endpoints and sessions.
NHI Mgmt Group analysis
Encrypted runtime payloads create a visibility gap that traditional package scanning cannot close. The important issue is not whether code is obfuscated, but whether security teams can see what a dependency does once it is imported and decrypted. Static analysis, install hooks, and filename heuristics all fail when the malicious body only appears in memory. The category needs behavioural control points that cover runtime execution as well as package publication.
Secrets exposure in developer tooling is now a software supply chain problem, not just a secrets management problem. This campaign targets browser stores, Discord sessions, wallet extensions, and application-level persistence, which means the stolen material spans both human and non-human identities. In identity terms, the trust boundary has moved from the repository to the runtime session, and that demands lifecycle controls over tokens and credentials that live inside developer endpoints.
Runtime execution trampoline: the named failure mode here is code that hides in encrypted form until the dependency is imported. That pattern defeats the assumption that open-source packages are safe to inspect once at install time. The practical conclusion is that code provenance, dynamic analysis, and dependency policy must be aligned before teams treat a package as trusted.
Application-level persistence is a stronger signal of supply chain compromise than simple credential theft. When malware alters a trusted desktop client, removing the package is no longer enough to remove the impact. This shifts the response from package hygiene to endpoint containment, file integrity review, and session revocation, which is exactly where identity and endpoint governance intersect.
For identity programmes, the attack shows why session tokens and API secrets need the same lifecycle discipline as passwords. A credential that can be extracted from a browser store or application cache is still an identity control failure, even if no human typed a password. Teams that separate secrets governance from identity governance are leaving a practical gap in their threat model.
What this signals
Runtime-decrypted npm malware is a reminder that dependency governance now extends into execution, not just publication. Teams should expect more packages to hide intent until import time, which makes behavioural telemetry and file integrity monitoring more valuable than string-based detection alone. Pair dependency controls with the NIST SP 800-53 Rev 5 Security and Privacy Controls families for integrity, audit, and access control.
Secrets sprawl across developer tooling remains the practical weakness attackers exploit most often. When credentials live in browsers, desktop clients, caches, and CI workstations, a single infostealer can convert local compromise into enterprise-wide identity exposure. The remediation gap documented in The State of Secrets in AppSec is a warning that inventory, rotation, and revocation still need more operational discipline.
NHI governance has to include the identity material that application code can steal and reuse. That means session tokens, API keys, and service credentials need lifecycle ownership, not just storage. Teams that want a stronger baseline should align package review, endpoint containment, and secret rotation with the NHI Lifecycle Management Guide.
For practitioners
- Harden dependency intake with runtime-aware inspection Add behavioural analysis for packages that use encryption, dynamic evaluation, or VM execution. Treat a dependency that imports cleanly but decrypts code at runtime as higher risk than a package with visible suspicious strings.
- Scope secret inventory beyond vaults Include browser credential stores, application caches, session tokens, and developer workstation secrets in your discovery and remediation workflow. These locations are common targets in supply chain infostealers and are often outside formal vault governance.
- Revoke and re-issue exposed sessions immediately If a developer endpoint or build host is suspected, invalidate Discord-style tokens, browser sessions, API keys, and other credentials that may have been harvested. Do not rely on package removal alone because application-level persistence may survive.
- Add file integrity monitoring for trusted clients Watch for modifications to local application internals such as desktop client core files, especially on engineering endpoints. A package that tampers with installed software has crossed from dependency abuse into endpoint persistence.
Key takeaways
- This campaign shows that an npm package can conceal malicious behaviour until runtime, which defeats static review and install-only controls.
- The most exposed assets are secrets and sessions, not just source code, and that turns developer endpoints into identity compromise points.
- Behavioural detection, token revocation, and file integrity monitoring are the controls that matter most when malware persists inside trusted applications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Encrypted npm payloads and token theft map to core NHI visibility and credential controls. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0003 , Persistence | The campaign steals credentials and persists by modifying trusted client software. |
| NIST CSF 2.0 | PR.AC-4 | The issue is identity material abuse through weak control of access and secrets. |
| NIST SP 800-53 Rev 5 | IA-5 | Secrets and authenticators are directly targeted for theft and reuse. |
| CIS Controls v8 | CIS-5 , Account Management | Credential theft and persistence both depend on poor account and secret lifecycle control. |
Review account lifecycle controls and remove stale tokens from developer and application environments.
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.
- 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.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
What's in the full article
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- The decrypted payload structure and execution flow inside the malicious npm packages
- The specific credential, wallet, and session targets mapped to each malware wave
- The host and network indicators that help analysts distinguish this campaign from ordinary package behaviour
- The detection logic used to correlate encryption, runtime execution, and application tampering
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives security and identity teams a common baseline for reducing credential exposure across modern environments.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org