Malicious npm packages show how supply chain malware hides in plain sight

At a glance

What this is: Veracode found 54 malicious npm packages that beaconed to C2 via an Ethereum smart contract and used anti-analysis checks plus COM hijacking to persist on Windows systems.

Why it matters: This matters because package vetting alone is not enough when supply chain malware blends registry abuse, hidden infrastructure, and persistence techniques that bypass conventional review and sandboxing.

Context

Malicious open-source packages are a supply chain problem because the trust boundary is the package ecosystem, not just the code a developer writes. Once a package is published, installed, and executed in build or endpoint environments, attackers can use the normal software delivery path as a delivery mechanism for malware.

This campaign sits at the intersection of supply chain security, endpoint evasion, and identity-adjacent persistence because it abuses the package layer to reach Windows hosts and then survives through registry-based COM hijacking. The starting position is increasingly typical for modern open-source abuse: low-friction publication, high-friction detection.

The practical governance problem is that package reputation, malware analysis, and runtime control are often owned by different teams. That separation leaves a gap between what enters the pipeline, what gets executed, and what persists after execution begins.

Key questions

Q: What breaks when malicious npm packages are allowed to run on developer endpoints?

A: They can turn install-time trust into code execution, then harvest browser-stored secrets, cloud tokens, and local credentials before defenders detect the compromise. The problem is not only malware delivery. It is that development endpoints often already hold identities and secrets that let an attacker move from package execution to account abuse quickly.

Q: Why do DNS gating and environment checks make supply chain malware harder to detect?

A: DNS gating lets attackers limit execution to selected networks, while environment checks help the payload stay quiet elsewhere. That reduces noise, frustrates broad detections, and can make sandboxing miss the malicious path. Defenders should watch for failed resolution attempts, suspicious conditional execution, and domain lookups that appear tied to internal infrastructure.

Q: What are the signs that an npm package is trying to persist on Windows?

A: Look for unexpected registry writes, CLSID and InprocServer32 changes, native module loading from JavaScript, and repeated beaconing after installation. Those signals indicate the package is doing more than importing libraries and may be establishing a durable execution path.

Q: How should teams respond when a trusted software package may have been used to deploy malware?

A: Teams should respond as if the software package may have established an attacker foothold across multiple systems. That means isolating affected assets, preserving evidence, reviewing network telemetry, and checking for persistence mechanisms and credential exposure. Response should extend beyond the application itself to dependent hosts, identities, and monitoring coverage across the environment.

Technical breakdown

Ethereum smart contracts as dead-drop C2 discovery

A dead-drop resolver stores the current command-and-control location in an external system, then reads it at runtime instead of hardcoding the destination into the malware. In this case, the URL sat in an Ethereum smart contract, which makes takedown harder because defenders have to remove or alter the reference point rather than just block one IP address. That also gives the operator flexibility to change infrastructure without republishing the package. The result is a moving control plane hidden behind a normal blockchain object rather than a static server name.

Practical implication: defenders should treat externalised C2 lookups as part of package risk review, not just network detection.

Environment fingerprinting and Windows-only anti-analysis checks

Malware frequently checks host characteristics before activating to avoid sandbox or analyst environments. Here, the sample fingerprinted system details and specifically looked for Windows systems with five or more CPUs, which suggests the campaign tried to distinguish realistic endpoints from analysis tooling. This matters because modern malware does not need to be highly complex to be evasive; it only needs enough branching logic to delay or suppress payload delivery when it detects scrutiny. That behaviour reduces the visibility of static scanning and low-fidelity detonations.

Practical implication: run package samples in realistic endpoint profiles, not generic sandboxes, when validating suspicious open-source artefacts.

COM hijacking and native module loading for persistence

COM hijacking abuses Windows component registration so a malicious DLL or module is loaded in place of a legitimate COM server. In this campaign, the first-stage JavaScript payload loaded a native node module and used asynchronous procedure calls to trigger the second stage, which links application-level execution to a system-level persistence path. That combination matters because the attacker is not just seeking code execution once. They are creating a repeatable launch path that survives ordinary application restart assumptions and can blend into normal registry-driven behaviour.

Practical implication: monitor registry-based COM paths and native module loading together when investigating suspected package compromise.

Threat narrative

Attacker objective: The likely objective is to maintain covert execution on Windows endpoints long enough to deliver a second-stage payload for theft or mining.

1. Entry occurs when developers or build systems install malicious npm packages that appear legitimate enough to pass initial trust checks.
2. Credential or infrastructure access is not the main objective here; instead the malware reaches Windows hosts and resolves its C2 location through an Ethereum smart contract.
3. Escalation and persistence follow through environment fingerprinting, a native module loader and COM hijacking that help the payload survive and execute repeatedly.
4. Impact is likely covert payload delivery for theft or mining activity, with the exact second-stage behaviour still hidden behind dormant infrastructure.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet: North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

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

Open-source package abuse is now a supply chain persistence problem, not just a malware problem. The important signal in this campaign is not only that malicious packages were published, but that the malware used blockchain-based C2 discovery and Windows persistence techniques to survive ordinary review. That shifts the governance question from package approval to runtime containment and post-install behaviour. Practitioners should treat package intake, execution control, and persistence monitoring as one linked control surface.

Package trust decisions are too often made before the most dangerous behaviour appears. A package can look low-risk at publish time and only reveal its true intent after installation, environment checks, and stage-two resolution. That creates a verification gap for software supply chain programmes that focus on metadata, signatures, or naming patterns alone. Practitioners need to evaluate what a package does after execution starts, not just what it claims to be.

Environment fingerprinting is becoming a standard evasion layer in commodity malware. The Windows-only checks in this campaign show that attackers now expect analysts to detonate suspicious packages in controlled environments and design around that. That does not make sandboxing useless, but it does mean low-fidelity detonation is no longer enough as a primary decision point. Practitioners should assume adversaries are shaping payload behaviour around detection conditions.

Hidden C2 resolution is the key named concept here. By placing command-and-control discovery in an Ethereum smart contract, the operator reduced dependency on a fixed infrastructure footprint and made takedown slower and noisier. That pattern matters beyond this case because defenders often still think in terms of blocking domains and IPs, while attackers are increasingly externalising the control plane. Practitioners should extend threat hunting to non-traditional infrastructure references inside packages and scripts.

What this signals

Hidden control planes are now part of software supply chain risk. When malware can externalise C2 discovery into a blockchain object, the defender’s problem is no longer just domain blocking. The programme implication is that supply chain monitoring has to include runtime resolution paths, not only package provenance or static reputation checks.

Package governance and endpoint monitoring are converging. If the intake control does not inspect behaviour after install, a malicious package can still turn into a persistence foothold on Windows hosts and bypass the assumptions behind ordinary software approval.

Environment fingerprinting is the new low-cost evasion layer. Security teams should expect adversaries to tune payloads to sandbox conditions, which means validation needs realistic endpoint profiles and stronger post-install telemetry.

For practitioners

• Inspect package behaviour after installation Detonate suspicious npm packages in an isolated environment and review whether they resolve external infrastructure, fingerprint the host, or load native modules before approving them for use.
• Block malicious packages at the intake layer Use package firewalling or equivalent allow and deny controls to prevent newly identified malicious packages from entering build and developer environments.
• Monitor for COM hijacking persistence Hunt for registry changes under CLSID InprocServer32 paths and pair that with alerts on unexpected native module loading from JavaScript runtimes.
• Treat externalised C2 references as indicators Search package sources and unpacked artifacts for blockchain contracts, disposable URLs, and other dead-drop resolver patterns that separate malware logic from the live C2 location.

Key takeaways

• Malicious npm packages can hide a full malware chain inside the software supply path, making ordinary package review insufficient on its own.
• This campaign combined dead-drop C2 discovery, environment checks, and Windows persistence, showing that supply chain abuse now blends infrastructure evasion with endpoint tradecraft.
• Teams need behavioural controls at intake and runtime, because the effective defence is not just identifying bad packages but stopping what they do after execution begins.

Key terms

• Dead Drop Resolver: A dead drop resolver is a technique where malware stores its command or destination in an external location that can be updated without changing the malware itself. That makes the control plane harder to detect and block because the payload is decoupled from a fixed server address.
• COM Hijacking: COM hijacking is a persistence technique that manipulates Windows Component Object Model registry entries so legitimate software loads attacker-controlled code. It is effective because it abuses normal operating-system behaviour rather than relying on obviously malicious file names or startup entries.
• Environment Fingerprinting: Environment fingerprinting is the practice of inspecting host traits such as CPU count, memory, operating system, or network details before deciding whether to execute malicious code. Attackers use it to avoid sandboxes, reduce analyst visibility, and tailor payload delivery to real endpoints.
• Supply Chain Malware: Malware delivered through trusted software distribution paths such as packages, dependencies, or build tooling. It succeeds by inheriting trust from legitimate workflows, which makes publication-time checks insufficient if the malicious behaviour appears only after install or in a later version.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for security practitioners who need to connect identity controls to broader supply chain and runtime governance decisions.