Full Report
As part of our ongoing security efforts, we continuously monitor and detect malicious packages within various software ecosystems. Recently, we uncovered a unique supply chain attack through the NPM package “jest-fet-mock,” which implements a different approach using Ethereum smart contracts for command-and-control operations. The package masquerades as a popular testing utility while distributing malware across Windows, Linux, and macOS platforms. This discovery represents a notable difference in supply chain attack methodologies, combining blockchain technology with traditional attack vectors in a way not previously observed in npm. jest-fet-mock was the first package identified in a larger ongoing campaign targeting the npm ecosystem. Additional packages connected to this campaign were later reported by security firms Phylum and Socket.Key FindingsFirst observed instance of malware utilizing Ethereum smart contracts for C2 server address distribution in the NPM ecosystem.Typosquatting attack targeting developers by impersonating two legitimate, popular testing packages.Cross-platform malware targeting Windows, Linux, and macOS development environments.Uses NPM preinstall scripts to execute malicious code during package installation.Performs info-stealing actions while establishing persistence mechanisms across infected systems.The Art of ImpersonationThe malicious package “jest-fet-mock”, published in mid-October, was designed to impersonate two legitimate and widely used JavaScript testing utilities.The first, “fetch-mock-jest” (~200K weekly downloads), is a wrapper around fetch-mock that enables HTTP request mocking in Jest environments.The second, “Jest-Fetch-Mock” (~1.3M weekly downloads), provides similar functionality through Jest’s native mocking capabilities.Both legitimate packages are tools for testing HTTP requests in JavaScript applications. The attacker used a classic typosquatting technique by misspelling “fetch” as “fet” while maintaining the key terms “jest” and “mock”. Given that the legitimate packages are primarily used in development environments where developers typically have elevated system privileges, and are often integrated into CI/CD pipelines, we believe this attack specifically targets development infrastructure through the compromise of testing environments.Attack FlowBlockchain-Based Command & ControlEtherscan transaction details showing the smart contract’s getString method returning the C2 server addressThe most distinctive aspect of this attack is how it leverages the Ethereum blockchain for its command-and-control infrastructure. When executed, the malware interacts with a smart contract at address “0xa1b40044EBc2794f207D45143Bd82a1B86156c6b”. Specifically, it calls the contract’s “getString” method, passing “0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84” as a parameter to retrieve its C2 server address.By using the blockchain in this way, the attackers gain two key advantages: their infrastructure becomes virtually impossible to take down due to the blockchain’s immutable nature, and the decentralized architecture makes it extremely difficult to block these communications.Understanding the Smart Contract MechanismThink of a smart contract on the Ethereum blockchain as a public bulletin board — anyone can read what’s posted, but only the owner has the ability to update it. The attackers in this case deployed such a contract, using it to store their C2 server address. Every time the malicious package is installed on a new system, it checks this bulletin board to find out where to download the actual malware. What makes this approach particularly effective is its flexibility. Instead of hardcoding server addresses in their malware, the attackers can simply update their smart contract whenever they need to point to a new server. This means that even if defenders successfully block one C2 server, the attackers can quickly switch to a new one by updating their contract, and all new infections will automatically connect to the new location.Initial ExecutionThe attack chain begins during the npm package installation process through the preinstall script. This script determines the host operating system and constructs a platform-specific URL to download the appropriate payload. The malware then spawns a detached process, ensuring the malicious code continues running independently of the installation process.Multi-Platform MalwareOur analysis revealed distinct malware variants designed for:Windows (SHA-256: df67a118cacf68ffe5610e8acddbe38db9fb702b473c941f4ea0320943ef32ba),Linux (SHA-256: 0801b24d2708b3f6195c8156d3661c027d678f5be064906db4fefe74e1a74b17),and macOS (SHA-256: 3f4445eaf22cf236b5aeff5a5c24bf6dbc4c25dc926239b8732b351b09698653).Notably, as of this writing, none of these files have been flagged as malicious by any security vendors on VirusTotal.The malware variants demonstrated various capabilities including system reconnaissance, credential theft, and establishing persistence through platform-specific mechanisms — using AutoStart files in Linux and Launch Agent configuration (~/Library/LaunchAgents/com.user.startup.plist) in macOS.Throughout their operation, all variants maintain consistent communication with the attacker’s C2 server, showcasing a coordinated cross-platform attack strategy aimed at compromising development environments.ImpactBy targeting development tools and testing utilities, attackers gain potential access to not only individual developer machines but also CI/CD pipelines and build systems. The use of blockchain technology for C2 infrastructure represents a different approach to supply chain attacks in the npm ecosystem, making the attack infrastructure more resilient to takedown attempts while complicating detection efforts.The cross-platform nature of the malware, coupled with the fact that no security vendors have flagged these files as malicious on VirusTotal at the time of writing, makes this an actively dangerous threat to development environments.ConclusionThe discovery of “jest-fet-mock” reveals how threat actors are finding different ways to compromise the software supply chain. This case serves as an important reminder for development teams to implement strict security controls around package management and carefully verify the authenticity of testing utilities, especially those requiring elevated privileges.This campaign is ongoing, with additional packages connected to the same campaign reported later in the month by Phylum and Socket.As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play, including suspicious entry points, and promptly alert our customers to help protect them from potential threats.PackagesFull list of packages related to this campaign:https://medium.com/media/c2df69d4456790c918055a02ae426e96/hrefIOCshxxp[:]//193[.]233[.]201[.]21:3001hxxp[:]//193[.]233[.]201[.]21:3001/node-win.exehxxp[:]//193[.]233[.]201[.]21:3001/node-linuxhxxp[:]//193[.]233[.]201[.]21:3001/node-macosdf67a118cacf68ffe5610e8acddbe38db9fb702b473c941f4ea0320943ef32ba0801b24d2708b3f6195c8156d3661c027d678f5be064906db4fefe74e1a74b173f4445eaf22cf236b5aeff5a5c24bf6dbc4c25dc926239b8732b351b09698653Supply Chain Attack Using Ethereum Smart Contracts to Distribute Multi-Platform Malware was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.
Analysis Summary
# Incident Report: Novel NPM Supply Chain Attack Using Ethereum C2
## Executive Summary
A novel software supply chain attack was discovered leveraging the compromised NPM package `jest-fet-mock`, which utilized typosquatting to impersonate legitimate testing utilities. The distinct characteristic of this incident was the use of an immutable Ethereum smart contract to serve as a resilient Command and Control (C2) infrastructure for distributing stages of the malware. The attack targeted development environments across Windows, Linux, and macOS, leading to system compromise, information stealing, and persistence establishment.
## Incident Details
- Discovery Date: Recent (Implied by "uncovered")
- Incident Date: Mid-October (When `jest-fet-mock` was published)
- Affected Organization: Unspecified Organization/Ecosystem (NPM/Software Supply Chain)
- Sector: Software Development/Technology
- Geography: Global (As NPM is widely used)
## Timeline of Events
### Initial Access
- **Date/Time:** Mid-October
- **Vector:** Software Supply Chain Compromise via NPM Package Injection (Typosquatting)
- **Details:** The attacker published the malicious package `jest-fet-mock`, misspelling legitimate packages like `fetch-mock-jest` and `Jest-Fetch-Mock`. Execution began immediately upon package installation via the `preinstall` script.
### Lateral Movement
- **Details:** The malware performed system reconnaissance and established platform-specific persistence mechanisms (e.g., AutoStart files on Linux). The details on lateral movement *between* systems are not explicitly detailed, but the potential impact suggests CI/CD pipelines were targeted.
### Data Exfiltration/Impact
- **Details:** The executed malware variants performed info-stealing actions and communicated with the C2 infrastructure (retrieved via the Ethereum smart contract).
### Detection & Response
- **How it was discovered:** Continuous security monitoring detected the malicious package `jest-fet-mock`.
- **Response actions taken:** Notification/Reporting of the threat vector and sharing IOCs. Further packages in the campaign were reported by third parties (Phylum, Socket).
## Attack Methodology
- **Initial Access:** Typosquatting against NPM packages (`jest-fet-mock`) executed via **NPM preinstall scripts** during package installation.
- **Persistence:** Established using platform-specific mechanisms, including AutoStart files on Linux.
- **Privilege Escalation:** Not explicitly detailed, but implied necessary due to targeting development/CI/CD environments where developers often run with elevated privileges.
- **Defense Evasion:** Malware had zero detections on VirusTotal at the time of writing. Used unique C2 infrastructure (Ethereum) which is difficult to block/takedown.
- **Credential Access:** Performed explicitly stated info-stealing actions.
- **Discovery:** Performed system reconnaissance actions.
- **Lateral Movement:** Establishment of persistence configured for potential future access/control.
- **Collection:** Information gathering, including credentials.
- **Exfiltration:** Communication established with C2 infrastructure to download stages and potentially send stolen data (implied).
- **Impact:** Compromise of development machines and potential CI/CD pipelines.
## Impact Assessment
- **Financial:** Not specified.
- **Data Breach:** Focus on system compromise and credential theft within development environments.
- **Operational:** Potential disruption to CI/CD pipelines and build systems utilizing these testing utilities.
- **Reputational:** Significant risk to the integrity of the development toolchain.
## Indicators of Compromise
- **Network indicators (Defanged):**
- `hxxp[:]//193[.]233[.]201[.]21:3001` (C2/Payload download server)
- Downloaded payloads include: `node-win.exe`, `node-linux`, `node-macos`
- **File indicators (SHA-256):**
- Windows Payload: `df67a118cacf68ffe5610e8acddbe38db9fb702b473c941f4ea0320943ef32ba`
- Linux Payload: `0801b24d2708b3f6195c8156d3661c027d678f5be064906db4fefe74e1a74b17`
- macOS Payload: `3f4445eaf22cf236b5aeff5a5c24bf6dbc4c25dc926239b8732b351b09698653`
- **Behavioral indicators:**
- Interaction with Ethereum Smart Contract: `0xa1b40044EBc2794f207D45143Bd82a1B86156c6b` (calling `getString` method with parameter `0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84` to retrieve C2 address).
- Execution via NPM package `preinstall` script.
## Response Actions
- **Containment measures:** (Implied) Removal/blocking of the malicious package from package registries and dependencies. Blocking access to the identified C2 IP address.
- **Eradication steps:** (Implied) Scanning developer workstations and CI/CD systems for persistence mechanisms and deleted payloads.
- **Recovery actions:** (Implied) Restoring affected systems and potentially auditing developer access tokens if credentials were stolen.
## Lessons Learned
- **Key takeaways:** Threat actors are innovating supply chain attacks by integrating volatile technologies like blockchain (Ethereum) to create immutable and resilient C2 infrastructure that complicates defensive takedown efforts. Typosquatting remains an effective method to target developer tools.
- **What could have been done better:** Proactive dependency scanning and auditing of *all* package usage, especially testing utilities which often run with high privileges during build processes.
## Recommendations
- Implement strict security controls and vetting processes for all third-party dependencies installed in development environments and CI/CD systems.
- Utilize security solutions capable of monitoring for behavioral anomalies like package installation scripts attempting to make external network connections immediately.
- Favor registry mirrors or verified sources where possible, and audit package permissions required by installation scripts.