Malicious npm Packages Steal SSH Keys, API Tokens, Cloud Credentials, and Wallet Secrets

A new npm supply chain campaign is targeting blockchain, Web3, and cloud developers by stealing sensitive secrets from developer machines and build environments.

CYFIRMA says it identified 11 suspicious npm packages linked to the operation, including ethers-jss, coinbase-wallet-utils, moralis-sdk, ganach, solidty, stelar-sdk, hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat, and ethereum-dev-utils.

The campaign targets some of the most valuable developer secrets, including SSH private keys, GitHub tokens, npm tokens, AWS keys, API credentials, Ethereum private keys, mnemonic phrases, seed phrases, and deployment configuration files.

npm Packages Used Install Scripts to Steal Developer Secrets

The attack relies heavily on npm lifecycle scripts. According to the official npm scripts documentation, npm can run preinstall, install, and postinstall scripts during package installation.

That behavior is useful for legitimate setup tasks, but attackers can abuse it. In this campaign, malicious code could run as soon as a developer installed a package, with no extra action required after the install command.

CYFIRMA grouped the activity into multiple clusters. Some packages wrapped legitimate Ethereum development libraries, some used typosquatting, and others used blockchain infrastructure to hide command-and-control details.

Package or cluster	Main tactic	Primary risk
ethers-jss	Malicious wrapper around Ethereum tooling	Wallet private key and mnemonic theft
coinbase-wallet-utils	Reconnaissance and data exfiltration	Host, user, directory, and environment data theft
moralis-sdk	Trojanized copy of a legitimate SDK structure	Obfuscated postinstall downloader
ganach, solidty, stelar-sdk	Typosquatting and smart contract-based infrastructure lookup	Platform-specific payload delivery
ethcompat-related packages	On-chain data exfiltration	Encrypted credential theft through Ethereum transactions

ethers-jss Targeted Wallet Creation and Recovery

The ethers-jss package posed as a useful Ethereum development package, but researchers found wallet hijacking logic inside it. The malware hooked wallet creation and wallet recovery functions to capture private keys and mnemonic phrases.

That made the package especially dangerous for Web3 developers. If a developer generated or restored a wallet while the malicious package was active, the malware could collect the wallet address, private key, and recovery phrase.

The same package also searched for sensitive files and environment variables. Targets included .env files, Hardhat configuration files, shell configuration files, private keys, cloud secrets, npm tokens, GitHub tokens, Infura keys, and Alchemy keys.

• SSH private keys stored in the .ssh directory
• Cloud credentials such as AWS secret keys
• Developer tokens such as NPM_TOKEN and GITHUB_TOKEN
• Wallet secrets such as PRIVATE_KEY, MNEMONIC, and SEED_PHRASE
• Blockchain deployment files such as hardhat.config.js and foundry.toml

moralis-sdk Had the Largest Reported Exposure

The moralis-sdk package created a larger exposure because of its reported download volume. CYFIRMA says the package had accumulated more than 2.7 million downloads at the time of analysis, which increased the potential reach of the campaign.

The package used a staged approach. Version 1.0.0, published on October 28, 2025, appeared to be a clean copy of the legitimate project. Version 1.0.1, published on November 11, 2025, introduced the malicious postinstall code.

The malicious behavior was isolated in postinstall.js. The rest of the package copied legitimate-looking documentation, examples, README content, and project files to reduce suspicion.

Attackers Used Blockchain and Trusted Services

Several packages used more advanced infrastructure techniques. The ganach, solidty, and stelar-sdk packages queried an Ethereum smart contract to retrieve infrastructure details instead of hard-coding a command-and-control server.

This approach can make takedowns harder because infrastructure details can change through blockchain-based configuration. It also gives the malware a way to hide operational details from quick static checks.

Another cluster encrypted stolen credentials and embedded the data inside Ethereum transaction fields. That turned public blockchain infrastructure into an exfiltration channel and made stolen data appear as normal blockchain activity.

Technique	How it worked	Why it matters
Lifecycle script execution	Malicious code ran during install	Developers did not need to open or run a separate file
Package impersonation	Packages copied trusted project names or structures	Developers could mistake them for legitimate tools
Smart contract lookup	Malware queried Ethereum for infrastructure data	Attackers avoided obvious hard-coded C2 values
On-chain exfiltration	Encrypted data was placed in Ethereum transactions	Credential theft blended into blockchain activity
Obfuscated downloaders	Scripts hid payload logic and fetched more code	Security tools had fewer static indicators to inspect

Why This Is a Serious Supply Chain Risk

The campaign fits a broader software supply chain attack pattern. MITRE ATT&CK tracks this behavior under T1195.001, which covers compromise of software dependencies and development tools.

The risk extends beyond one developer laptop. A stolen npm token can help attackers publish malicious updates. A stolen GitHub token can expose source code and automation workflows. A stolen cloud key can give attackers access to production infrastructure.

Recent research from Unit 42 shows that modern npm attacks increasingly target CI/CD pipelines, cloud credentials, GitHub tokens, npm tokens, SSH keys, Kubernetes secrets, and HashiCorp Vault secrets.

Developers Should Treat npm Installs as Code Execution

The official npm scripts documentation makes clear that package scripts can run during installation. That means installing an unknown package can be equivalent to executing code from an unknown source.

npm provides an option to reduce this risk. The npm install documentation says ignore-scripts prevents npm from running scripts specified in package.json files, although explicitly run scripts still behave differently.

Developers can use npm install –ignore-scripts when testing unfamiliar packages, reviewing new dependencies, or investigating potentially suspicious packages. Teams should also verify whether the package needs install scripts at all before allowing them in CI.

• Review package names carefully for typosquatting.
• Check publisher history, repository links, and recent version changes.
• Use npm install –ignore-scripts for high-risk dependency checks.
• Keep private keys, seed phrases, and API tokens out of plaintext project files.
• Rotate credentials immediately if a malicious package may have run.

How Teams Can Respond to Possible Exposure

Teams that installed any of the listed packages should remove them, search developer machines and CI runners for execution traces, and rotate all potentially exposed secrets. That includes SSH keys, npm tokens, GitHub tokens, cloud credentials, wallet keys, RPC provider keys, and deployment secrets.

The CYFIRMA report recommends dependency verification, lifecycle script restrictions, secret management, endpoint monitoring, continuous dependency monitoring, and rapid incident response.

Unit 42 also recommends controls such as package-lock usage, npm ci in CI/CD pipelines, private registry proxying, provenance verification, and strict egress filtering for CI runners. The wider npm threat landscape now shows that package installation can expose much more than application code.

Action	Priority	Reason
Remove suspicious packages	High	Stops further execution from known malicious dependencies
Rotate exposed credentials	High	Stolen secrets can enable account, wallet, and cloud compromise
Audit CI/CD logs	High	Build runners often contain deployment secrets and tokens
Review outbound network traffic	Medium	Can reveal exfiltration to attacker-controlled infrastructure
Restrict install scripts	Medium	Reduces automatic execution during dependency installation

Indicators Reported by Researchers

Type	Indicator	Description
Package	ethers-jss	Malicious Ethereum wrapper targeting wallet secrets
Package	coinbase-wallet-utils	Reconnaissance and environment data theft package
Package	moralis-sdk	Trojanized SDK package with malicious postinstall logic
Package	ganach	Typosquatting package using blockchain-based infrastructure lookup
Package	solidty	Typosquatting package targeting blockchain developers
Package	stelar-sdk	Typosquatting package with downloader behavior
IP and port	193[.]233[.]201[.]21:3001	Remote payload distribution server retrieved through blockchain mechanism
Ethereum smart contract	0xa1b40044EBc2794f207D45143Bd82a1B86156c6b	Used to retrieve dynamic infrastructure information
Ethereum wallet	0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f	Used to receive exfiltrated credential transactions

The campaign shows how quickly an npm package can become a credential theft tool. For Web3 and cloud teams, dependency review is now a secret protection control, not only a code quality task.

Security teams should map detections to MITRE ATT&CK T1195.001 and review whether their existing controls can detect malicious package installation, suspicious postinstall execution, unexpected access to secret files, and outbound connections from build systems.

The npm install configuration can help reduce risk during package testing, but it does not replace dependency verification, secret rotation, network monitoring, and least-privilege access across developer and CI/CD environments.

FAQ