Malicious NuGet supply chain code turned Sicoob SDK trust into theft

At a glance

What this is: This is an analysis of a malicious NuGet supply-chain package that abused a banking SDK trust boundary to steal certificate-based credentials during normal construction.

Why it matters: It matters because identity and secrets governance now extends into dependency selection, build pipelines, and runtime certificate handling, where compromised packages can expose high-value non-human identities without triggering traditional access controls.

👉 Read Corgea's analysis of the malicious Sicoob NuGet supply-chain package

Context

A malicious package can become an identity breach when it sits inside the trust path for certificate-based authentication. In this case, the compromised NuGet artifact did not need to discover secrets on disk because developers and deployment jobs passed the client ID, PFX path, and PFX password directly into the SDK.

That is a different governance problem from ordinary malware scanning. The risk sits at the intersection of software supply chain security, secrets handling, and non-human identity control because a banking integration package effectively handled credentials on behalf of the workload that installed it.

Key questions

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. Instead of using the certificate only to authenticate to the intended service, the dependency can copy out the client ID, password, and private key material before the application ever makes a legitimate request. That turns routine initialisation into credential compromise.

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. The risk is amplified when teams pass secrets into constructors or deployment jobs, because the package does not need to search for credentials. It receives them as intended input.

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. In parallel, watch for exposed secrets and anomalous authentication from build systems. If those signals appear together, assume package trust is being used as an attack path.

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.

Technical breakdown

Constructor-time exfiltration in a trusted SDK

The malicious package used a dangerous pattern: it accepted authentication material as normal input, then copied that material out during object construction. In a healthy SDK, constructor logic should initialise local state and validate parameters, not transmit credentials. Here, the attacker relied on the developer assuming the package’s public API was safe because it resembled a legitimate banking integration library. That trust boundary matters because the exploit happens before downstream application logic, logging, or security middleware can intervene.

Practical implication: treat dependency constructors that process secrets as executable trust boundaries and review their behaviour before deployment.

Why certificate-based banking integrations are high value targets

mTLS integrations often depend on a private key inside a PFX archive plus a password to unlock it. If a malicious dependency captures both, it may enable impersonation of the application to upstream banking services, subject to server-side certificate binding and fraud controls. The danger is not limited to one API call. Once the certificate material is exposed, the attacker may reuse it across token issuance, payment operations, or account-data access until the credential is revoked.

Practical implication: isolate and monitor any workload that handles client certificates, because a single leaked PFX can outlive the immediate transaction.

Binary artifact review vs source repository review

This case shows why source-code review alone is insufficient for registry attacks. The visible GitHub source can look ordinary while the distributed compiled package contains extra exfiltration logic, a hardcoded Sentry DSN, and credential leakage that never appears in the repository. For defenders, the relevant object is the artifact that gets installed, not only the code that is published for inspection. That distinction is central to modern package governance across NuGet, npm, and PyPI.

Practical implication: validate the installed binary artifact, not just the repository, for dependencies that handle secrets or authentication material.

Threat narrative

Attacker objective: The attacker’s objective was to steal certificate-based banking credentials and use them to impersonate the victim’s Sicoob integration or resell the access.

1. Entry occurred when developers or build jobs installed the malicious NuGet package as a legitimate banking SDK for Sicoob API integration.
2. Credential access occurred when the constructor received the client ID, PFX path, and PFX password, then read and encoded the certificate material for exfiltration.
3. Impact followed when the stolen certificate material could enable impersonation of the banking integration, exposing payment, account, or Open Finance operations.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Certificate handling packages deserve privileged scrutiny because they sit on top of NHI trust. A workload certificate, its password, and the client identifier function together as a non-human identity bundle. If a dependency can capture all three at construction time, the organisation has effectively delegated credential custody to code it has not truly vetted. That breaks the assumption that a signed or familiar package is safe to execute with production secrets.

Binary artifact trust is the named failure mode here. The visible source looked normal, but the shipped NuGet artifact contained the malicious behaviour. This is the specific governance assumption that failed: teams assumed repository review was enough to validate the dependency they installed. Security programmes need to distinguish source trust from artifact trust, especially for libraries that touch secrets, certificates, or token material.

Secrets exposure in dependency code accelerates the shift from application risk to identity risk. Once a package can see production credentials, the compromise is no longer limited to the supply chain. It becomes a standing privilege problem because the malicious code inherits the same access path as the application. The practical conclusion is that identity controls must extend into package intake, not stop at the application boundary.

From our research:

• 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.
• From our research: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• For a deeper governance lens: Review the Guide to the Secret Sprawl Challenge for how hardcoded credentials, CI/CD exposure, and remediation controls intersect in practice.

What this signals

This incident signals that package governance now belongs inside identity governance programmes, not only software supply chain reviews. When a dependency can process certificate material, the workload’s secret boundary becomes part of the attack surface, and a package approval process without artifact validation is incomplete.

Binary artifact trust gap: the industry still overestimates what repository review can prove. For teams handling banking integrations or other certificate-backed workloads, the next control question is whether the installed binary has been evaluated as carefully as the published source.

The practical shift is toward tighter controls on secret-bearing dependencies, stronger egress monitoring for build and runtime environments, and more explicit ownership for certificate lifecycle events. Where the credential is also the identity, compromise speed matters, and revocation discipline becomes the decisive containment mechanism.

For practitioners

• 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.
• Hunt for suspicious outbound telemetry from build jobs Search endpoint, proxy, and egress logs for the Sentry ingestion host and related package activity, then correlate that telemetry with package installation windows.
• Reduce secret exposure inside CI/CD workflows Avoid passing long-lived banking credentials into build or deployment jobs unless the job absolutely requires them, and keep those credentials outside shared project variables where possible.

Key takeaways

• The breach pattern shows that a malicious dependency can steal banking credentials at the exact moment an application is supposed to authenticate.
• The evidence points to a source-and-artifact mismatch, which means repository review alone is not enough for secret-handling packages.
• Teams should treat certificate custody, dependency approval, and credential rotation as one governance problem, not three separate ones.

Key terms

• Binary Artifact Trust: The confidence an organisation places in the compiled package it actually installs, not just the source code it can inspect. In supply-chain attacks, the artifact may contain behaviour that never appears in the public repository, so trust must be verified at the binary level.
• Certificate-Based Workload Identity: A machine identity that uses a client certificate, private key, and often a password-protected PFX archive to authenticate to a service. If any part of that bundle is exposed, the workload can be impersonated until the certificate is revoked or replaced.
• Secret-Handling Dependency: A library that receives or manipulates credentials such as tokens, API keys, certificates, or passwords as part of normal operation. These dependencies deserve elevated scrutiny because compromise can directly expose authentication material rather than just corrupt application logic.
• Install-Time Exfiltration: The removal of data from a system during dependency installation rather than during normal application runtime. It is dangerous because it happens early, is often trusted by default, and can bypass controls that focus only on executed application features.

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

👉 The full Corgea post covers the binary artifact mismatch, exfiltration flow, and recommended response steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect identity controls to operational risk. It helps security teams build governance models that hold up when credentials move through code, pipelines, and runtime systems.