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.
NHIMG editorial — based on content published by Xygeni: analysis of a runtime-decrypted npm infostealer campaign
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Harden dependency intake with runtime-aware inspection Add behavioural analysis for packages that use encryption, dynamic evaluation, or VM execution.
- Scope secret inventory beyond vaults Include browser credential stores, application caches, session tokens, and developer workstation secrets in your discovery and remediation workflow.
- 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.
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
👉 Read Xygeni's analysis of the runtime-decrypted npm infostealer campaign →
Runtime-decrypted npm malware: what it means for supply chain controls?
Explore further
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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime-decrypted npm infostealers expose the trust gap in supply chain