Pacote falso NuGet rouba criptomoedas com ataque homóglifo

Entenda o golpe que usou um truque visual para enganar desenvolvedores .NET.

Escrito por
Jardeson Márcio
Jardeson Márcio é Jornalista e Mestre em Tecnologia Agroalimentar pela Universidade Federal da Paraíba. Com 8 anos de experiência escrevendo no SempreUpdate, Jardeson é um especialista...

Um novo e sofisticado ataque à cadeia de suprimentos foi descoberto no NuGet, o gerenciador de pacotes oficial do ecossistema .NET. O alvo: desenvolvedores que utilizam bibliotecas legítimas em seus projetos. O golpe envolveu um pacote falso NuGet chamado Netherеum.All, que se passava pela popular biblioteca Nethereum — usada amplamente em aplicações de blockchain e criptomoedas — para roubar dados sensíveis de carteiras digitais.

O ataque se destacou pela sutileza. Os criminosos usaram um truque visual quase imperceptível para enganar desenvolvedores atentos e, com isso, roubar chaves privadas e frases mnemônicas usadas em carteiras de criptomoedas. O pacote fraudulento chegou a acumular milhões de downloads falsos, demonstrando a sofisticação das táticas de engenharia social empregadas.

Este artigo explica em detalhes como o golpe funcionava, o objetivo dos invasores e, principalmente, como os desenvolvedores podem se proteger de ataques semelhantes.

5PKh1gH9 trading criptomoedas

O golpe do ‘homóglifo’: como o pacote Netherеum.All enganava os desenvolvedores

A base do golpe estava em uma técnica conhecida como ataque homóglifo, usada para criar nomes visualmente idênticos aos de projetos legítimos. O Netherеum.All parecia, à primeira vista, o mesmo que Nethereum, mas escondia um caractere invisível ao olho desatento.

O truque do caractere cirílico

Neste caso, o invasor substituiu o “e” latino (U+0065) pelo “е” cirílico (U+0435). Visualmente, ambos são idênticos, mas pertencem a alfabetos diferentes. Esse pequeno detalhe fez toda a diferença: ao pesquisar por “Nethereum” no NuGet, o pacote falso Netherеum.All aparecia lado a lado com o legítimo, levando muitos desenvolvedores a baixá-lo por engano.

Esse tipo de golpe, conhecido como typosquatting homóglifo, é especialmente perigoso porque explora a familiaridade visual. Mesmo usuários experientes podem ser enganados ao não perceber a diferença sutil no nome.

A farsa dos 11,7 milhões de downloads

Para dar uma aparência de legitimidade, os invasores inflaram artificialmente a contagem de downloads. O pacote falso registrou 11,7 milhões de downloads, número suficiente para sugerir popularidade e credibilidade.

Essa técnica é um exemplo clássico de engenharia social: ao apresentar métricas infladas, os criminosos criam uma falsa sensação de confiança, induzindo desenvolvedores a acreditar que o pacote é amplamente utilizado e, portanto, seguro.

Um pico tão rápido e anormal de downloads em um pacote novo, especialmente sem histórico de contribuições ou feedback da comunidade, é um forte sinal de alerta.

O objetivo: roubo de chaves privadas e frases mnemônicas

A investigação conduzida pela empresa de segurança Socket revelou o verdadeiro propósito do pacote malicioso. Assim que o Netherеum.All era instalado, o código incluía uma função disfarçada chamada EIP70221TransactionService.Shuffle.

Essa função, aparentemente inofensiva, decodificava um endereço de servidor de Comando e Controle (C2). Em seguida, o pacote passava a varrer o ambiente de desenvolvimento do usuário em busca de dados críticos — incluindo frases mnemônicas, chaves privadas e arquivos de keystore relacionados a carteiras de criptomoedas.

Essas informações eram então exfiltradas silenciosamente para o servidor remoto controlado pelos atacantes. O código foi cuidadosamente projetado para evitar detecção por antivírus e ferramentas de análise estática, tornando o ataque especialmente insidioso.

Por que o NuGet é um alvo fácil para este tipo de ataque?

O NuGet, diferentemente de outros repositórios como PyPI (Python) ou npm (Node.js), é mais permissivo em relação a caracteres de nomes de pacotes. Enquanto outras plataformas restringem a nomenclatura a caracteres ASCII, o NuGet permite caracteres Unicode, abrindo espaço para ataques homóglifos.

Essa lacuna é conhecida e já foi explorada em outros incidentes documentados pela ReversingLabs e por pesquisadores independentes. O resultado é que criminosos podem registrar pacotes com nomes quase idênticos aos de projetos legítimos, confundindo usuários e infiltrando malware na cadeia de suprimentos de software.

Como os pacotes são facilmente distribuídos e instalados via comandos simples — como dotnet add package —, a barreira de entrada para um ataque desse tipo é mínima, e o impacto potencial é gigantesco.

Como desenvolvedores .NET podem se proteger

Embora a equipe de segurança do NuGet tenha removido o pacote Netherеum.All e seus clones, a técnica usada é altamente replicável. Portanto, a prevenção depende, em grande parte, de boas práticas individuais.

Aqui estão medidas práticas que todo desenvolvedor .NET deve adotar:

  • Inspecione o nome do pacote: verifique cuidadosamente a ortografia antes de instalar. Prefira copiar o nome diretamente do site oficial do projeto.
  • Verifique o editor: confirme o nome do publicador. No caso do golpe, o pacote foi publicado por um usuário chamado “nethereumgroup”, e não pela equipe legítima do Nethereum.
  • Desconfie de métricas suspeitas: um pacote recém-criado com milhões de downloads é um forte indício de manipulação.
  • Monitore o tráfego de rede: use ferramentas de monitoramento para detectar conexões de saída anômalas durante o build ou execução de aplicações.
  • Adote ferramentas de segurança de supply chain: soluções como Socket, Snyk ou GitHub Advanced Security ajudam a identificar dependências comprometidas.

Conclusão: a vigilância na cadeia de suprimentos é responsabilidade de todos

Embora os pacotes Netherеum.All e NethereumNet já tenham sido removidos do NuGet, o incidente reforça um ponto crítico: a segurança na cadeia de suprimentos de software é um esforço contínuo.

Ataques baseados em homóglifos, typosquatting e engenharia social continuarão evoluindo. Cabe à comunidade .NET — desenvolvedores, mantenedores e equipes de segurança — adotar uma postura proativa de verificação e auditoria.

Afinal, um simples caractere invisível pode ser o elo mais fraco de toda a infraestrutura de segurança de um projeto.

Você já auditou as dependências do seu projeto recentemente? Compartilhe suas melhores práticas de segurança nos comentários e ajude a fortalecer a comunidade.

Compartilhe este artigo
Nenhum comentário