Malicious NuGet supply chain code turned Sicoob SDK trust into theft

At a glance

What this is: A malicious Sicoob NuGet package hid credential theft inside normal SDK construction, leaking banking certificate material and passwords as soon as developers instantiated the client.

Why it matters: IAM, PAM, and NHI teams should treat dependency trust as part of credential governance when packages process certificates, tokens, or other secrets in build and runtime paths.

Context

A supply-chain compromise becomes especially dangerous when the malicious code sits inside the library that is supposed to authenticate a service. In this case, the package requested production banking material and then used that same trusted flow to steal it, which is a direct identity and secrets-governance failure.

The risk is not only code provenance but also where secrets are handed over and who can observe them during execution. When a client library receives certificate paths, passwords, or tokens as constructor inputs, the trust boundary moves from the application into the dependency itself.

Key questions

Q: What breaks when a malicious SDK receives certificate material at construction time?

A: The trust model breaks because the dependency becomes a privileged observer of secrets before the application can authenticate anything or detect abuse. If a constructor accepts client IDs, certificate paths, and passwords, malicious code can extract them immediately and reuse the same call path for exfiltration. That turns normal integration setup into a credential compromise event.

Q: Why do malicious package implants create fraud risk as well as data theft?

A: Because stolen certificate material and client credentials can often be reused to impersonate an integration, not just read configuration data. In banking and payments, that can enable unauthorized token issuance, account-data access, or payment actions depending on the issuer’s binding and monitoring controls. The security incident therefore becomes a potential fraud problem.

Q: What are the signs that a dependency is hiding secret exfiltration logic?

A: Watch for unusual outbound telemetry calls, hardcoded ingestion endpoints, secret handling inside constructors, and binary artifacts that do things not present in the visible source. A package that loads certificate files and immediately serializes them to an external service is not merely diagnostic. It is behaving like a credential collector.

Q: How should teams govern third-party SDKs that handle non-human identity secrets?

A: They should require binary artifact review, strict package allowlisting, and explicit approval for any dependency that touches certificates, tokens, or signing material. The question is not whether the package is popular. The question is whether it can observe or transform authentication secrets outside the application’s control boundary.

Technical breakdown

Constructor-time secret capture in trusted SDKs

The core mechanism is simple and dangerous: a developer creates the client object, passes in the client ID, PFX path, and PFX password, and the package immediately processes those values inside its own code path. That means the dependency sees the secrets at the point they are most valuable, before any external API exchange or authentication success is visible to defenders. In security terms, this is a supply-chain trust violation embedded in the application onboarding path, not a later runtime exploit.

Practical implication: treat dependency constructors that accept secrets as high-risk trust boundaries and review their binary behavior, not just their source claims.

Why mTLS SDKs create a stronger secret-handling surface

Mutual TLS SDKs often need to load private key material, certificate files, and passwords from application-controlled storage, which makes them unusually sensitive to malicious behavior. A package that handles this workflow can convert legitimate authentication inputs into exfiltration material without needing filesystem discovery or separate privilege escalation. The malicious code also used a hardcoded outbound telemetry path, which is a common technique for disguising secret theft as diagnostics or error reporting.

Practical implication: constrain which dependencies are allowed to touch certificate material and require outbound destination review for any SDK that handles authentication secrets.

Binary artifact review versus repository trust

The source-facing repository can look clean while the published package contains compiled logic that never appears in the visible code review path. That split matters because defenders often trust the upstream GitHub project and assume the registry artifact is equivalent. In this pattern, the package manager is the delivery mechanism, but the compiled DLL is the true attack surface. For banking and payment integrations, artifact integrity is as important as package naming or maintainer identity.

Practical implication: verify the installed package artifact itself with dependency scanning, hash checks, and policy gates before allowing it into production pipelines.

Threat narrative

Attacker objective: The attacker objective was to steal banking authentication material that could be reused to impersonate the victim’s Sicoob integration and access financial functions.

1. Entry occurred when developers installed Sicoob.Sdk 2.0.0 through 2.0.4 from NuGet under a trusted banking SDK name.
2. Credential access happened during constructor execution, where the package captured client IDs, PFX paths, PFX passwords, and certificate bytes.
3. Exfiltration followed through a hardcoded Sentry endpoint that carried the certificate material and authentication secrets out of the environment.
4. Impact was potential impersonation of the banking integration, with downstream risk to token issuance, Pix, boleto, and account-data activity.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply-chain trust must now include secret-handling behavior, not just package provenance. A package that accepts certificate paths and passwords becomes part of the credential control plane the moment it is instantiated. That means dependency review has to ask what the binary does with secrets, not only whether the repository looks legitimate. Practitioners should treat authentication-capable SDKs as governed secret processors, not ordinary libraries.

Binary artifact integrity is the governance gap this incident exposes. The visible source and the published package diverged, which means source review alone is an incomplete control for banking and payment integrations. That is a classic case of repository trust being over-extended to registry artifacts. Teams that rely on package names or GitHub presence without binary validation are accepting a false assurance model.

Constructor-time exfiltration is a named failure mode worth tracking. This pattern takes effect before any obvious business action, which makes detection later in the flow too late for credential protection. The real control gap is that secrets are handed to untrusted code at creation time and then assumed to remain inside the process boundary. Practitioners should move review and policy enforcement to the moment secrets are first passed into dependencies.

Banking SDKs collapse the line between application logic and identity governance. When an SDK processes mTLS certificates, client IDs, and passwords, it is operating inside the organisation’s authentication architecture even if it is supplied by a third party. That creates a direct intersection between software supply chain risk and IAM control ownership. Security and IAM teams should align on package approval criteria for any dependency that touches certificates, tokens, or other non-human identity material.

Compromise of the dependency layer can create downstream financial fraud exposure, not just technical data theft. If certificate material and passwords are stolen, the result can be unauthorized banking API use, payment abuse, or statement access depending on the binding controls in place. That shifts the conversation from malware detection to identity-bound transaction governance. Practitioners should assume that stolen integration credentials can become a fraud pathway as well as a security incident.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: API Key Management Guide

What this signals

Constructor-time secret exfiltration: this is the failure pattern defenders need to name when dependencies accept secrets as part of normal object creation. Once a package can read certificates and passwords in the constructor, traditional source review is too late, because the secret has already crossed into untrusted code.

Banking and payment SDKs should be treated as identity infrastructure, not just application dependencies. The relevant control question is whether a package can observe, serialize, or export non-human identity material such as certificates, client IDs, and passwords before the first authenticated transaction.

Teams running CI/CD for financial integrations need to move package trust checks left of deployment and right of repository reputation. If the installed artifact is not verified, the pipeline can become the exfiltration path for the same secrets it was meant to protect.

For practitioners

• Audit dependencies that process certificate material Inventory SDKs and packages that accept client IDs, PFX files, private keys, OAuth tokens, or passwords, then review their compiled behavior and outbound destinations before approval.
• Block registry artifacts with source and binary mismatch Require that the installed package hash, signed metadata, and compiled contents match the expected release before the dependency reaches CI/CD or production deployment.
• Rotate exposed banking integration secrets If the package was used, revoke and reissue affected certificates, reset PFX passwords, disable or replace impacted client IDs where possible, and inspect API logs for abnormal banking activity.
• Scan pipelines for secret-bearing constructor calls Search application code and build jobs for client constructors that receive production secrets, especially where package installation and runtime credential handling occur in the same pipeline.

Key takeaways

• This incident shows that a trusted-looking SDK can turn certificate onboarding into secret theft the moment it is instantiated.
• The compromise matters because stolen PFX material and passwords can enable impersonation of a banking integration, not just configuration exposure.
• The strongest preventive control is to verify the binary artifact and restrict which dependencies are allowed to handle authentication secrets.

Key terms

• Constructor-time Exfiltration: Constructor-time exfiltration is the theft of secrets when an object is created, before the application performs any business action. In malicious dependencies, the constructor can read certificates, passwords, or tokens and immediately send them to an external endpoint, making normal instantiation itself the attack trigger.
• Binary Artifact Mismatch: Binary artifact mismatch occurs when the published package does not behave like the visible source code suggests. The repository may look clean, but the compiled artifact includes additional logic or dependencies, so trust based only on source review is incomplete for supply-chain security.
• Mutual TLS Credential Material: Mutual TLS credential material is the certificate, private key, and password set used to authenticate a client to a server. In regulated integrations, this material often enables non-human identity access, so theft can lead directly to impersonation, payment abuse, or privileged API use.
• Software Supply Chain Trust Boundary: The software supply chain trust boundary is the point where an organization decides which software components, build systems, dependencies, and delivery steps it will trust. It defines where verification must occur. Technically, it includes source, build, signing, packaging, distribution, and update paths, plus the identities and controls that govern each stage.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps IAM, PAM, and security teams build controls for credentials that move through applications, pipelines, and third-party dependencies.