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 Findings
- First 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 Impersonation
The 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 Flow
Blockchain-Based Command & Control
The 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 Mechanism
Think 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 Execution
The 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 Malware
Our 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.
Impact
By 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.
Conclusion
The 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.
Packages
For the full list of packages related to this campaign see this link:
https://gist.github.com/masteryoda101/d4e90eb8004804d062bc04cf1aec4bc0
IOCs
- hxxp[:]//193[.]233[.]201[.]21:3001
- hxxp[:]//193[.]233[.]201[.]21:3001/node-win.exe
- hxxp[:]//193[.]233[.]201[.]21:3001/node-linux
- hxxp[:]//193[.]233[.]201[.]21:3001/node-macos
- df67a118cacf68ffe5610e8acddbe38db9fb702b473c941f4ea0320943ef32ba
- 0801b24d2708b3f6195c8156d3661c027d678f5be064906db4fefe74e1a74b17
- 3f4445eaf22cf236b5aeff5a5c24bf6dbc4c25dc926239b8732b351b09698653