Between August 2023 and now, eight malicious npm packages accumulated 40,767 downloads, delivering Overlord RAT and information stealers to developer workstations. One package, 'function-flag', accounted for 37,419 of those downloads. CloudSEK and Checkmarx disclosed the campaign, codenamed MALFEX, after tracking 12 related packages through the npm registry.
This wasn't a zero-day exploit or a sophisticated social engineering operation. Attackers published packages with plausible names, used lifecycle hooks to execute malicious code during installation, and waited for developers to run npm install.
Timeline
August 2023: Campaign begins. Attackers publish initial packages to the npm registry with names designed to appear legitimate or useful.
Installation phase: Developers download packages as dependencies. The 'function-flag' package gains traction, accumulating the majority of downloads over the campaign period.
Execution: Lifecycle hooks (preinstall, postinstall scripts) trigger automatically during npm install, executing malicious payloads before developers inspect package contents.
Payload delivery: Overlord RAT and information stealers deploy to compromised developer workstations, establishing persistence and exfiltrating credentials, source code, and environment variables.
Detection and disclosure: CloudSEK and Checkmarx identify the malicious packages and coordinate disclosure with npm to remove them from the registry.
Which Controls Failed
Dependency verification: Teams installed packages without verifying package integrity, publisher identity, or reviewing installation scripts. No checksums, no signature verification, no manual review of lifecycle hooks.
Least privilege: Developer workstations ran with sufficient privileges for malware to establish persistence. The installation process had access to credentials, SSH keys, and environment variables containing API tokens.
Network segmentation: Compromised developer machines could reach external command-and-control infrastructure without restriction. No egress filtering blocked the initial callback or subsequent data exfiltration.
Monitoring: No tooling flagged suspicious package installations, unexpected network connections from developer workstations, or the execution of obfuscated code during package lifecycle events.
What Standards Require
NIST 800-53 Rev 5 SR-3 (Supply Chain Protection) requires organizations to employ integrity verification mechanisms for software components. You need to verify package signatures, compare checksums against known-good values, and maintain an approved list of package sources.
NIST 800-53 Rev 5 CM-7 (Least Functionality) demands you restrict software installation privileges and disable unnecessary features. Developer workstations shouldn't run npm with administrative privileges, and package managers should require explicit approval for lifecycle script execution.
ISO/IEC 27001:2022 Annex A.8.30 (Outsourced Development) requires security controls for externally developed software components. This includes vetting third-party code, monitoring for vulnerabilities, and establishing criteria for accepting external dependencies.
PCI DSS v4.0.1 Requirement 6.3.2 mandates that you maintain an inventory of bespoke and custom software and third-party software components. You can't secure what you don't track. Every npm package your application depends on needs documentation, version pinning, and periodic review.
Lessons and Action Items
Lock down lifecycle hooks immediately. Configure npm to require explicit approval before running preinstall, postinstall, or other lifecycle scripts. Set ignore-scripts=true in your .npmrc file and whitelist specific packages that require build steps:
ignore-scripts=true
Then use npm rebuild <package> only for packages you've audited.
Pin dependencies with lock files. Use package-lock.json or yarn.lock to ensure reproducible builds. Don't rely on semantic versioning ranges that automatically pull the latest version. An attacker who compromises a maintainer account can push a malicious update that your CI/CD pipeline will install automatically.
Audit dependencies before adding them. Before running npm install, check the package's download count, publication history, and maintainer reputation. Review the package.json for suspicious lifecycle scripts. Use npm pack <package> to download without installing, then inspect the contents.
Implement Software Bill of Materials (SBOM) tracking. Generate an SBOM for every build using tools like Syft or the native npm sbom command. Compare each new SBOM against the previous version to detect unexpected dependency additions. This satisfies PCI DSS v4.0.1 Requirement 6.3.2 and gives you visibility into supply chain changes.
Segment developer environments. Developer workstations shouldn't have direct access to production credentials or unrestricted internet access. Use bastion hosts for production access, rotate credentials stored in environment variables, and implement egress filtering that blocks connections to known malicious infrastructure.
Monitor package installations. Deploy endpoint detection that alerts on npm installations outside approved hours, installations of packages not in your approved list, or network connections initiated by Node.js processes to unfamiliar domains. The MALFEX campaign operated for over a year because no one was watching.
Verify package integrity. Use npm's built-in signature verification once it's widely adopted, or implement your own integrity checks. Calculate SHA-256 hashes of packages in your lock file and compare them before installation. Tools like Socket or Snyk can automate this verification.
The MALFEX campaign succeeded because it exploited trust. Developers trust that packages in the npm registry are safe. They trust that lifecycle scripts perform legitimate build tasks. They trust that popular packages with thousands of downloads have been vetted.
Your job is to verify that trust with technical controls. Every npm install is a potential compromise. Treat it accordingly.
