Crate Rust malicioso 'evm-units' executa payloads específicos por SO

Descoberta e panorama

Pesquisadores identificaram que o crate Rust evm-units, publicado pelo autor identificado como ablerust, acumulou milhares de downloads antes de ser removido e mascarava comportamento malicioso por trás de uma função aparentemente inócua. Analistas do Socket.dev foram os primeiros a detalhar a cadeia de ataque e os vetores usados para a execução silenciosa do código malicioso.

Abordagem técnica / Vetor e exploração

O vetor principal repousava na função get_evm_version(), que, em vez de apenas retornar um número de versão, decodificava uma string Base64 para obter uma URL de comando e controle. O código implementava um loader de payloads que consultava essa infraestrutura e baixava artefatos compatíveis com o sistema da vítima.

Dois elementos facilitaram a infecção:

• Dependência encadeada: o pacote uniswap-utils dependia de evm-units e invocava o código durante a inicialização via #[ctor::ctor], permitindo execução sem interação direta do desenvolvedor.
• Execução por SO: o código usava atributos de compilação condicional (#[cfg(target_os)]) e User-Agent específicos (por exemplo, linux, darwin, win32) para solicitar payloads compatíveis e otimizar evasão.

Comportamento por plataforma

Segundo a análise publicada, o loader agia de forma diferente conforme o sistema:

• Linux/macOS: o malware baixava um script para o diretório temporário e o executava com nohup para suprimir saída visível.
• Windows: o código procurava pelo processo qhsafetray.exe (relacionado ao antivírus Qihoo 360). Na ausência do processo, gerava um VBScript para iniciar uma instância oculta do PowerShell; se o processo existisse, executava PowerShell com flags de criação suprimida para evitar heurísticas.

Impacto e alcance

O pacote tinha "milhares" de downloads antes da remoção, o que representa um vetor de risco elevado para ambientes de desenvolvimento que consumiram a cadeia de dependências. A dependência transitiva via uniswap-utils demonstra que bibliotecas utilitárias podem transformar-se em portas de entrada para execução remota sem ação explícita do desenvolvedor.

Mitigações e recomendações

• Auditoria de dependências: revisar dependências diretas e transitivas, especialmente antes de builds e em pipelines CI/CD.
• Repositórios internos: usar mirrors/registries internos com validação de pacotes e assinaturas para bloquear crates recém-publicados sem reputação.
• Monitoramento de comportamento: EDR/IDS com regras para identificar execuções atípicas de PowerShell, scripts em diretórios temporários e conexões para infraestrutura com certificados autoassinados (o malware usava danger_accept_invalid_certs(true) para tolerar TLS inválido).
• Políticas de runtime: restringir execução de código não assinado em ambientes de desenvolvimento sensíveis e separar workstations de desenvolvimento de artefatos de produção.

Limites das informações

As fontes descrevem o comportamento do crate e a análise do Socket.dev, mas não quantificam vítimas finais nem indicam atribuição a um ator. As comunicações C2 e o escopo exato da exfiltração não foram detalhados nas análises disponíveis.

Relevância para cadeias de suprimento de software

O caso reforça que a cadeia de dependências em ecossistemas modernos (como crates Rust, npm, PyPI) é um vetor crítico: utilitários aparentemente inofensivos podem executar código na inicialização e comprometer ambientes inteiros via dependências transitivas.

Fontes: Socket.dev; Cyber Security News.