Endor Labs researchers have identified 88 new malicious npm packages in the latest PhantomRaven campaign—81 of which are still available for download. These packages are actively stealing credentials from developer environments using a technique that bypasses most security scanning tools.
A key finding is that 257 out of 259 lines of the malware payload remain unchanged across different waves of this campaign. The attack pattern is stable and effective, indicating the operators see no need to modify it.
Key Findings
Remote Dynamic Dependencies evade static analysis. The malicious packages use Remote Dynamic Dependencies (RDD) to load their payload after installation. Your dependency scanner checks the package at rest, finds nothing suspicious, and approves it. The malicious code only appears when the package executes and fetches its payload from an external server. This is a fundamental blind spot in how most teams verify dependencies.
The campaign persists despite public disclosure. PhantomRaven was publicly reported months ago, yet 81 packages remain on npm, and the core attack code is virtually unchanged. This highlights significant gaps in npm's removal process and the operators' confidence in their technique.
Attribution claims don't matter for your risk assessment. Some packages claim they're part of security research. Regardless of intent, these packages execute credential-stealing code in your environment. That's the risk you need to address.
The attack targets your development environment, not production. These packages steal environment variables, configuration files, and credentials from developer machines and CI/CD pipelines. Your production security controls won't help if an attacker has your developers' AWS keys or database passwords.
What This Means for Your Team
You can't rely on pre-installation scanning alone. If your security process is "run npm audit before deploying," you're not catching RDD-based attacks. The malicious code doesn't exist in the package when you scan it.
Your developers are high-value targets. A compromised developer environment gives attackers access to source code, secrets, internal systems, and often production credentials. PhantomRaven specifically targets this attack surface because it's effective.
The "security research" excuse creates a gray area you need policy for. If someone publishes a package that steals credentials but claims it's for research, what's your response? You need a clear position on this before you're explaining to your CISO why you allowed it.
Action Items by Priority
Implement runtime monitoring for dependency behavior. Deploy tools that monitor what your dependencies do when they execute, not just what they contain when installed. This catches RDD attacks by revealing unexpected network requests or access to sensitive files. Tools like Socket or Phylum provide this capability. If you're using GitHub, enable Dependency Review and configure it to flag packages with install scripts or network access patterns.
Audit your current dependencies for RDD patterns. Search your package-lock.json or yarn.lock files for packages that use install scripts (preinstall, postinstall, install hooks). Review what these scripts do. Any script that fetches and executes remote code should trigger immediate investigation. Automate this check in your CI pipeline—fail the build if a new dependency introduces install scripts without explicit approval.
Restrict network access from your build environments. Configure your CI/CD runners to block outbound connections except to explicitly allowed domains. This won't prevent RDD attacks entirely, but it limits what the malicious code can exfiltrate. At minimum, block access to file-sharing services and anonymous paste sites commonly used for data exfiltration.
Separate developer credentials from environment variables. Stop storing production credentials in .env files or environment variables on developer machines. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password) that requires authentication per access. This limits what an attacker can steal even if they compromise a developer environment. For PCI DSS v4.0.1 environments, this also addresses Requirement 8.3.2 around protecting authentication credentials.
Create a policy for security research in your supply chain. Define what constitutes acceptable security research versus malicious activity. Your policy should require: advance disclosure to affected parties, clear documentation of research intent, no actual credential theft, and immediate package removal after demonstration. Document this policy and share it with your development team so they know how to respond when they encounter packages making research claims.
Monitor npm for packages using your organization's name. Attackers often create packages with names similar to internal tools or popular libraries. Set up alerts for new packages that match your organization's naming patterns. The npm registry API makes this straightforward to automate.
The PhantomRaven data shows you what supply chain attacks look like when they're working. The operators haven't changed their approach because they don't need to. Your security model needs to account for dependencies that behave differently at runtime than they appear during scanning. Start with runtime monitoring—it's the control that addresses the fundamental technique these attacks rely on.
