PhantomRaven's campaign of remote dependencies that puts in check npm

In recent months the JavaScript community has again received an uncomfortable reminder: software supply chains remain one of the favorite vectors for attackers. A campaign known as "PhantomRaven," initially detected in late 2025 and expanded by subsequent research, has been publishing malicious packages in the npm registry with the intention of stealing sensitive data from developers and continuous integration environments.

The technical peculiarity of PhantomRaven is its use of remote dynamic dependencies (Remote Dynamic Dependencies, RDD), a simple but effective tactic: instead of embed the malicious code within the published package, attackers point from the package.json file to a unit hosted in an external URL. When running npm install that unit is downloaded from the attacker's server and run, in many cases avoiding automated static checks that analyze the package content in the register. You can see a technical explanation of how npm plays package.json in the official npm documentation: https: / / docs.npmjs.com / cli / v9 / conforming-npm / package-json.

Public research on PhantomRaven, including that of Endor Labs, describes several waves of publication: after the initial discovery new rounds were detected between November 2025 and February 2026 in which the attackers launched dozens of packages from disposable accounts. Endor Labs documents in detail the persistence of the campaign, the consistency of the payload and the associated infrastructure; your report is available here: https: / / www.endorlabs.com / learn / return / of-phantomraven. According to these analyses, many of the samples are still accessible in the npm record.

Another recurring feature of the campaign is the use of "slopsquatting" or typosquatting techniques: malicious packages try to look like very used legitimate projects - for example Babel or GraphQL Codegen - by publishing names that could be confused with those suggested by automatic assistants or by whom they quickly copy and paste a recommendation. The combination of convincing names and remote dependence reduces the probability of detection and increases the probability of a developer installing the package by error.

Once the malicious code reaches the machine, its goal is clear and dangerous: to collect information that allows the attacker to move laterally or exfilter secrets. Endor Labs notes that the samples look for local files and configurations such as .gitconfig and .npmrc, environment variables and tokens used by CI / CD pipelines - GitHub, GitLab, Jenkins, CircleCI -; they also collect system prints (IP, hostname, Node version) to shape the victim. The sending of data to the control and command server (C2) is usually done by HTTP GET, although the authors also used POST and WebSocket to ensure redundancy.

The infrastructure used by PhantomRaven showed repeated patterns: domains that include the word "artifact," servers on Amazon EC2 that often lacked TLS certificate, and a payload whose most of the code remained unchanged between waves. However, the operators rotated npm and post accounts, adjusted metadata and changed PHP endpoints to remain operational with minimal changes.

This leaves several practical lessons for any developer or security team. First, there is no shortcut: to verify the origin of a package and its publication is more important than ever. It is not enough to copy the one suggested by a chatbot or paste without looking at a name that "sounds good." Inspecting package.json, reviewing the author and the publicator's reputation, and checking the existence of a reasonable source repository are simple steps that can avoid many unpleasant surprises. For those who manage pipelines and repositories, it is recommended to enable unit scanning and secret detection tools that are integrated into the workflow; GitHub offers secret scanning and Dependabot capabilities for security updates that help reduce the risk: https: / / docs.github.com / en / code-security / secret-scanning.

It is also appropriate to apply security controls on tokens and credentials: limit the scope of tokens CI / CD, rotate them regularly and not expose them in files that can be read by third-party processes. At the organizational level, the practice of building artifacts in isolated environments and using reliable package allowlists (rather than installing packages from public record without supervision) reduces the attack surface. Resources such as OWASP and supply chain analysis provide useful guidance on unit hygiene and early detection: https: / / owasp.org / www-project-dependency-check /.

There are also commercial and community solutions that can help mitigate risks: unit security scanners, private packets mirrors, and stricter publishing policies in internal repositories. Platforms such as Snyk have published guides and analysis on how supply chains remain critical vectors; see, for example, their coverage of supply chain attacks: https: / / snyk.io / blog / supply-chain-attacks /.

Although PhantomRaven's technique is not sophisticated from the cryptographic or obfuscation point of view of the code - the payload barely changed between samples - its effectiveness lies in operational simplicity and in the exploitation of human habits: relying on names, following unverified examples and running facilities in privileged environments. A small change in development habits and the adoption of basic safety controls can significantly reduce exposure.

If you are a developer, check your projects and pipelines: look for units that point to external URLs in package.json, confirm that there are no unknown packages in your lockfiles and consider scanning development machines and CI runners with tools that detect abnormal communications to suspicious domains. If you run an organization, it promotes zero-confidence policies for third-party packages and provides teams with a catalogue of approved and updated units.

The industry has already had similar episodes and solutions are largely known. The lesson is that the surveillance must be continuous: the attackers will repeat patterns that work and rotate the minimum necessary to move forward. Stay informed, apply technical controls and, above all, check twice before installing, are steps that are now part of the basic safety of any npm-based project.