A malicious NuGet package masquerading as the official C# SDK for Sicoob — Sistema de Cooperativas de Crédito do Brasil, one of Brazil’s largest cooperative banking systems with roughly 9 million members and over 5,000 service points — has been caught stealing the exact authentication material the SDK was supposed to protect. Socket published its analysis on May 28, 2026; The Hacker News corroborated it on May 29. NuGet has since blocked the package. The interesting part for infrastructure teams is not the theft itself but the channel: the package exfiltrates banking certificates through Sentry, a legitimate error-monitoring SaaS that most egress policies already allow.

What Happened

The package, Sicoob.Sdk, presented itself as a .NET 8 SDK that “manages authentication and mTLS certificates natively.” It first appeared on NuGet on May 5, 2026, reached version 2.0.4 a day later, and pulled roughly 484 downloads across six versions before Socket’s abuse report took it down. Versions 2.0.0 through 2.0.4 carry the malicious code.

A developer integrating with Sicoob’s APIs needs three things: a client ID, a PFX certificate, and the PFX password. A PFX file is a password-protected archive that typically bundles a client certificate and its private key for mutual TLS. The SDK asks for all three through an entirely ordinary-looking constructor — and that constructor is where the theft happens.

Technical Details

When an application instantiates SicoobClient with a client ID, a PFX path, and a PFX password, the compiled DLL (lib/net8.0/Sicoob.Sdk.dll) initializes Sentry with a hardcoded DSN, reads the PFX file from disk with File.ReadAllBytes, base64-encodes it, and ships the client ID, the plaintext PFX password, and the encoded certificate archive out through SentrySdk.CaptureMessage. Socket confirmed the behavior both statically (via an IL excerpt) and dynamically. A second capture path harvests raw boleto API responses — Brazilian payment-slip records that can expose transaction amounts, due dates, identifiers, and payer/payee data.

Two design choices make this more dangerous than commodity malware. First, the exfiltration is gated on production mode: the constructor only initializes Sentry when its isSandbox flag is false, which is exactly the documented production usage. In sandbox mode it skips Sentry entirely, so the package looks clean in a test environment and only leaks when fed real credentials. Second, there is a source-to-package mismatch. The linked GitHub org Sicoob-Cooperativa hosts a clean SicoobClient.cs that loads the certificate for mTLS and nothing more — no Sentry init, no file read, no base64. The visible source is a façade; the malicious logic lives only in the published binary. That defeats the reflexive “the repo looks fine” review.

The impersonation infrastructure is freshly minted and unverified: the GitHub org was created May 4, 2026, has zero followers and no public members, and its sole contributor account (joaobcdev) was created roughly two minutes earlier. Worse, during the investigation Google’s AI Search surfaced Sicoob.Sdk as the legitimate .NET package for Sicoob integration, laundering a malicious dependency into a routine search result.

Impact

Anyone who instantiated SicoobClient with real credentials should treat that PFX material as compromised. With a valid client ID, certificate, and password, an attacker can impersonate the victim’s Sicoob API integration — minting tokens and reaching Pix instant payments, boleto operations, balances, transfers, investment data, and Open Finance functions, subject to Sicoob-side controls. CI/CD pipelines are the sharp edge here: PFX files and passwords routinely live in build secrets, deployment variables, and mounted secret volumes, so a single release job that constructs the SDK can leak certificates straight out of a privileged automation environment.

Two related findings underline that this is a pattern, not a one-off. The same sicoob NuGet profile published 11 other Sicoob-branded modules (~6,000 combined downloads), untrusted by association. And on May 28, Microsoft flagged 14 malicious npm packages typosquatting OpenSearch, ElasticSearch, and DevOps/env-config libraries to harvest AWS keys, Vault tokens, npm tokens, and CI/CD secrets via a preinstall hook.

What To Do Now

Remove Sicoob.Sdk immediately and find every place it ran — workstations, build jobs, production services. Treat any PFX used with the affected versions as burned: revoke and replace the certificates, rotate the passwords, and rotate or disable the affected client IDs. Pull Sicoob authentication and API logs and look for unusual token issuance, source IPs, Pix activity, boleto access, payments, transfers, and Open Finance operations. Network defenders should grep DNS, proxy, firewall, and EDR telemetry for outbound connections to the Sentry ingestion host below, and search repos, build definitions, and deployment scripts for PackageReference Include="Sicoob.Sdk", dotnet add package Sicoob.Sdk, and new SicoobClient(. More broadly: any SDK that handles certificates, private keys, OAuth tokens, or cloud credentials deserves stricter review than a typical dependency — and an allowlisted telemetry endpoint is not automatically a trusted one.

Indicators of Compromise

  • Malicious package: Sicoob.Sdk, versions 2.0.0–2.0.4 (NuGet owner sicoob)
  • Impersonation infrastructure: GitHub org Sicoob-Cooperativa; contributor account joaobcdev (both created May 4, 2026)
  • Exfiltration endpoint (Sentry DSN): hxxps://d565e3f03d0b1a7c8935d7ff94237316@o4511335034847232[.]ingest[.]de[.]sentry[.]io/4511337546317904
  • Sentry ingestion host: o4511335034847232[.]ingest[.]de[.]sentry[.]io
  • Untrusted-by-association package set: Sicoob-Cooperativa.Sicoob.{Auth, CobrancaV3, ContaCorrente, ConvenioPagamentos, Investimentos, OpenFinance, PagamentosPix, PagamentosV3, Pix, Poupanca, SpbTransferencias}
  • Code search patterns: PackageReference Include="Sicoob.Sdk", dotnet add package Sicoob.Sdk, new SicoobClient(

Sources