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

At a glance

What this is: This is a supply chain threat analysis showing 54 malicious npm packages using smart-contract-based C2 resolution and Windows persistence techniques.

Why it matters: It matters because software supply chain abuse can bypass conventional perimeter controls, and package-level compromise can become an access path into build systems, developer endpoints, and secrets-bearing environments.

By the numbers:

• On 8th January we detected and blocked a malware campaign which targeted Windows hosts, consisting of 42 new malicious NPM packages.
• An additional 12 related packages were blocked on January 9th, bringing the total to 54 packages.

👉 Read Veracode's analysis of the malicious npm package campaign and C2 evasion

Context

Open-source package ecosystems are attractive to attackers because trust is inherited at install time, not proven at execution time. In this case, malicious npm packages were published to blend into developer workflows while delivering first-stage malware, making the primary governance problem supply chain integrity rather than a single blocked indicator.

The identity angle is indirect but real. Package managers, build pipelines, and developer endpoints often run with privileged access to code, secrets, and cloud credentials, so a poisoned dependency can become an access path into non-human identities and the systems that rely on them. That makes software supply chain controls part of identity governance, not just application security.

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 malicious packages so often target developer and CI environments?

A: Because those environments usually sit close to high-value material such as signing keys, tokens, API keys, and cloud credentials. Even when the malware is not overtly credential-stealing, the surrounding trust boundary is wide enough that a small dependency compromise can become a broader access problem.

Q: How do you know if package screening is actually working?

A: Look for controls that catch more than known bad names. Effective screening should detect obfuscation, suspicious install-time behaviour, native code loading, unexpected network beacons, and persistence changes on the endpoint. If the only signal is a reputation hit after publication, the control is too late.

Q: Who is accountable when a malicious package reaches production systems?

A: Accountability usually sits across security, engineering, and platform operations. Engineering controls the dependency choices, security defines the detection and response requirements, and platform teams govern build pipelines and package trust policies. Frameworks such as NIST CSF, NIST 800-53, and MITRE ATT&CK support shared ownership of prevention, detection, and response.

Technical breakdown

How smart-contract C2 resolution changes takedown dynamics

The campaign stored its command-and-control URL in an Ethereum smart contract, a dead drop resolver pattern that decouples malware from fixed infrastructure. Because the malware reads the destination from the contract, defenders cannot neutralise it simply by blocking a hardcoded domain. This also creates operational flexibility for the attacker, who can update the destination without republishing the package. The result is a more resilient delivery chain that is harder to sinkhole, blocklist, or attribute quickly.

Practical implication: tie package screening to runtime behaviour and not just known bad domains.

Why environment fingerprinting and Windows checks matter

The first-stage payload fingerprints the host by hashing system details such as hostname, CPU count, memory, and network interfaces, then checks for Windows systems with five or more CPUs. That is a classic anti-analysis pattern. It helps the malware avoid sandbox environments and reduces the chance that defenders will see the second stage during detonation. In other words, the malicious package is not just delivered through npm, it actively shapes where and when its payload executes.

Practical implication: use detonation environments that mirror real developer endpoints closely enough to trigger conditional logic.

COM hijacking and native module loading as persistence mechanisms

The payload uses registry persistence through COM hijacking and a native node module loader named analytics.node to execute the second stage through asynchronous procedure calls. COM hijacking lets malware redirect legitimate component loading by manipulating registry keys, while native module loading moves execution beyond simple JavaScript inspection. This combination increases durability and complicates static review, because the malicious behaviour is split across package metadata, JavaScript staging, and native code execution paths.

Practical implication: inspect package install hooks, native modules, and registry changes as one attack chain, not separate events.

Threat narrative

Attacker objective: The likely objective is to maintain foothold on Windows endpoints long enough to deliver a second-stage payload, steal cryptocurrency-related value, or support broader malware development.

1. Entry occurred through malicious npm packages published to an open-source registry and installed in developer or Windows environments.
2. Credential access was not the primary focus of the observed stage, but the payload established host fingerprinting and C2 beaconing to prepare for second-stage execution.
3. Impact would follow through persistence, second-stage delivery, and likely theft or mining activity on compromised endpoints.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package trust has become an access control decision. Open-source installs are often treated as software procurement, but this campaign shows they also function as privilege grants into developer environments. Once a malicious package is executed, the attacker inherits whatever local permissions, environment variables, and adjacent secrets the install path exposes. For identity and application security teams, software composition controls are now part of access governance, not just dependency hygiene.

Dead drop resolvers create governance blind spots. By placing the C2 location in an Ethereum smart contract, the attacker separated malware behaviour from static infrastructure indicators. That weakens takedown, blocklisting, and simple indicator-based detection because the malicious endpoint can change without code changes. Practitioners should treat any package that externalises its control plane as higher risk and require deeper behavioural review before trust is granted.

Identity-adjacent risk lives in developer tooling and build pipelines. Package ecosystems routinely sit next to secrets, tokens, signing keys, and cloud access material. A dependency compromise can therefore pivot from endpoint malware into non-human identity abuse, especially when build agents or developer machines carry standing access. The governance lesson is that least privilege must extend to software delivery paths, not only to human accounts.

COM hijacking and native loaders are a persistence compound, not isolated tricks. The campaign combines registry manipulation with native module execution, which means static package review alone will miss part of the attack chain. That is a useful reminder that supply chain threats are increasingly multi-layered and that policy needs to cover install-time behaviour, native code, and post-install persistence as one control domain.

Supply chain malware is increasingly identity-relevant because the next target is often a token. Once a malicious package is installed on a developer endpoint or in a CI runner, the practical question becomes whether the attacker can reach cloud credentials, API keys, or signing material. This makes package integrity, secret exposure, and endpoint hardening a single governance problem. The control boundary should follow the trust boundary, not the repository boundary.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Forward look: Read NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding controls that prevent privileged identities from accumulating unmanaged access.

What this signals

Package supply chain abuse is becoming identity-adjacent by default. The more developers, build agents, and AI-assisted pipelines rely on third-party packages, the more likely it becomes that an attack starts with code but ends with credential exposure. For programmes that already struggle with secret sprawl, the right response is to bind dependency trust to identity controls, endpoint hardening, and secret governance in one operating model.

Dead drop resolver abuse is a useful named concept for defenders. It describes a malware pattern where the control plane is hidden behind an indirect lookup such as a blockchain contract, making static blocklists less useful. Teams should expect more of these control-plane indirections in supply chain malware and build detection that watches for unexpected resolution behaviour, not just malicious domains.

For practitioners

• Inspect package install paths for behavioural red flags Scan npm dependencies for unusual postinstall activity, native module loading, registry writes, and environment fingerprinting before allowing them into developer or CI environments.
• Treat package managers as privileged execution surfaces Apply tighter execution controls to build runners and developer workstations, especially where package installation can touch secrets, signing keys, or cloud credentials.
• Add dead drop resolver detection to pipeline controls Flag packages that retrieve C2 destinations from blockchain contracts, paste sites, or other indirect lookups rather than static domains.
• Harden Windows developer endpoints against persistence Monitor registry locations associated with COM hijacking and validate that endpoint protection can detect asynchronous native module execution.
• Separate dependency trust from runtime trust Require deeper scrutiny for packages that pass basic reputation checks but still use obfuscation, anti-analysis checks, or second-stage loading patterns.

Key takeaways

• Malicious npm packages are no longer just a developer nuisance. They are an execution path into endpoints, secrets, and the identities those systems depend on.
• Using an Ethereum smart contract for C2 resolution makes takedown and indicator-based blocking materially harder because the control plane can move without changing the payload.
• Practitioners should treat package trust, endpoint persistence, and secret exposure as one control problem and enforce behavioural screening before code reaches production.

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.
• 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.
• Native Module Loader: A native module loader is code that loads compiled components rather than plain interpreted scripts. In malware campaigns, this can be used to hide execution paths, evade simple source inspection, and move malicious behaviour deeper into the runtime where static review is less effective.

What's in the full report

Veracode's full analysis covers the operational detail this post intentionally leaves for the source:

• The full indicator set for the malicious packages, including package names, registry keys, and infrastructure artefacts.
• The exact detection and blocking workflow used to identify and stop the campaign across package and endpoint layers.
• The malware behaviour notes around COM hijacking, native module loading, and the dead drop resolver pattern.
• The package-level findings that help defenders build allowlisting and triage rules for similar npm campaigns.

👉 The full Veracode post includes indicators of compromise, registry artefacts, and the package list used in the campaign.

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 gives security and identity practitioners a practical framework for governing privileged access across modern delivery pipelines.