Typosquatted NuGet 'Sicoob.Sdk' Hoovers PFX Certs From Brazilian Banks
A poisoned package impersonating Brazil's Sicoob co-op banking network exfiltrates client IDs and PFX certificates — the same certs that sign API calls into the financial system.
Another package registry, another supply-chain story. This one stings because the target is regulated banking infrastructure.
Researchers at Socket flagged a NuGet package named Sicoob.Sdk, versions 2.0.0 through 2.0.4, that pretends to be a C# SDK for Sicoob — one of Brazil's largest cooperative financial systems. The package isn't an SDK. It's an exfiltration tool wearing one as a costume.
The malicious versions pull client IDs and PFX certificate files off the host and ship them to attacker-controlled infrastructure. If you've never had to wrangle Brazilian open-banking integrations: PFX certs are the keys to the kingdom. They authenticate the application to Sicoob's APIs, and in practice they're often bundled with the private key and a password the dev hardcoded six sprints ago.
Steal the PFX, steal the session.
The failure mode here is the one we keep writing about. A developer searches NuGet for an integration library, sees a package name that matches the bank, checks the version count, and dotnet add packages it into a service that already has secrets mounted. There's no signature verification step in most CI pipelines that would catch a typosquat against a vendor that doesn't publish an official NuGet at all. Sicoob distributes integration samples through its own developer portal, not the public registry — which is exactly the gap squatters exploit.
A few things worth saying plainly.
PFX files should not be sitting on developer laptops or in build agents in a form that any in-process code can read. If your .NET service loads the cert via X509Certificate2(path, password) from a file on disk, anything running in that process — including a transitive dependency — can read the same bytes. Move them into a managed store. Azure Key Vault, AWS Certificate Manager, GCP Secret Manager. Pick one. Rotate the cert if you've ever installed the bad package, because you have to assume the private key is gone.
The other lesson, again: registry hygiene. NuGet, npm, PyPI — they're all the same threat surface now. Scope your allowlists. Pin versions. Treat a new dependency the way you'd treat a new outbound firewall rule. One thing the post-mortem will say is that nobody owned the question of which packages were allowed to reach prod.
Sicoob has not, as of writing, published a security advisory on its developer portal. The malicious package was removed from NuGet after disclosure, but cached copies in private proxies and build artifacts will linger.
Operational takeaway: grep your .csproj files for Sicoob.Sdk, revoke any PFX that touched a machine where it ran, and assume the credential is burned.
