Topic starter
20/08/2026 6:06 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “New npm Infostealer Discovery: Nyx Stealer Hijacks Discord 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.
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.
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.
Practitioner guidance
- Inspect for encrypted loaders in dependency code Prioritise packages that combine large ciphertext blobs, key derivation and immediate runtime decryption in the entry path.
- 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.
Bottom line: Runtime-decrypted npm packages shift the detection problem from source inspection to behaviour at execution time, which is where hidden payloads become visible.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:41 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Runtime-decrypted npm infostealers expose the trust gap in supply chain