Sicoob.Sdk NuGet Certificate Exfiltration

Executive Summary

Socket published research on May 28, 2026 showing that NuGet package Sicoob.Sdk versions 2.0.0 through 2.0.4 impersonated an official Sicoob .NET SDK and exfiltrated banking API authentication material through Sentry telemetry [1]. Halting Problems downloaded the available NuGet artifacts and confirmed that the affected DLLs contain the hardcoded Sentry destination plus static selectors for SentrySdk, CaptureMessage, ReadAllBytes, ToBase64String, cliend_id:, and pass: in lib/net8.0/Sicoob.Sdk.dll [2], [3]. The package’s public source repository presents ordinary SDK behavior for loading a PFX certificate into an mTLS HTTP client, but the inspected SicoobClient.cs source does not contain the Sentry initialization or capture path observed in the distributed NuGet DLL [6].

This should be treated as a malicious package impersonation event, not a benign telemetry mistake. Any organization that installed or executed Sicoob.Sdk@2.0.0 through 2.0.4 with real Sicoob credentials should assume the supplied client ID, PFX archive contents, and PFX password were exposed unless local network and endpoint telemetry proves otherwise [1].

Key Facts

threat_type: "NuGet package impersonation and credential exfiltration"
ecosystem: "NuGet, .NET"
registry: "NuGet"
affected_packages:
  - "Sicoob.Sdk"
malicious_versions:
  - "2.0.0"
  - "2.0.1"
  - "2.0.2"
  - "2.0.3"
  - "2.0.4"
known_non_malicious_versions:
  - "1.0.0"
related_nuget_owner: "sicoob"
related_github_org: "Sicoob-Cooperativa"
exfiltration_endpoint_defanged: "hxxps://d565e3f03d0b1a7c8935d7ff94237316@o4511335034847232[.]ingest[.]de[.]sentry[.]io/4511337546317904"
credentials_at_risk:
  - "Sicoob API client IDs"
  - "PFX certificate archives"
  - "PFX passwords"
  - "Sicoob access tokens derived from exposed client credentials"
  - "raw boleto API response data"
confidence: "high"
attribution: "unknown"

Source Confidence and Claim Ledger

Claim	Status	Evidence
Sicoob.Sdk versions 2.0.0 through 2.0.4 exfiltrate client IDs, PFX passwords, and base64-encoded PFX contents through Sentry telemetry.	confirmed	Socket static and dynamic analysis, plus local artifact string verification for the affected NuGet packages [1], [2], [3].
The NuGet package set currently includes 1.0.0, 2.0.0, 2.0.1, 2.0.2, 2.0.3, and 2.0.4.	confirmed	NuGet flat-container index and registration metadata [2], [3].
The public GitHub repository is a source-to-package mismatch for the malicious behavior.	confirmed	The public SicoobClient.cs loads PFX material into X509Certificate2, while local package inspection and Socket’s IL excerpt show Sentry capture behavior in the DLL [1], [6].
Sicoob-Cooperativa should not be treated as an authorized Sicoob source without direct Sicoob confirmation.	likely	The GitHub org was created on 2026-05-04, is unverified, has zero followers, and differs from the older github[.]com/Sicoob account created in 2017 [4], [5].
Downstream financial API abuse, confirmed victims, or actor identity are known.	not_observed	No primary evidence in this collection names victims, successful fraud, or a threat actor.

What Happened

The malicious package used the trust position of a banking SDK. Socket reported that Sicoob.Sdk advertised itself as an official C# SDK for Sicoob API integrations and accepted a client ID, PFX file path, and PFX password as normal constructor inputs [1]. That is a plausible shape for an mTLS-based financial API client: a PFX archive can contain the client certificate and private key needed to authenticate the integration.

The abuse is in what happened next. Socket found that production-mode SicoobClient construction initialized Sentry, read the supplied PFX file from disk, base64-encoded it, and captured a Sentry message containing the client ID, plaintext PFX password, and encoded certificate material [1]. Our local package inspection confirmed that 2.0.0 through 2.0.4 carry the Sentry destination and the static string set needed to support that behavior in lib/net8.0/Sicoob.Sdk.dll [2], [3].

NuGet metadata and package contents also support the impersonation assessment. The package uses Sicoob branding, depends on many Sicoob-Cooperativa.Sicoob.* modules, and includes a Sentry dependency in the .nuspec files [3]. The linked GitHub organization Sicoob-Cooperativa was created on 2026-05-04, is not GitHub-verified, exposes no public members through the API, and has zero followers [4]. That posture is materially different from the older github[.]com/Sicoob account, created in 2017 and presenting itself as “Confederacao Nacional das Cooperativas do Sicoob” with a www.sicoob.com.br link [5].

Artifact and Provenance Notes

Halting Problems downloaded the available Sicoob.Sdk package artifacts from NuGet’s flat-container API on May 28, 2026. The package index still listed all six observed versions at collection time [2]. The SHA-256 values of the downloaded .nupkg files were:

artifact_hashes_sha256:
  Sicoob.Sdk@1.0.0: "87b66028e491573b787ee00bc81916241047e035d152dfbf4807b57c1bbbb043"
  Sicoob.Sdk@2.0.0: "7d2332e76c266509cdec8b552ccc839f50c28e6b01070071257bd3f57d1d9da2"
  Sicoob.Sdk@2.0.1: "f0dff53969080584560b2971411415bdf9064d5a5a50185c4ae018943e7d5cbe"
  Sicoob.Sdk@2.0.2: "94eb8da6703dd073184015c9e3cb34e9b6153fc499c9cb1a7db6e4361ec349dd"
  Sicoob.Sdk@2.0.3: "ac9dc55f13d973e05865e9674c8b8e6744e7fbfca3355199b292f614f13ac7bc"
  Sicoob.Sdk@2.0.4: "190dbcafa776e8cc221106414b8fbd68252d98438c5e46b8449788fbe70316a4"

The extracted .nuspec files include repository commit values, but not a repository URL. The public GitHub repository does have a SicoobClient.cs file that handles clientId, pfxPath, and pfxPassword for mTLS, but the inspected source lacks SentrySdk.Init, SentrySdk.CaptureMessage, the Sentry ingestion host, and a direct source-level PFX file exfiltration path [6]. That mismatch is a key reason this incident is classified as supply-chain abuse instead of a normal SDK defect.

Impact Determination

Classification	Criteria	Required action	Closure condition
Confirmed compromise	Sicoob.Sdk@2.0.0 through 2.0.4 executed and endpoint, proxy, EDR, or Sentry-ingest telemetry shows outbound activity to the listed Sentry host.	Isolate the executing host or runner, preserve package and network evidence, revoke Sicoob client IDs where possible, revoke and replace PFX certificates, and rotate PFX passwords from a clean system.	Replaced certificates and client IDs are in use, old material is rejected by Sicoob-side controls, and no suspicious token issuance or API activity remains unresolved.
Presumed exposed	Affected package version was installed, restored, built, imported, or used by an app or CI job that had real Sicoob PFX material, but telemetry cannot prove network exfiltration.	Treat the PFX archive, password, client ID, and any derived tokens as exposed. Rebuild from clean dependencies and audit financial API activity.	Every credential reachable from the affected runtime has been rotated or explicitly accepted by the risk owner.
Potentially exposed	Sicoob.Sdk appears in manifests, caches, lockfiles, packages, or code, but execution with real credentials is not established.	Collect package restore logs, application startup logs, endpoint telemetry, and secret-store access logs for the relevant period.	Each hit is dispositioned as confirmed compromise, presumed exposed, or not exposed.
Not exposed	No affected versions or indicators appear in source, lockfiles, package caches, build artifacts, endpoints, CI logs, proxy logs, or deployed services.	Preserve negative search output and block future use of the package identity.	Coverage includes developer endpoints, CI runners, production hosts, and NuGet caches.
Unknown	Package inventory, endpoint telemetry, network logs, Sicoob logs, or CI logs are unavailable.	Keep the asset in scope and prefer credential rotation for production banking credentials.	Missing evidence is recovered or the residual risk is formally accepted.

Downstream Abuse Audits

Credential responders should treat this as certificate compromise. Search Sicoob-side logs for token issuance, API calls, Pix operations, boleto operations, account balance or statement retrieval, payments, transfers, Open Finance consent activity, and source IP changes after any affected package execution [1]. Where Sicoob provides certificate thumbprint, client ID, mTLS, or OAuth audit fields, pivot on the client IDs and certificate identities that were supplied to SicoobClient.

CI/CD owners should identify every workflow, runner, deployment job, and secret store that had access to Sicoob PFX files or passwords. Look for NuGet restore of Sicoob.Sdk, PackageReference Include="Sicoob.Sdk", dotnet add package Sicoob.Sdk, application startup with new SicoobClient(, and outbound HTTPS connections to o4511335034847232[.]ingest[.]de[.]sentry[.]io. Rotate CI secrets even when only package execution is proven, because a build job that instantiated the SDK may have exposed production banking material [1].

Developer endpoint teams should search local NuGet caches, IDE build output, application logs, shell histories, and EDR network telemetry. A local developer test using production PFX material is enough to put the certificate archive and password at risk. Do not rely on sandbox tests as negative proof: Socket reported that the malicious path was tied to non-sandbox constructor behavior [1].

Registry and source-control owners should block Sicoob.Sdk and the sicoob NuGet owner in allowlist or package firewall policy until Sicoob confirms an authorized package path. Treat the related Sicoob-Cooperativa.Sicoob.* modules as untrusted by association even though Socket did not find the same standalone Sentry PFX exfiltration logic in those module packages [1].

Indicators of Compromise

packages:
  - "Sicoob.Sdk@2.0.0"
  - "Sicoob.Sdk@2.0.1"
  - "Sicoob.Sdk@2.0.2"
  - "Sicoob.Sdk@2.0.3"
  - "Sicoob.Sdk@2.0.4"
domains:
  - "o4511335034847232[.]ingest[.]de[.]sentry[.]io"
urls:
  - "hxxps://d565e3f03d0b1a7c8935d7ff94237316@o4511335034847232[.]ingest[.]de[.]sentry[.]io/4511337546317904"
files:
  - "lib/net8.0/Sicoob.Sdk.dll"
hashes:
  - "7d2332e76c266509cdec8b552ccc839f50c28e6b01070071257bd3f57d1d9da2"
  - "f0dff53969080584560b2971411415bdf9064d5a5a50185c4ae018943e7d5cbe"
  - "94eb8da6703dd073184015c9e3cb34e9b6153fc499c9cb1a7db6e4361ec349dd"
  - "ac9dc55f13d973e05865e9674c8b8e6744e7fbfca3355199b292f614f13ac7bc"
  - "190dbcafa776e8cc221106414b8fbd68252d98438c5e46b8449788fbe70316a4"
telemetry_selectors:
  - "PackageReference Include=\"Sicoob.Sdk\""
  - "dotnet add package Sicoob.Sdk"
  - "new SicoobClient("
  - "cliend_id:"
  - "pass:"
  - "Boleto:"
  - "SentrySdk"
  - "CaptureMessage"
  - "ReadAllBytes"
  - "ToBase64String"

Detection and Hunting

Use the repository audit script to scan source trees, exported logs, NuGet caches, and .nupkg files for the affected package, constructor usage, Sentry endpoint, and DLL static selectors:

python3 scripts/threat-posts/sicoob_sdk_audit.py /path/to/repos /path/to/exported/logs ~/.nuget/packages --output sicoob-audit --fail-on-hit

Use the artifact verifier to redownload the NuGet artifacts, validate the known SHA-256 values, and confirm the malicious static selectors in affected DLLs:

python3 scripts/threat-posts/sicoob_sdk_nupkg_verify.py --output sicoob-nupkg-verify

Suggested SIEM query pivots:

("Sicoob.Sdk" OR "SicoobClient(" OR "PackageReference Include=\"Sicoob.Sdk\"")
("o4511335034847232.ingest.de.sentry.io" OR "4511337546317904" OR "d565e3f03d0b1a7c8935d7ff94237316")
("cliend_id:" AND "pass:" AND "SentrySdk")

Positive signals are affected package versions in dependency inventory, affected .nupkg hashes in package caches, constructor execution on hosts with PFX files, or outbound network telemetry to the Sentry ingestion host. Escalate immediately when any positive signal is tied to production credentials, release runners, deployment jobs, secret stores, or financial API clients.

Remediation

Containment: block Sicoob.Sdk in NuGet package policy, remove the package from source and lockfiles, isolate hosts or runners that executed affected versions with real credentials, and preserve the affected .nupkg, build logs, process telemetry, and network logs.

Eradication: replace the dependency only through a Sicoob-controlled and independently verified source path. Delete affected NuGet caches on developer workstations, CI runners, build images, and deployment hosts. Rebuild release artifacts from clean dependency state.

Credential recovery: revoke and replace any PFX certificates supplied to affected versions, rotate PFX passwords, rotate or disable exposed client IDs where Sicoob controls allow it, invalidate derived access tokens, and review Sicoob API audit logs for suspicious token issuance or financial operations.

Closure gates: all affected versions are absent from source, lockfiles, caches, images, and deployments; old certificates and passwords no longer authenticate; Sicoob API logs have been reviewed for the exposure window; and package allowlist controls prevent accidental reintroduction.

Open Questions

• NuGet package web UI state and download counts were not independently captured in this run; Socket reported package blocking and 484 total downloads during its investigation [1].
• No public Sicoob, Sentry, or NuGet incident advisory was located during this collection.
• Victim identities, actor identity, and confirmed downstream financial API abuse remain unknown.

Sources

1. Socket: Malicious NuGet Package Impersonates Sicoob SDK to Exfiltrate Banking Certificates and Passwords
2. NuGet flat-container index for Sicoob.Sdk
3. NuGet registration index for Sicoob.Sdk
4. GitHub API: Sicoob-Cooperativa organization
5. GitHub API: Sicoob account
6. Sicoob-Cooperativa public SicoobClient.cs source