TL;DR: A malicious NuGet package posing as Sicoob.Sdk 2.0.0 through 2.0.4 exfiltrated client IDs, PFX paths, PFX passwords, and certificate material at constructor time, according to Corgea. The pattern shows how supply-chain trust collapses when packages that handle banking authentication material can leak secrets before any visible API call.
NHIMG editorial — based on content published by Corgea covering the malicious Sicoob NuGet package: Sicoob.Sdk supply-chain abuse and credential exfiltration
Questions worth separating out
Q: What breaks when a package that handles certificates is malicious?
A: The trust boundary breaks at the point where the package receives production secrets.
Q: Why do banking SDKs create such high-value supply-chain risk?
A: Banking SDKs often sit directly on certificate-based authentication paths, so a malicious update can capture the exact material needed to impersonate a workload.
Q: How can security teams tell whether package trust is being abused in their environment?
A: Look for unusual repository creation patterns, sudden publisher changes, transitive dependencies from unfamiliar accounts, and CI activity that reaches out to new domains.
Practitioner guidance
- Review certificate-handling dependencies as privileged code Inventory every library that accepts client IDs, PFX files, passwords, tokens, or signing keys, then require higher review standards before it enters a production build path.
- Validate installed artifacts, not just repositories Compare package hashes, inspect compiled binaries where feasible, and require artifact provenance checks for NuGet packages that process authentication material.
- Rotate exposed banking credentials immediately If the malicious package reached a production environment, revoke and reissue the PFX certificate, rotate the PFX password, and disable or replace the affected client ID where possible.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Constructor-level exfiltration logic and the exact Sentry call flow used to leak client ID and PFX material
- Package family mapping across the Sicoob-Cooperativa modules and the related untrusted publishing identity
- Detection leads for package manifests, lockfiles, and outbound telemetry from build environments
- Response steps for revoking certificates, rotating passwords, and checking for unusual banking API activity
👉 Read Corgea's analysis of the malicious Sicoob NuGet supply-chain package →
Malicious Sicoob NuGet packages: what identity and access teams missed?
Explore further
This is supply-chain identity theft, not just malware. When a package that handles mTLS credentials becomes the exfiltration point, the compromise moves inside the identity layer of the application itself. That means the control gap is not only code scanning, but governance over which binaries are trusted to process certificates, client IDs, and secrets. Practitioners should treat package provenance as part of identity governance for workloads.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
A question worth separating out:
Q: Who is accountable when a compromised dependency exposes production secrets?
A: Accountability is shared across application, platform, and identity teams because the failure spans dependency control, secret exposure, and workload access governance. Security frameworks expect organisations to reduce attack surface, but the practical answer is to remove reusable secrets from places untrusted code can reach and to log every runtime credential handoff.
👉 Read our full editorial: Malicious NuGet supply chain code turned Sicoob SDK trust into theft