keyv/cacheable NPM Worm: When Revoking Tokens Backfires

Tacklebox

Campaign or TTP Overview

In a recent malicious campaign that rocked the software supply chain, the keyv/cacheable npm worm surfaced, illustrating a sophisticated development in npm repository threats. This incident involved the manipulation of a widely-used package, keyv, and its dependencies, impacting developers who automatically pull updates without scrutinizing each package version.

The attack was first identified in mid-2023, targeting a range of developer environments. By subverting a trusted npm library, the attackers gained wide reach, exploiting the automated dependency resolution process employed by developers. Notably, the tactic was attributed to an unidentified group with a strong grasp of open-source package distribution mechanisms, enhancing the worm’s efficacy by ensuring it rapidly proliferated across projects and environments.

The distinctive aspect of this attack was the counterintuitive reaction to handle the situation: revoking compromised tokens, typically the first step in such incursions, actually compounded the issue. Revocation inadvertently triggered reinstallation hooks, allowing the worm to propagate further as systems attempted to refresh credentials without refactoring dependency integrations. Relevant details were highlighted in a detailed SANS diary entry.

How It Was Built

The worm’s design capitalized on the inherent trust within the npm ecosystem. It began with injecting malicious code into the keyv library. The modified package contained hooks that executed payloads during installation or upgrade events in any hosting environment, effectively turning every npm installs or updates into a potential infection vector.


{

  "name": "keyv",

  "version": "x.y.z-worm",

  "scripts": {

    "install": "node worm.js"

  }

}

The delivery mechanism involved script executions which initiated network calls back to command-and-control (C2) servers, obtaining further commands or downloading additional payloads. Attackers utilized a domain masquerading approach with URLs resembling standard update sources, e.g., cdn.npmjs-updates.com, to deceive automated systems and devs into initiating the rogue updates.

The payload was ingeniously crafted to retain persistence even after cleanup attempts, embedding itself deeply into build environments so that any typical automated remediation step, such as token revocation and fresh login, exacerbated its control, by reinitializing via hooked scripts.

Why It Worked

The genius behind this campaign lay in the blend of trust exploitation and the token revocation booby-trap. The attackers understood the ecosystem’s reliance on automated processes. By poisoning an upstream dependency, they ensured the worm’s omnipresence wherever keyv was included, directly in line with the npm brand’s legacy of dependency.

Trust-based Vector: The package in question, recognized and trusted by many in software development, led to widespread rapid adoption of infected versions without immediate suspicion. This trust, leveraged against developers’ reliance on continuous integration/deployment (CI/CD), became an attack vector itself.

Cascading Revoke Effect: Token revocation, meant to cut off unauthorized access, triggered unintended installation scripts seated within dependency hooks. The intricacies of npm’s update mechanisms turned a reasonable response into a flawed catalyst for further infection, adding layers to the resilience of the attacker’s hold.

Operator Takeaways

This campaign teaches valuable lessons for offensive operatives regarding exploiting supply chain relationships and procedural responses. Emphasizing indirect control through dependency manipulation can offer expansive target engagement with minimal exposure. A few critical adaptations if replicating such a strategy include:

Dependency Hijacking: Explore trusted repositories for potential dependencies to inject with subtly modified payloads, promoting control entry points across numerous applications.
Remediation Harassment: Design payloads to leverage automatic remediation or refresh cues to reinforce footholds, capitalizing on safety mechanisms to aid propagation.

Do’s and Don’ts

Do conduct thorough reconnaissance on package dependencies and integrations before initiating supply-chain attacks.
Don’t underestimate the speed at which such infections can spread; maximize initial stealth and persistence to maintain presence after detection.
Do leverage widely trusted packages to maximize reach and minimize initial suspicion, ensuring lasting entry into development cycles.
Don’t rely solely on single vector control; diversify payload callbacks and C2 channels to mitigate loss of operability if one vector fails.

References

Key reference material provided via:
SANS Internet Storm Center

Additional reading may include detailed analysis on known vulnerabilities from Security Intelligence Reports.