Malicious npm Packages Adopt Runtime Execution to Evade Detection

The software supply chain is under siege once again. In a single day, cybersecurity researchers disclosed two distinct malware campaigns targeting the npm ecosystem, both demonstrating a troubling evolutionary leap in how threat actors evade detection. These campaigns, detailed on September 22, 2026, reveal that attackers are rapidly adapting to defensive measures, shifting from well-known installation-time attack vectors to stealthy runtime execution strategies that conventional security tools struggle to catch.

The Twilio Impersonation Campaign: tw-pkgprobe-7731

ReversingLabs researcher Lucija Valentić disclosed details of a malicious npm package named tw-pkgprobe-7731 that masqueraded as an authorized security research probe targeting developers integrating Twilio into their applications. The package was first uploaded to the npm registry in mid-August 2026 by an account called “twdepprobe7731.” In a burst of activity, eleven versions were published in rapid succession over approximately 45 minutes.

What makes this campaign particularly noteworthy is its social engineering approach. Comments inside the package described it as an “Authorized bug-bounty research probe (Twilio HackerOne program)” that “runs only inside Twilio’s serverless packager sandbox.” This legitimate-sounding framing could easily fool a developer who skimmed the documentation before installing.

How the Attack Unfolded

Upon execution, the package performed a environment check to determine whether it was running in a Twilio developer environment. If the check failed, it exited immediately — a precision-targeting technique that reduced its footprint and made detection less likely. When the check passed, the malware:

• Extracted environment variables and system details including mounts, temporary folders, and configurations
• Exfiltrated the gathered data via a webhook
• Scanned installed npm packages and node_modules directories for Twilio account SIDs
• Injected custom npm packages into matching project folders

Version 1.0.4 escalated the threat significantly by exfiltrating process.env.ACCOUNT_SID and process.env.AUTH_TOKEN — effectively compromising the victim’s Twilio credentials. This could allow the threat actor to authorize billing, trigger communications, and potentially pivot into broader infrastructure access.

Curiously, the final three versions reverted to the basic probing profile, dropping the credential-stealing functionality. The package also conducted OSINT gathering by probing Twilio-related hosts and even fetching AWS metadata from the well-known cloud instance endpoint. ReversingLabs noted that the package versions did not follow Twilio’s actual bug hunting guidelines on HackerOne, strongly suggesting malicious intent despite the researcher-probe framing.

indexed-btree: Runtime Execution Marks a Tactical Shift

On the same day, Checkmarx revealed a separate and arguably more sophisticated campaign centered on a package called indexed-btree. This malicious npm package mimicked the legitimate “sorted-btree” library — an ordinary B-tree indexing utility. What set it apart was its execution method: rather than relying on lifecycle scripts, the malware hid its loader entirely within application code that executed at runtime.

This represents a direct response to npm version 12’s security improvement, which prevents automatic execution of lifecycle scripts such as preinstall and postinstall. These scripts have been one of the most common vectors for supply chain malware, allowing threat actors to run malicious code automatically during package installation without user consent.

The EtherHiding Technique

The indexed-btree malware employed a multi-stage delivery chain with several notable techniques:

• The loader was concealed inside a BTree.prototype.set() method, triggering sharedLoad.min.js — a JavaScript payload embedding obfuscated first-stage malware
• Host fingerprinting data was beaconed to a hard-coded Slack channel and Telegram bot
• The campaign used the EtherHiding technique to pull encrypted next-stage payloads from a smart contract deployed on the Sepolia testnet
• The final stage involved deleting malicious artifacts and removing the trigger from the package code to cover tracks

The campaign was lucrative. Checkmarx estimated that the threat actor earned approximately €230,933.57 in cryptocurrency (109 ETH) from the operation. The package, uploaded on June 18, 2026, by a user named “charlessadler25,” amassed millions of downloads before removal. At least ten additional packages were tied to the same operation, all since delisted:

• ordered-kv-index
• btree-leaderboard
• priority-slot-queue
• btree-range-store
• btree-core
• btree-time-index
• btree-lru-cache
• neighbor-key-map
• sliding-score-window
• mutex-forge

PolinRider Resurfaces on Packagist

Compounding the day’s revelations, Socket reported that the North Korea-linked threat campaign known as PolinRider had resurfaced on Packagist, the PHP package registry. Socket removed malicious code from the “dev-main” version of “visanduma/nova-two-factor,” a package with over 700,000 cumulative downloads.

PolinRider’s hallmark is compromising developer accounts to inject malicious content into source code repositories. The campaign uses routine developer actions — cloning a repository or opening it in an IDE — as triggers to activate infection chains. Techniques include rewriting Git history, concealing payloads within configuration or font files, setting up malicious VS Code auto-run tasks, and using blockchain-based delivery methods like EtherHiding and its successor NullReceiver for staged payload delivery.

In its latest iteration, PolinRider introduced heavily obfuscated JavaScript directly into “index.php” files, executing it through PHP’s shell_exec() function. This adaptability demonstrates that the operators tailor their execution methods to each compromised project rather than relying on a fixed delivery path.

Why Runtime Malware Changes the Game

The shift from install-time to runtime execution is significant for the cybersecurity community. Traditional supply chain security tools focus on scanning packages during installation — checking for suspicious lifecycle scripts, analyzing install-time behavior, and blocking known-bad patterns. When malware moves its execution into the application’s normal runtime flow, these install-time controls become insufficient.

Ensar Seker, CISO at SOCRadar, captured the challenge succinctly: “Security controls change attacker behavior rather than eliminate the underlying threat. Blocking lifecycle scripts is an important improvement, but attackers will continue searching for alternative execution paths. Defenders need layered controls capable of detecting malicious behavior before installation, during execution, and after deployment.”

Practical Defensive Recommendations

For development teams and security professionals, these campaigns underscore several urgent priorities:

• Adopt runtime behavior analysis: Install-time scanning alone is no longer sufficient. Organizations need tools that monitor package behavior during execution, not just during installation.
• Verify package authenticity: Always cross-reference packages against their official registries and maintainers. Be wary of packages that mimic legitimate libraries with slight name variations.
• Lock dependencies: Use lockfiles and pinned versions to prevent unexpected package updates from introducing malicious code.
• Monitor environment variables: Both campaigns targeted environment variables containing credentials. Implement secrets management solutions rather than storing sensitive tokens in plaintext environment variables.
• Implement network egress controls: The Twilio-targeting package exfiltrated data via webhooks. Network monitoring can detect unexpected outbound connections from development environments.
• Audit blockchain-based delivery: EtherHiding and NullReceiver represent a growing trend of using smart contracts for malware delivery. Security teams should monitor for unusual blockchain interactions from development machines.

The Broader Supply Chain Threat Landscape

These incidents are not isolated. The npm ecosystem has been a frequent target for supply chain attacks, with threat actors increasingly recognizing that compromising a single popular package can grant access to thousands of downstream applications. The combination of npm’s improved security controls and attackers’ rapid adaptation creates a perpetual cat-and-mouse dynamic.

What is particularly concerning is the speed of adaptation. The indexed-btree campaign emerged almost immediately after npm version 12’s lifecycle script restrictions were introduced, demonstrating that threat actors monitor security improvements and adjust their tactics in real time. The PolinRider campaign’s evolution across multiple package registries — from npm to Packagist — shows that these threats are not confined to a single ecosystem.

For organizations building software in 2026, the message is clear: supply chain security requires a multi-layered approach that addresses the entire lifecycle of a dependency — from selection and installation through runtime execution and ongoing monitoring. Relying on any single control, no matter how effective it appears, will inevitably leave gaps that determined attackers will exploit.

As threat actors continue to refine their techniques, the cybersecurity community must match that evolution with equally adaptive defensive strategies. The days of trusting a package simply because it passed install-time checks are over.

---

Edited by Palawan @QUE.COM
Website: https://QUE.COM Intelligence
Sponsored by: https://MAJ.COM AI Autonomous