Alerta: o pacote de NuGet que fingia ser um SDK bancário para roubar credenciais e certificados PFX

Pesquisadores de segurança detectaram um pacote malicioso em NuGet que se fazia passar por um SDK legítimo para Sicoob, uma das maiores cooperativas financeiras do Brasil, e cujo objetivo era roubar credenciais da API e certificados PFX utilizados por empresas para autenticar-se na rede bancária e automatizar pagamentos e cobranças. A ameaça não é apenas técnica: explora a confiança de desenvolvedores que procuram integrar serviços bancários, convertendo uma instalação rotineira em uma brecha potencialmente crítica para pagamentos e dados financeiros.

Tecnicamente, o pacote interceptava o fluxo normal de inicialização do cliente: quando um desenvolvedor proporcionava um client ID, a rota para um arquivo PFX e sua senha, o código malicioso leia o arquivo PFX a partir de disco, codificava seu conteúdo e enviava esse pacote - juntamente com o client ID e a senha - a endpoints pré-configurados que atuavam como receptores de exfiltração. Além disso, havia canais dedicados para capturar respostas cruas da API de Boleto, o que expõe não só credenciais, mas também detalhes de transações, pilhas, prazos e identificadores sensíveis.

Há vários pontos de interesse nesta campanha que devem preocupar a comunidade: primeiro, o pacote foi distribuído de NuGet e alcançou centenas de downloads antes de ser bloqueado, o que demonstra que os registros públicos continuam sendo um vetor eficaz para propagar código malicioso. Segundo, os atacantes usaram uma tática de “manufactured legitimacy” Ao associar o pacote com um repositório do GitHub aparentemente legítimo, criando uma discordância entre o código público e o binário distribuído por NuGet; essa separação dificulta a detecção manual e engana os verificadores superficiais.

Outro amplificador do problema foi o aparecimento do pacote em resultados gerados por ferramentas de busca baseadas em IA, que o recomendaram como uma biblioteca válida para integrar com Sicoob. Essa combinação –registro público + aparência legítima + recomendações automáticas – faz com que desenvolvedores desprevenidos instalem dependências sem controles adequados, expondo assim credenciais de produção e ativos críticos.

Este incidente é inserido em uma onda mais ampla de ataques à cadeia de fornecimento de software que têm afetado principalmente o ecossistema npm, com campanhas que usam typosquatting, postinstall hooks e técnicas de dependência para extrair credenciais de ambientes locais, pipelines CI/CD e arquivos .env. Analistas de segurança e empresas como Sonatype documentaram como os atacantes deixaram para trás simples faltas de ortografia e agora desenham nomes de pacotes e versões que parecem completamente plausível em fluxos de trabalho reais, uma prática que descrevem como fabricação de legitimidade. Para ler análises e recomendações sobre essas técnicas, são úteis recursos públicos como o blog de Sonatype https://www.sonatype.com/blog e projetos que promovem assinatura e verificação de artefatos como Sigstore https://sigstore.dev.

As implicações práticas são severas: com um PFX e sua senha um atacante pode suplantar integrações bancárias, criar pagamentos ou receber fundos em nome da vítima, ou filtrar informações financeiras de terceiros. A nível organizacional, isto pode traduzir-se em perdas econômicas diretas, fraude, sanções regulatórias e danos reputacionais, especialmente em mercados onde métodos como Pix e Boleto estão amplamente adotados.

Para reduzir o risco imediato devem ser tomadas medidas de emergência e estratégicas. Na resposta imediata, qualquer um que tenha instalado o pacote em questão deve eliminá-lo do seu código e repositórios, considerar o material PFX como comprometido, revogar ou substituir os certificados expostos, rodar senhas e desactivar ou regenerar os IDs afectados. Paralelamente, recomenda-se auditar os logs de autenticação e transações em Sicoob em busca de atividade anómala e coordenar com a equipe de segurança do banco se houver indícios de abuso.

Em um plano preventivo mais amplo, as organizações e desenvolvedores devem evitar armazenar material sensível em texto plano dentro de repositórios ou discos compartilhados; em seu lugar convém usar cofres de segredos e HSM/Vaults que minimizem a presença de chaves no filesystem. A cadeia de abastecimento deve ser protegida por políticas de bloqueio de pacotes não verificados, uso de registries internos ou whitelists, validação de assinaturas de pacotes, geração de SBOMs e adoção de controles como SLSA. Implementar a digitalização automática de dependências, rever diferenças entre o pacote publicado e o código-fonte ligado, e restringir o acesso de CI/CD a segredos sensíveis são contramedidas que reduzem a superfície de ataque.

Finalmente, este caso serve como lembrete de que a segurança da infraestrutura de pagamentos depende tanto de boas práticas criptográficas como de higiene na gestão de dependências. As ferramentas automáticas de recomendação e busca podem acelerar o desenvolvimento, mas também amplificam riscos quando não se combinam com verificação humana e controles técnicos. A indústria precisa avançar para fluxos onde a proveniência e a integridade de cada dependência sejam verificáveis por defeito, e as equipes de desenvolvimento devem incorporar revisões de segurança em cada passo do ciclo de vida do software.