- Os pacotes npm maliciosos colortoolsv2 e mimelib2 buscaram URLs C2 de um contrato inteligente Ethereum para evitar a detecção.
- A indireção on-chain permitiu que os operadores rotacionassem endpoints sem republicar pacotes; o colortoolsv2 foi removido em 7 de julho antes de uma mudança para o mimelib2.
- Um push coordenado do GitHub usou repositórios falsos de bots de negociação, estrelas infladas e confirmações com script para mascarar as dependências maliciosas.
- Os IoCs incluem versões de pacotes, hashes SHA1 e o contrato 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, além de orientações para defensores.
Os agentes de ameaças recorreram a um truque inovador: encaminhar a infraestrutura maliciosa por meio de um Contrato inteligente Ethereum para ocultar ponteiros de comando e controle (C2) usado por pacotes npm. De acordo com o ReversingLabs, dois pacotes — colortoolsv2 e mimelib2 — acessaram discretamente o blockchain para recuperar URLs para payloads de segundo estágio, evitando verificações de rotina que buscam domínios codificados.
Em vez de explorar um bug no próprio Ethereum, o esquema aproveita a rede como uma camada de indireção pública e resiliente. Depois que o colortoolsv2 foi bloqueado no npm em 7 de julho, os operadores rapidamente mudaram para o mimelib2 com lógica quase idêntica, continuando a referenciar o mesmo contrato on-chain para a próxima etapa.
Da instalação do npm à pesquisa on-chain: como o desvio funcionou
Dentro do colortoolsv2, um carregador mínimo (index.js) atuou como um despachante que invocou um comando externo e buscou seu alvo em um contrato inteligente em vez de um script local ou configuração estática. O Etherscan mostra o contrato em 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, cujas funções de leitura retornaram uma URL usada para acessar o serviço C2.
Este ponteiro on-chain complicou o bloqueio: os defensores não podiam simplesmente confiar em encontrar ou colocar na lista negra um domínio codificado no pacote porque o o ponto final ativo vivia atrás de um contrato que os operadores controlavam. A rotação de destinos exigia apenas a atualização do armazenamento do contrato, não a republicação do artefato npm, e qualquer tráfego de blockchain resultante era mesclado como legítimo.
Uma vez executado durante a instalação ou tempo de execução, o carregador recuperou um second-stage component (SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21), que lidava com a atividade subsequente. Imitando o comportamento do colortoolsv2, o mimelib2 reutilizou o mesmo contrato para o mesmo propósito, com caminhos de código quase idênticos.
O ReversingLabs descreveu a abordagem como incomum no ecossistema npm: URLs maliciosos foram hospedados por meio do estado de um contrato inteligente, não em serviços web tradicionais frequentemente vistos em campanhas anteriores de cadeia de suprimentos (por exemplo, armazenamento em nuvem ou gists).
Fumaça e espelhos do GitHub: repositórios falsos de robôs de negociação como disfarce
Os pacotes npm não surgiram isoladamente. Os operadores criaram uma rede de projetos do GitHub apresentados como utilitários de negociação de criptomoedas:repositórios como solana-trading-bot-v2— e então os conectou às dependências maliciosas. Para um observador casual, esses repositórios pareciam "vivos", ostentando milhares de commits, múltiplos mantenedores, estrelas e observadores.
Um olhar mais atento revelou que grande parte da atividade era superficial e planejada, incluindo a rotatividade repetitiva de arquivos de licença e contas recém-criadas com conteúdo esparso (alguns criados por volta de 10 de julho com arquivos README tão simples quanto "Olá"). Nomes de usuários que apareceram nos históricos de commits — incluindo slunfuedrac, cnaovalles e pasttimerles — apareceram repetidamente nos projetos em fase de stage.
Os commits mostraram exatamente onde os pacotes foram encadeados na base de código—adicionando colortoolsv2 e posteriormente mimelib2 como dependências em bot.ts, e importações correspondentes aparecendo em src/index.ts. A prova social fabricada tornou a inserção de dependência muito menos óbvia durante uma análise superficial.
Na verdade, a fachada do GitHub amplificou os sinais de confiança enquanto a o verdadeiro ponto de decisão para o próximo movimento do malware residiu no Ethereum. Ao separar a engenharia social (GitHub) do controle (contrato inteligente), os operadores tornaram a campanha mais difícil de detectar e interromper.
IoCs e medidas concretas para os defensores
O ReversingLabs publicou um inventário detalhado dos artefatos vinculados a essa atividade, juntamente com a principal referência on-chain que impulsionou o segundo estágio. Os seguintes itens podem ser usados para caçar, bloquear e validar exposições em pipelines de construção e estações de trabalho de desenvolvedores:
- npm packages: colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215), 1.0.1 (1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b), 1.0.2 (db86351f938a55756061e9b1f4469ff2699e9e27)
- npm packages: mimelib2 1.0.0 (bda31e9022f5994385c26bd8a451acf0cd0b36da), 1.0.1 (c5488b605cf3e9e9ef35da407ea848cf0326fdea)
- Second stage: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21
- Contrato inteligente usado para indireção C2: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b
Contexto adicional da fase de remoção: colortoolsv2 foi removido do npm em 7 de julho, após o qual os operadores mudaram para mimelib2 com a mesma referência on-chain e comportamento de carregador quase idêntico.
As ações recomendadas para equipes de engenharia e segurança incluem: pesquisas na cadeia de sinalizadores realizadas por scripts de instalação; bloquear ou avisar sobre a execução do child_process nos ganchos do ciclo de vida do pacote; negar saída de rede durante a instalação do npm no CI; impor listas de permissões para registros e mantenedores; bloquear versões transitivas; e monitorar solicitações vinculadas ao endereço do contrato acima.
De forma mais ampla, trate as métricas de popularidade do repositório como sinais não relacionados à segurança. A confiança deve derivar de código, artefatos e indicadores de rede, não contagens de estrelas, volume de confirmações ou o aparecimento de muitos “mantenedores”. A verificação independente — análise estática, execução em sandbox e verificações de procedência orientadas por SBOM — continua essencial.
O que se destaca nesta campanha não é uma falha no Ethereum, no NPM ou no GitHub individualmente, mas a forma como a infraestrutura pública pode ser integrada em uma cadeia de entrega furtiva. movendo a descoberta C2 para um contrato inteligente e lavando a credibilidade por meio do GitHub, os atores exageraram na detecção tradicional. Uma higiene cuidadosa da dependência e controles em camadas são o contrapeso.
