Resumo

Pesquisadores da Socket descobriram um pacote falso no repositório NuGet que se disfarçava como SDK oficial do Sicoob, um dos maiores sistemas financeiros cooperativos do Brasil. O pacote falso “Sicoob.Sdk”, nas versões 2.0.0 a 2.0.4, roubou certificados digitais PFX, IDs de cliente e senhas usadas para autenticar operações bancárias automatizadas — incluindo pagamentos Pix e geração de boletos. Com quase 500 downloads antes da remoção, o caso expõe vulnerabilidades graves na cadeia de suprimentos de software brasileira.

  • Pacote “Sicoob.Sdk” no NuGet roubou certificados PFX e credenciais bancárias
  • Quase 500 downloads antes do bloqueio; mesmo perfil publicou 11 outros pacotes
  • Google AI Mode apresentou o pacote como biblioteca legítima
  • Caso se insere em onda maior de ataques a repositórios de código em 2026

O ataque ao ecossistema Sicoob

O Sicoob é a maior rede de cooperativas financeiras do Brasil, com milhões de associados e uma API que permite a empresas integrarem serviços como processamento de pagamentos instantâneos via Pix e geração de códigos de boletos bancários. Para automatizar essas operações, desenvolvedores utilizam certificados PFX — arquivos digitais que comprovam a identidade da empresa perante a API do banco.

Foi exatamente nesse fluxo que atacantes criaram o pacote Sicoob.Sdk, publicado no NuGet, o repositório oficial de pacotes da plataforma .NET da Microsoft. Segundo a análise detalhada do The Hacker News, as versões 2.0.0 a 2.0.4 do pacote continham código oculto que exfiltrava dados sensíveis sempre que um desenvolvedor inicializasse a classe SicoobClient.

“Quando um desenvolvedor instancia SicoobClient com um client ID, caminho de arquivo PFX e senha, o pacote lê o arquivo PFX do disco, codifica em Base64 e envia o client ID, a senha PFX e os dados codificados para um endpoint Sentry de terceiros”, explicou o pesquisador Kirill Boychenko, da Socket, em seu relatório.

Como o pacote falso operava

O mecanismo de exfiltração era sofisticado o suficiente para passar despercebido em revisões de código superficiais. O pacote não alterava o comportamento visível da aplicação — ele cumpria a função esperada de um SDK bancário, mas operava silenciosamente em segundo plano.

O fluxo do ataque seguia estas etapas:

  1. Instalação pelo desenvolvedor: o pacote era instalado via NuGet como qualquer outra dependência C#.
  2. Inicialização da classe: ao instanciar SicoobClient com credenciais legítimas, o código malicioso era ativado.
  3. Leitura do certificado PFX: o arquivo de autenticação bancária era lido do disco da máquina do desenvolvedor.
  4. Exfiltração via Sentry: client ID, senha PFX e certificado codificado em Base64 eram enviados para um endpoint Sentry controlado pelo atacante.
  5. Captura de respostas de boletos: o pacote também interceptava respostas brutas da API de Boletos, expondo detalhes de transações, valores, datas de vencimento e dados de pagadores.

A consequência direta: com o certificado PFX e as credenciais em mãos, o atacante podia se passar pela integração bancária da vítima e realizar operações financeiras automatizadas em nome da empresa — incluindo processar pagamentos Pix e gerar QR codes dinâmicos.

IA do Google amplificou o golpe

Um dos aspectos mais preocupantes do caso é que o Google Search AI Mode — o modo de busca com inteligência artificial do Google — apresentou o Sicoob.Sdk como uma biblioteca C# legítima para integração com APIs do Sicoob. Isso significa que desenvolvedores que buscavam um SDK oficial puderam ser direcionados ao pacote malicioso pela própria ferramenta de IA do Google.

O caso evidencia um problema emergente na segurança de software: grandes modelos de linguagem e sistemas de busca por IA podem amplificar pacotes maliciosos ao apresentá-los como soluções confiáveis, especialmente quando o nome do pacote imita perfeitamente o de uma instituição real.

Além disso, o perfil responsável pela publicação — identificado apenas como “sicoob” no NuGet — mantinha um repositório GitHub aparentemente limpo e funcional. Essa desconexão entre o código-fonte público e o pacote distribuído é uma tática crescente: o GitHub serve como fachada de legitimidade, enquanto o payload malicioso reside exclusivamente no artefato publicado no repositório de pacotes.

Perfil publicou mais 11 pacotes suspeitos

O mesmo autor do Sicoob.Sdk publicou ao menos outros 11 pacotes no NuGet, que somaram cerca de 6.000 downloads no total. O escopo completo desses pacotes ainda está sendo analisado pela comunidade de segurança, mas o padrão sugere uma operação coordenada de coleta de credenciais.

O pacote Sicoob.Sdk foi removido do NuGet após a divulgação responsável. O pacote foi deletado e seu conteúdo ocultado por violação dos termos de uso do repositório NuGet.

Ataques a repositórios de código crescem

O caso do Sicoob.Sdk não é isolado. Ele faz parte de uma onda sem precedentes de ataques à cadeia de suprimentos de software que tem como alvo desenvolvedores em todo o mundo. Segundo o The Hacker News, apenas nos últimos dias foram identificados:

  • 14 pacotes npm maliciosos que imitavam bibliotecas populares do OpenSearch e ElasticSearch para roubar credenciais AWS, tokens do HashiCorp Vault e segredos de pipelines CI/CD, publicados pelo ameaçador “vpmdhaj” em 28 de maio.
  • 164 pacotes npm em cinco namespaces que baixavam código JavaScript de segundo estágio e exfiltravam variáveis de ambiente para o domínio “oob.moika.tech” — número que depois cresceu para 179.
  • 141 pacotes npm usados como hospedagem gratuita para um proxy web com anúncios, direcionado a estudantes.
  • O pacote “forge-jsxy” no npm, capaz de keylogging, monitoramento de clipboard, escaneamento de arquivos .env, exfiltração de histórico de shell, captura de screenshots e varredura de carteiras de criptomoedas.
  • 176 pacotes npm que usaram confusão de dependência com número de versão “99.99.99” para distribuir scripts de reconhecimento e roubo de credenciais.

A Microsoft, através de seu Microsoft Defender Security Research Team, identificou que os atacantes superaram as técnicas clássicas de typosquatting. Em vez de criar nomes com erros de digitação óbvios, agora constroem nomes que parecem plausíveis e funcionais dentro de fluxos de trabalho legítimos — o que a Sonatype chama de “manufatura de legitimidade”.

A campanha do TeamPCP (também chamado de Replicating Marauder ou UNC6780) exemplifica essa evolução: o grupo envenenou ferramentas populares de desenvolvedor no npm, PyPI, Docker Hub e Packagist de forma semelhante a um worm, transformando envenenamento de dependência isolada em um método reproduzível de comprometimento entre organizações.

Risco para empresas brasileiras

O impacto potencial do Sicoob.Sdk é particularmente grave no contexto brasileiro. O Sicoob atende majoritariamente cooperativas e pequenas e médias empresas que utilizam sua API para automatizar operações financeiras — um cenário em que a cadeia de confiança digital é crítica.

Com os certificados PFX comprometidos, um atacante poderia:

  • Processar pagamentos Pix em nome da empresa comprometida
  • Gerar QR codes Pix dinâmicos para desviar fundos
  • Acessar dados de boletos, incluindo valores, pagadores e status de pagamento
  • Interceptar informações de transações futuras via API

Para desenvolvedores e equipes de TI que trabalham com integrações bancárias, este caso reforça a necessidade de verificar a origem de qualquer dependência de código antes de incorporá-la ao projeto — especialmente quando envolve autenticação financeira.

Como se proteger agora

Se a sua equipe utilizou o pacote Sicoob.Sdk em qualquer versão entre 2.0.0 e 2.0.4, as ações imediatas recomendadas são:

  1. Remova o pacote imediatamente de todos os projetos e ambientes.
  2. Trate os certificados PFX como comprometidos — solicite novos certificados junto ao Sicoob.
  3. Altere as senhas PFX e rotacione todos os client IDs afetados.
  4. Audite os logs de autenticação e API do Sicoob em busca de atividade incomum.
  5. Revise o processo de seleção de dependências — verifique sempre o autor, o repositório de origem e o histórico de manutenção antes de instalar qualquer pacote.

Mais amplamente, equipes de desenvolvimento devem adotar ferramentas de análise de segurança de dependências, como Socket, Snyk ou Sonatype, que detectam comportamentos suspeitos em pacotes antes da instalação.

A decisão do Google AI de apresentar o pacote como legítimo também levanta questões sobre a confiança cega em respostas geradas por inteligência artificial para decisões técnicas. Desolvedores devem sempre cruzar recomendações de IA com fontes primárias — como a documentação oficial do banco ou do serviço.

Referências