PhantomRaven: npm malware campaign exploits Remote Dynamic Dependencies to evade detection

CyberSecureFox 🦊

Security researchers at Koi Security report a protracted npm supply chain operation dubbed PhantomRaven that has uploaded 126 malicious packages since August 2024, accumulating more than 86,000 downloads. At the time of their publication, roughly 80 packages were still active. The campaign’s defining feature is its use of Remote Dynamic Dependencies (RDD)—a technique that fetches and executes code from external URLs during installation, helping adversaries bypass conventional static analysis and registry-centric defenses.

How Remote Dynamic Dependencies work—and why they are hard to spot

In a typical npm workflow, third‑party modules are listed in package.json and resolved from the npm registry, with versions locked in a lockfile. RDD overturns this model by allowing a package to download and run code at install time from attacker-controlled endpoints, including over plain HTTP. The malicious package can present zero declared dependencies, creating a false sense of safety for developers and many SCA tools.

When a user runs npm install, the package silently retrieves a payload and executes it. Because the dependency is never listed in the manifest or lockfile—and never fetched via the npm registry—static analysis and lockfile diffing fail to capture the true components that end up on the system.

Targeted delivery, poor reproducibility, and multi-channel exfiltration

Koi Security notes that PhantomRaven retrieves a fresh payload on every install and avoids caching. This enables fine-grained targeting: operators can fingerprint the requester (for example, by IP or environment), serve a benign response to security researchers, or deliver customized implants to corporate networks and cloud build agents. Such behavior complicates reproducibility, triage, and forensics.

Post-compromise, the malware gathers system telemetry and exfiltrates sensitive data, including access tokens. Stolen tokens can become an entry point for follow-on supply chain attacks, such as tampering with repositories and CI/CD pipelines. Data exfiltration is implemented redundantly via HTTP GET with data in the URL, HTTP POST in JSON, and WebSocket channels to improve reliability and blend-in.

Masquerading and the rise of “slopsquatting”

Several packages impersonate tools from ecosystems associated with GitLab and Apache, boosting credibility and install rates. Operators also exploit slopsquatting—the registration of packages that match plausible but non-existent names hallucinated by LLM assistants. Developers who rely on AI recommendations without verification may inadvertently install attacker-owned packages, turning helpful prompts into a malware delivery vector.

Supply chain impact: why build systems are especially exposed

RDD breaks core assumptions behind dependency management: the lockfile and static scanners do not reflect what actually executes on build hosts. In CI/CD environments, this gap increases the blast radius—compromise of build agents, environment secrets, or artifacts can lead to widespread downstream impact. Historical incidents in the npm ecosystem (e.g., ua-parser-js in 2021) and beyond (e.g., SolarWinds; Codecov bash uploader) show how quickly developer tooling compromise can propagate. Frameworks such as NIST SSDF (SP 800-218) and SLSA emphasize provenance, isolation, and least privilege—controls directly challenged by RDD.

Defensive guidance for npm and CI/CD pipelines

Restrict code execution during installs

Minimize blind spots in CI/CD by disabling lifecycle scripts where feasible (for example, use npm ci with ignore-scripts) and running builds in egress-restricted environments that allow only trusted registry domains over HTTPS.

Tighten egress and protocol policies

Block outbound HTTP and deny downloads from unverified external URLs during build steps. Apply egress filtering and use TLS-inspecting proxies to detect anomalous destinations and payloads while preserving secrets appropriately.

Improve dependency provenance

Adopt manual and automated vetting of new packages: author reputation, release history, source availability, and integrity checks. Monitor for typosquatting and slopsquatting. Consider a private mirror or internal cache of vetted packages to reduce exposure.

Harden secrets management

Use short-lived tokens with least privilege, enforce rotation, and scan for exposed secrets. Segregate build environments from production networks and store secrets outside the workspace when possible.

Educate developers and review AI-suggested dependencies

Do not install packages based solely on LLM recommendations. Train teams to identify red flags such as unexpected external downloads, obfuscated install scripts, and packages with minimal provenance.

PhantomRaven underscores how adversaries weaponize npm’s flexibility and developer trust to bypass standard controls. Organizations can reduce risk by enforcing scriptless installs in CI, applying egress-by-default-deny, validating dependency provenance, and tightening token hygiene. Reviewing pipeline configurations today—disabling unnecessary scripts, limiting external connectivity, and instituting independent review of new packages—will materially diminish the likelihood and impact of the next supply chain incident.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.