Ataque silencioso: pacotes NuGet maliciosos apontam ASP.NET para exfiltrar identidades e abrir portas traseiras

Pesquisadores em segurança têm desenterrado uma campanha sofisticada dirigida a desenvolvedores de aplicativos ASP.NET que, longe de buscar infecções barulhentas nas equipes dos programadores, aponta para um objetivo mais valioso e silencioso: as aplicações que esses desenvolvedores constroem. Segundo o relatório publicado por Socket, quatro pacotes maliciosos publicados em NuGet entre 12 e 21 de agosto de 2024 atuaram em conjunto para filtrar dados de identidade de ASP.NET e para implantar portas traseiras persistentes em aplicações implantadas.

Os pacotes, publicados pelo perfil Hamzazaheer, receberam mais de 4.500 downloads antes de serem retirados após a divulgação responsável. Seus nomes — incluindo variantes como NCryptYo, DOMOAuth2_, IRAOAuth2.0 e SimplesWriter_ — escondem comportamentos muito distintos: desde um “dropper” que ativa a cadeia de compromisso até componentes que extraem as tabelas de identidade, papéis e permissões de ASP.NET Identity e que aceitam regras de autorização enviadas pelo atacante para outorgar privilégios.

Em essência, a campanha utiliza um executável de primeiro estádio incorporado em um dos pacotes (NCryptYo) que se ativa quando a livraria se carrega na aplicação. Esse módulo instala o hooks no compilador JIT de .NET para desencriptar e colocar uma carga útil secundária: um proxy local que escuta em localhost:7152 e redirecione o tráfego para um servidor de comando e controle cuja direção é resolvida dinamicamente em tempo de execução. Através desse túnel local, os outros pacotes começam a enviar informações sensíveis de identidades e permissões ao exterior; a infra-estrutura remota pode então responder com novas regras de autorização que a aplicação processa, permitindo ao atacante criar contas administrativas ou desactivar verificações de segurança em ambientes de produção.

O pacote apresentado como utilitário de conversão de PDF, SimplesWriter_, incorpora capacidades preocupantes de escrita incondicional em disco e execução oculta de processos, permitindo que o atacante deixe executáveis adicionais na máquina vítima e os arranques sem janelas visíveis. A análise de meta- dados e do ambiente de compilação sugere que todos os pacotes provêm do mesmo ator, uma vez que compartilham pegadas de construção idênticas.

É importante sublinhar o vetor pelo qual se atua: não se busca apenas comprometer a estação de trabalho do desenvolvedor, mas manipular a camada de autorização durante o desenvolvimento para controlar aplicações instaladas. Quando a aplicação com dependências maliciosas chega à produção, o canal para o C2 pode permanecer ativo e continuar exfiltrando dados de permissões e recebendo regras que concedam acesso administrativo a qualquer instância implantada.

Este tipo de ataque é outra variação do problema mais amplo da cadeia de fornecimento de software: componentes de terceiros que parecem inofensivos e se incorporam a projetos acabam sendo a via de entrada a sistemas críticos. Em comparação, Tenable relatou outro caso recente no ecossistema npm: um pacote chamado ambar-src que se aproveitava do hook de instalação ( preinstall) para executar código malicioso no Windows, Linux e macOS e baixar carregadores que davam acesso remoto ao atacante. A pesquisa de Tenable detalha como esses instaladores descarregavam e executavam binários ou scripts que, em diferentes sistemas, encriptam desde shellcodes em memória até agentes baseados em frameworks como Mythic, e exfiltravam dados a domínios em serviços na nuvem para camuflar seu tráfego ( Tenable).

Os riscos são claros: quando uma dependência de terceiros pode modificar a lógica de autorização ou instalar processos persistentes, a integridade da aplicação e de seus usuários fica comprometida. Para aqueles que desenvolvem com ASP.NET, é crucial entender que a ex-filtração nestes incidentes se centra nos objetos e estruturas que manejam a autenticação e a autorização — por exemplo, tabelas e esquemas que lidam ASP.NET Identity — e que a presença de código não confiável no ciclo de construção pode permitir ao atacante mudar essas regras de fora.

Diante desta realidade, convém reforçar práticas de higiene na gestão de dependências e na cadeia de abastecimento. Manter um inventário de componentes e um SBOM, validar a procedência de pacotes e preferir artefatos assinados, auditar e digitalizar dependências com ferramentas especializadas, isolar os processos de construção e controlar o tráfego saliente desde as pipelines de CI/CD são medidas que reduzem a superfície de ataque. Além disso, aplicar políticas de menor privilégio em ambientes de desenvolvimento e revisão manual de mudanças em livrarias que interagem com a autenticação e as regras de acesso ajudam a detectar anomalias antes de chegarem à produção. Para aprofundar os controlos e recomendações gerais sobre segurança na cadeia de fornecimento, os guias de agências como CISA São úteis.

Outros recursos técnicos também são relevantes: a Microsoft oferece documentação sobre a assinatura de pacotes e melhores práticas para consumir pacotes em ambientes .NET ( assinatura de pacotes em NuGet) e projectos de código aberto e fornecedores de segurança continuam a melhorar as detecções para estes comportamentos. Além disso, pesquisas e ferramentas que analisam hooks do JIT, proxies locais suspeitos ou execuções no momento de carga são cada vez mais necessárias para identificar padrões como os descritos por Socket e Tenable.

Se você suspeitar que você usou algum destes pacotes ou qualquer outro que actue inesperadamente, considere tratar o sistema como potencialmente comprometido: remove as dependências, revisa logs e configurações de autorização, rota credenciais e segredos, e realiza uma análise forense se houver indícios de acesso não autorizado. Como lembrete técnico e operacional, a segurança de uma aplicação não começa nem termina no seu código fonte: as livrarias e o processo pelo qual chegam ao seu projeto importa tanto quanto o código que escreves.

A comunidade e as plataformas de pacotes estão atentas e respondem retirando artefatos maliciosos, mas a experiência demonstra que as descargas anteriores à remoção podem deixar instalações em numerosos repositórios e pipelines. É, por isso, imperativo que equipamentos de desenvolvimento, operações e segurança colaborem para detectar e mitigar ameaças na cadeia de abastecimento antes de chegarem à produção.