NuGet malicioso rouba credenciais de devs .NET e abre portas para backdoors em produção
Uma sofisticada campanha de ataque à cadeia de suprimentos de software foi identificada tendo como alvo direto desenvolvedores ASP.NET que utilizam o ecossistema .NET e o repositório oficial do NuGet. A operação, cuidadosamente planejada, usou quatro pacotes maliciosos para roubar credenciais, coletar dados sensíveis de aplicações e implantar backdoors persistentes em sistemas que venham a consumir essas bibliotecas comprometidas.
Os pacotes maliciosos foram publicados no NuGet entre 12 e 21 de agosto de 2024 por um usuário que se identificava como “hamzazaheer”. Em poucos dias, esses componentes somaram mais de 4.500 downloads, o que indica que não ficaram restritos a testes: é bastante provável que tenham sido integrados a projetos reais, inclusive em aplicações que já estão em produção.
Quais pacotes foram usados no ataque
Os investigadores identificaram quatro pacotes principais envolvidos na campanha:
– NCryptYo
– DOMOAuth2_
– IRAOAuth2.0
– SimpleWriter_
O NCryptYo é o componente mais sofisticado do conjunto e se apoia em uma técnica clássica de comprometimento de cadeia de suprimentos: o typosquatting. Ele foi criado para se passar pela biblioteca de criptografia NCrypto, amplamente utilizada em projetos .NET. Além de usar um nome extremamente parecido, o pacote contém um arquivo chamado NCrypt.dll, imitando o provedor de criptografia nativo do Windows, e replica também o namespace das APIs oficiais da Microsoft, o que facilita a enganação de desenvolvedores distraídos.
Como o NCryptYo se infiltra e permanece oculto
Assim que o assembly do pacote é carregado pela aplicação, um construtor estático é executado automaticamente, sem exigir ação explícita do desenvolvedor. Esse construtor cria e ativa um proxy oculto escutando na porta local 7152, que então redireciona o tráfego para uma infraestrutura remota controlada pelo atacante. Esse proxy funciona como um túnel silencioso, permitindo que dados sensíveis sejam desviados sem chamar atenção.
O NCryptYo vai além de uma simple DLL maliciosa. Ele utiliza uma técnica de sequestro do compilador JIT (Just-In-Time), de forma que o código nocivo é mantido criptografado e só é decriptado no momento da execução. Isso reduz drasticamente a chance de detecção por ferramentas que fazem análise estática do código ou inspeção superficial de binários.
Para aumentar ainda mais a resiliência contra análise e detecção, o arquivo NCrypt.dll é protegido por ofuscação .NET Reactor, inclui um mecanismo de expiração configurado para 14 dias e implementa diversas verificações anti-debugging. Na prática, isso significa que pesquisadores de segurança e analistas de malware encontram mais dificuldade para reverter o código e entender exatamente como o ataque é conduzido.
Infraestrutura compartilhada e evidências de uma campanha coordenada
A investigação conduzida por pesquisadores da Socket.dev mostrou que os quatro pacotes faziam parte de uma mesma campanha e não eram casos isolados. Ao analisar o tráfego e o comportamento das bibliotecas, foi possível identificar infraestrutura de comando e controle compartilhada entre todas elas.
Nos pacotes DOMOAuth2_, IRAOAuth2.0 e SimpleWriter_, os analistas descobriram um token de autenticação codificado byte a byte, o que reforça que todos foram desenvolvidos pela mesma pessoa ou grupo. Esse token é usado para autenticar comunicações com o servidor do atacante, garantindo que somente o código controlado por ele consiga interagir com a infraestrutura maliciosa.
Outra evidência da sofisticação da campanha apareceu em análises realizadas em plataformas de detecção de malware: ao ser enviado ao VirusTotal, o arquivo NCrypt.dll foi detectado como malicioso por apenas 1 entre 72 fornecedores de segurança. Esse índice baixíssimo de detecção mostra que as técnicas de ofuscação e evasão empregadas são altamente eficazes, pelo menos contra assinaturas tradicionais e soluções menos atualizadas.
Foco em ASP.NET Identity e roubo de credenciais
Os pacotes DOMOAuth2_ e IRAOAuth2.0 têm um papel bem definido na campanha: coleta silenciosa de informações sensíveis ligadas ao ASP.NET Identity, o sistema de gerenciamento de usuários, perfis e permissões amplamente utilizado em aplicações web .NET.
Uma vez ativados, esses pacotes extraem:
– IDs de usuário
– Roles (funções) e permissões associadas
– Outras informações de identidade relevantes para controle de acesso
Esses dados são então encaminhados, de forma furtiva, para o servidor do atacante, usando justamente o proxy local criado pelo NCryptYo na porta 7152. Ou seja, o tráfego parece local e inofensivo, mas na prática é retransmitido para a infraestrutura do criminoso, que passa a ter uma visão privilegiada do modelo de acesso e autenticação das aplicações vítimas.
SimpleWriter_: ferramenta “inofensiva” que planta arquivos e executa processos ocultos
O quarto pacote, SimpleWriter_, é apresentado como uma simples ferramenta de conversão de arquivos PDF, algo comum em aplicações corporativas e rotinas de automação. Na superfície, ele parece desempenhar essa função, o que ajuda a evitar desconfianças.
Por baixo, no entanto, o SimpleWriter_ é capaz de:
– Gravar no disco arquivos enviados ou controlados pelo agente malicioso
– Disparar a execução de processos em segundo plano, sem qualquer janela visível para o usuário
– Servir de porta de entrada para cargas adicionais, como outros malwares, backdoors mais avançados ou ferramentas de movimentação lateral na rede corporativa
Com esse comportamento, o atacante consegue estabelecer um ponto de apoio duradouro na máquina de desenvolvimento ou mesmo em servidores de aplicação, caso o pacote seja implantado em ambientes de produção.
O alvo real: aplicações em produção e ambiente corporativo
Embora o ponto inicial de comprometimento sejam os desenvolvedores .NET e suas estações de trabalho, o objetivo final da campanha não é apenas espionar o ambiente de desenvolvimento. O grande risco está nas aplicações em produção que, confiando no NuGet como fonte oficial, acabam incorporando esses pacotes na sua cadeia de dependências.
Uma vez que bibliotecas comprometidas são adicionadas ao código e implantadas em servidores de aplicação, o atacante ganha:
– Acesso em potencial a dados de usuários finais
– Visão sobre regras de autenticação e autorização usadas em produção
– Capacidade de manter backdoors duradouros, mesmo que a estação de trabalho original do desenvolvedor seja limpa
Isso transforma o incidente de “um pacote malicioso” em uma brecha crítica na cadeia de suprimentos, com impacto direto em empresas, clientes e dados confidenciais.
Por que esse tipo de ataque é tão perigoso para times .NET
Ataques via repositórios de pacotes são especialmente perigosos porque:
1. Exploram a confiança na cadeia de ferramentas – Desenvolvedores tendem a confiar em pacotes populares ou com nomes familiares, sem sempre revisar o código ou a procedência.
2. Escalam rapidamente – Um único pacote comprometido pode ser replicado em dezenas ou centenas de projetos, que por sua vez são distribuídos para inúmeros ambientes.
3. Dificultam rastreio – Identificar exatamente onde um pacote malicioso foi utilizado, em quais versões e em que ambientes está implantado pode ser trabalhoso, principalmente em organizações com dezenas de aplicações ASP.NET.
No caso específico do NCryptYo e dos demais pacotes da campanha, o uso de typosquatting, ofuscação avançada, técnicas anti-debugging e JIT hijacking faz com que muitas equipes de desenvolvimento sequer percebam que estão lidando com código suspeito.
Como desenvolvedores e empresas podem se proteger
Diante desse cenário, alguns cuidados passam a ser indispensáveis para quem trabalha com .NET e NuGet:
– Verificar o autor e a reputação do pacote
Antes de incluir um novo pacote, vale checar histórico, quantidade de downloads, tempo de existência e consistência das versões. Perfis recém-criados com poucos pacotes e nomes muito próximos de bibliotecas famosas merecem atenção redobrada.
– Conferir o nome com cuidado (evitar typosquatting)
Diferenças sutis, como uma letra a mais, sublinhados ou variações de maiúsculas e minúsculas podem indicar pacotes criados justamente para enganar quem digita rápido ou confia apenas em auto-complete.
– Auditar dependências de terceiros
Ferramentas de análise de composição de software (SCA) e scanners especializados em .NET podem ajudar a identificar bibliotecas suspeitas, assinaturas estranhas ou comportamentos anômalos.
– Adotar políticas internas de aprovação
Em vez de cada desenvolvedor adicionar qualquer pacote diretamente do NuGet público, muitas empresas criam repositórios internos espelhados, com curadoria e aprovação prévia dos componentes que podem ser utilizados.
– Monitorar comportamento em tempo de execução
Tráfego de rede inesperado, criação de proxies locais em portas incomuns (como a 7152 neste caso) e execução de processos em background sem explicação lógica devem acionar alertas em sistemas de observabilidade e segurança.
Impactos para segurança corporativa e compliance
Do ponto de vista corporativo, incidentes como este não afetam apenas a área técnica. Quando credenciais, tokens de acesso, dados de identidade de usuários e configurações de autorização são comprometidos, as consequências incluem:
– Risco de violação de dados pessoais e exposição de informações de clientes
– Possíveis incidentes de fraude, acesso indevido a sistemas internos e roubo de propriedade intelectual
– Problemas de conformidade com regulamentos de proteção de dados e normas de governança
– Perda de confiança de clientes e parceiros em produtos baseados em ASP.NET e na infraestrutura de software da empresa
Isso reforça a necessidade de tratar a segurança de dependências e da cadeia de suprimentos com a mesma seriedade dada à proteção de servidores, bancos de dados e endpoints.
Segurança em nuvem e a falsa sensação de proteção automática
Muitos times que rodam suas aplicações em ambientes de nuvem ou modelos SaaS acreditam que a plataforma por si só garantirá backup, integridade e proteção contra esse tipo de ataque. Essa percepção é perigosa: mesmo rodando em nuvem, se a aplicação incorporar um pacote NuGet malicioso, o provedor de infraestrutura não impedirá que o código seja executado.
Além disso:
– O backup padrão da nuvem muitas vezes não cobre o cenário de “backup de código comprometido”, apenas garante disponibilidade dos dados.
– Se um backdoor é implantado por meio de uma dependência maliciosa, restaurar snapshots pode simplesmente restaurar também o backdoor.
A responsabilidade pela segurança da cadeia de dependências, revisão de código e validação de pacotes permanece majoritariamente com as equipes de desenvolvimento e segurança da própria organização.
Caminho à frente: incorporar segurança ao ciclo de desenvolvimento .NET
O caso dos pacotes NCryptYo, DOMOAuth2_, IRAOAuth2.0 e SimpleWriter_ mostra que campanhas contra desenvolvedores .NET e o ecossistema NuGet estão se tornando mais direcionadas e sofisticadas. Para reduzir o risco, é fundamental:
– Integrar análise de dependências ao pipeline de CI/CD
– Treinar desenvolvedores para reconhecer sinais de typosquatting e engenharia social técnica
– Documentar e revisar periodicamente todas as bibliotecas externas utilizadas em projetos críticos
– Manter uma relação próxima entre times de desenvolvimento, segurança e operações para rápida resposta quando algum pacote suspeito for identificado
Ataques à cadeia de suprimentos não são mais uma hipótese distante: são uma realidade presente no dia a dia de quem constrói aplicações ASP.NET. Entender como esses pacotes operam, quais técnicas de evasão utilizam e como podem impactar ambientes de produção é o primeiro passo para fortalecer a segurança de todo o ciclo de desenvolvimento em .NET.