What Happened
A recent campaign by the North Korean threat actor group Famous Chollima involved the publication of 26 malicious packages to the npm registry. These packages deployed a cross-platform remote access trojan (RAT) using Pastebin for command-and-control (C2) communication. The campaign was discovered by Socket, a supply chain security firm.
The attack used character-level steganography to hide C2 instructions on Pastebin, complicating detection efforts. The attackers deployed their C2 infrastructure across 31 Vercel deployments, showcasing both scale and sophistication.
Timeline
While specific dates for package publication and discovery are not available, the campaign followed a clear pattern: publish packages, establish C2 communication through legitimate services, and maintain persistence across multiple infrastructure deployments.
Key points:
- 26 packages were published to npm.
- 31 separate Vercel deployments supported the C2 infrastructure.
- Pastebin served as the dead drop resolver.
- Socket identified and reported the campaign.
Which Controls Failed or Were Missing
Package Vetting Before Installation
Your team may lack a formal process for reviewing new dependencies before they enter your codebase. The malicious packages reached npm because there was no pre-publication security review, and organizations downloading them lacked automated scanning.
Egress Monitoring
The RAT communicated with Pastebin and Vercel-hosted infrastructure. Without monitoring outbound connections from your development and build environments, you won't detect this type of C2 communication. Many teams focus on ingress threats, neglecting egress monitoring.
Build Environment Isolation
Developer workstations and CI/CD pipelines that can access arbitrary internet endpoints create vulnerabilities. The packages could exfiltrate credentials, source code, or environment variables without triggering alerts.
Dependency Integrity Verification
Without checksum verification or package signing validation, your package manager will install whatever the registry serves. You lack cryptographic proof that the package you're installing matches what the legitimate maintainer published.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 requires maintaining an inventory of bespoke and custom software, and third-party software components to facilitate vulnerability and patch management. You need a complete inventory of your dependencies to assess whether malicious packages are present.
PCI DSS v4.0.1 Requirement 6.4.2 mandates using software engineering techniques to prevent or mitigate common software attacks. Supply chain attacks qualify as such, and your development process must include controls to prevent malicious dependencies.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires protecting against supply chain threats by employing security safeguards as part of a comprehensive information security strategy. This control addresses third-party components, requiring technical controls to verify package integrity before execution.
ISO/IEC 27001:2022 Annex A.8.30 (Outsourcing) requires addressing information security within supplier agreements. While npm packages aren't traditional suppliers, they are code you're incorporating into your application. Your security requirements must extend to your dependency chain.
Lessons and Action Items for Your Team
Implement Dependency Scanning in CI/CD
Add a security scanner to your pipeline to check packages against known malicious signatures before merging code. Tools like Socket, Snyk, or GitHub's Dependabot can flag suspicious packages based on behavior analysis.
Enforce scanning by configuring your CI/CD to fail builds when high-severity issues are detected.
Lock Your Dependencies with Checksums
Use package-lock.json or yarn.lock and commit these files to version control. These lock files include SHA-512 checksums. If a package is replaced with a malicious version at the same version number, the checksum won't match, and installation will fail.
Verify the integrity file itself hasn't been tampered with by reviewing changes in pull requests.
Monitor Outbound Connections from Build Environments
Deploy network monitoring on your CI/CD runners and developer workstations. Create alerts for connections to:
- Paste sites (Pastebin, GitHub Gists, etc.)
- Serverless platforms (Vercel, Netlify, AWS Lambda endpoints)
- Newly registered domains
- Geographic regions you don't operate in
The Famous Chollima campaign used Pastebin and Vercel. Your monitoring should flag these patterns as anomalous.
Restrict Build Environment Network Access
Your CI/CD runners don't need full internet access. Use egress filtering to allow only:
- Your package registries (npm, PyPI, etc.)
- Your artifact repositories
- Your version control system
- Your monitoring and logging endpoints
Block everything else by default. If a package tries to contact Pastebin during installation or runtime, the connection fails.
Review Package Metadata Before Adding Dependencies
Before adding any new package, check:
- Publication date (brand new packages are higher risk)
- Maintainer history (new maintainer on an old package is a red flag)
- Download statistics (very few downloads suggest limited vetting)
- Repository activity (no commits in months, then sudden activity)
- Typosquatting patterns (names similar to popular packages)
This won't catch everything, but it catches obvious attempts. The Famous Chollima packages likely exhibited some of these warning signs.
Isolate Development Environments
Your developers' laptops shouldn't have the same network access as production systems. Segment your network so that a compromised development machine can't pivot to production infrastructure or access production credentials.
Use separate AWS accounts, separate GCP projects, or separate Azure subscriptions for development versus production. A RAT on a developer's machine should hit a wall when it tries to move laterally.
Audit Your Current Dependencies
Run a scan against your existing package.json files now. You may already have malicious or vulnerable packages installed. Don't assume your current state is clean just because you haven't detected an incident.
The 26 packages in this campaign are now known. Check whether any are in your dependency tree.
Supply chain attacks exploit trust. You trust npm to host safe packages and package maintainers to publish clean code. The Famous Chollima campaign shows that this trust model is broken. Your controls need to assume packages are malicious until proven otherwise.
