How to Detect NPM Package Manager Supply-Chain Attacks with YARA

Authors: Alex Hegyi and Vince Zell

In September 2025, the JavaScript ecosystem was hit by two high-profile and very different npm supply-chain attacks: first, a fast and short-lived malicious push, and then a follow-on worm campaign.

• Attack 1 | “chalk/debug” maintainer compromise: a phished maintainer account pushed malicious versions of chalk, debug, ansi-styles, and related packages. The injected code primarily targeted browser builds and aimed to hijack crypto interactions.
• Attack 2 | Shai-Hulud worm: a self-replicating campaign that compromised over 500 npm packages, including those belonging to Crowdstrike – this attack stole maintainer tokens and autopublished backdoor updates. This planted malicious GitHub actions to exfiltrate secrets (AWS/GCP/Azure/GitHub) and establish persistence. 

YARA to detect the chalk/debug supply-chain attack

YARA is effective for supply-chain detection, because it can find patterns across source repositories and built artifacts, and not just single filenames or IP addresses. For npm incidents, we look for broad, repeatable pivots that show across many attack types: 

• Suspicious code markers, such as uncommon strings, obfuscated payload fragments, or known function selectors in malicious logic
• Build/packaging anomalies, like unexpected postinstall scripts
• Malicious or unexpected GitHub Actions workflows (odd paths, new workflow files) or unusual workflow permissions pointing to repo and CI abuse
• Credential and exfiltration pivots

Below is a YARA rule we put together for the chalk/debug supply-chain attack earlier in the month:

rule chalk_attack_npm_0925
{
    meta:
        author="Stairwell Threat Research”
        date="2025-09-11"
        description="Detects malicious wallet-drainer code patterns associated with the September 2025 chalk/debug npm supply-chain compromise"
        ref="https://github.com/chalk/chalk/issues/656"
     strings:
        $s1="runmask"
        $s2="checkethereumw"
        $function_selector="0x095ea7b3"
    condition:
        all of them
}

NPM supply-chain versions found by Stairwell

Through deploying this rule, Stairwell quickly turned up impacted versions sitting in customer environments, showing the real-world value of hunting with YARA.

Conversely, knowing your environment is absent of these impacted versions allows security teams to move on to other tasks. Uniquely, Stairwell helps companies understand both the presence and absence of these malicious files within their environment.

Security controls for NPM repos

Best practices for implementing additional controls include:

• Ignore run-scripts that allow packages to be altered immediately on run.
• Enable 2FA for updating repos to limit the spread to maintainers’ other packages.
• Set a minimum release age, delaying the install of brand new versions and reducing risk of uninstalling compromised packages.

More best practices in this OWASP cheat sheet.

Multiple YARA rules to detect supply-chain attacks

Beyond the YARA rules detection we’ve shared here, Stairwell researchers have also developed additional YARA rules for related npm compromises observed this month, and make these available internally to help customers apply the same approach for their own environments.

Stairwell helps defenders detect npm threats by enabling unlimited retrohunt at scale. We allow you to apply YARA rules against historical npm artifacts and surface hits across months (or years!) of retention within minutes – which is critical given the short exposure windows.

Supply-chain compromises, as we’ve witnessed this month, show just how quickly trust can be broken in widely used ecosystems. While defenders can’t control what gets published upstream, Stairwell can help control how fast they detect, hunt, and respond inside their own environments.

YARA is a practical way to enable these detections, and Stairwell makes it possible to run them retroactively and continuously at scale.