top of page

Sicoob.Sdk v2.0.4 Stole Brazilian Banking PFX Certificates Through Sentry Telemetry. Google's AI Search Recommended It. The Trust-Path Bleed Just Crossed Three Vendor Surfaces At Once.

  • Writer: Patrick Duggan
    Patrick Duggan
  • 39 minutes ago
  • 7 min read

Socket Research published a writeup this week on a malicious NuGet package named Sicoob.Sdk that impersonated the official C# SDK for Sicoob, the Brazilian cooperative-banking network that handles savings, Pix instant payments, Open Finance integrations, and Boleto payment slips for millions of Brazilian consumers and small businesses. The package shipped versions 2.0.0 through 2.0.4 between May 5 and May 6, 2026. Total downloads: four hundred eighty-four. Small N. Each victim is a developer integrating production banking APIs. The per-victim consequence is the kind that ends careers.


The exfiltration channel is what makes this post worth writing. The malicious package used Sentry telemetry as the data path out. The trust-path-bleed frame we have been writing for two months — npm publish trust, GitHub Actions workflow trust, VS Code Marketplace extension trust, VS Code Tunnels runtime trust, Cloudflare-protected origin trust — just crossed into a fourth vendor surface this week. Sentry is the error-monitoring SaaS that nearly every modern application in production runs as a default. Sentry traffic is the legitimate-trust-flow defenders do not block. The attacker hardcoded a Sentry DSN, initialized the Sentry SDK from inside the malicious constructor, and shipped the victim's banking credentials out as SentrySdk.CaptureMessage() calls. The traffic looked like every other application's error reports because it was, by construction, identical Sentry ingestion traffic.



What Sicoob.Sdk Did


When a developer integrated the malicious NuGet package and instantiated SicoobClient in their .NET application, the constructor triggered exfiltration. The credentials harvested in the production code path:


  • Client IDs — the runtime-supplied API authentication identifier

  • PFX passwords — the plaintext key used to unlock the client's certificate archive

  • Base64-encoded PFX contents — the certificate archive itself, containing the client certificate and the private key

  • Boleto API responses — Brazilian payment-slip transaction data including amounts, due dates, and payer/payee identification

The hardcoded Sentry DSN is in the writeup verbatim. The Sentry ingestion endpoint is o4511335034847232.ingest.de.sentry.io with project ID 4511337546317904 and public key [d565e3f03d0b1a7c8935d7ff94237316](https://analytics.dugganusa.com/stix/register?ref=hash-click&q=d565e3f03d0b1a7c8935d7ff94237316). The DSN routes through Sentry's German ingest cluster — legitimate Sentry infrastructure, not attacker-owned, which is exactly the design feature that makes the exfiltration channel hard to block at the network egress tier.


The exfiltration is conditionally gated. The Sentry-init logic runs only when the client is configured for production mode — that is, isSandbox = false. Developers testing against Sicoob's sandbox API see clean behavior. Developers wired up to live banking — where the certificates actually authorize real transactions — get their credentials shipped to the attacker. The conditional sandbox-vs-production gating is operator discipline. The package is written by someone who knew the developer-workflow shape and timed the exfiltration to the moment of maximum payload value.



The GitHub Repository Was Clean


The attacker registered a GitHub organization named Sicoob-Cooperativa on May 4, 2026 — one day before the NuGet package's first version went live. A GitHub account named joaobcdev was created minutes after the organization. The GitHub repository at github.com/Sicoob-Cooperativa/sicoob_sdk_csharp displayed ordinary SDK code: PFX certificate loading for mutual TLS authentication to the Sicoob API, the kind of code a Brazilian fintech engineer would review and approve as a dependency. The package distributed to NuGet contained additional code that did not appear in the GitHub repository: SentrySdk.Init(), File.ReadAllBytes(), Convert.ToBase64String(), and the credential transmission logic.


This is the source-to-package mismatch that Gabor Koos's npm evaluation methodology — published yesterday morning at gaborkoos.com and discussed in this blog earlier — names as the single most important verification step before installing a dependency. Koos's prescription for npm is the green provenance badge plus npm audit signatures. The NuGet ecosystem does not have the equivalent default. NuGet supports cryptographic package signing, but it does not run a Trusted-Publishing OIDC-attestation mechanism comparable to npm's provenance feature, and most NuGet packages in production today are not signed by their authors. The defender who relies on the GitHub repository to vouch for the NuGet artifact has no cryptographic chain to confirm the two are the same code. The Sicoob.Sdk publish is the receipt for that gap.



The Google AI Search Recommendation


The Socket writeup includes a detail worth dwelling on for what it implies about the broader 2026 ecosystem. The malicious package was surfaced by Google's AI search as the standard .NET Sicoob integration path during the window the package was live. A developer asking Google "how do I integrate Sicoob with C#" got the malicious Sicoob.Sdk package as the recommended answer. This is the same trust-laundering shape Gabor Koos named as slopsquatting in his npm methodology — LLMs hallucinate or surface plausible-sounding package names, attackers register those names, developers follow the recommendation without checking. Slopsquatting in Koos's framing was specifically about coding-assistant AI suggestions during a development session. The Sicoob.Sdk receipt extends the surface: a general-purpose AI search interface used by developers as the starting point of their integration research is functionally equivalent to a coding assistant for this purpose. The trust-laundering pathway is the same. The exploited surface is broader than the coding-assistant case.



The Operator Discipline


Four hundred eighty-four downloads is small. The attacker chose small. The targeting is by integration vertical, not by mass distribution. Anyone who downloaded the Sicoob.Sdk package is, by selection bias, a developer integrating Brazilian cooperative-banking APIs against production banking infrastructure. Each compromised certificate is an authorization token against real-money banking endpoints. The blast radius is small in count and immense in per-event consequence. The economics from the operator's perspective are inverted relative to mass-malware: low N, high per-N, and the operator population that runs this attack vector understands the inversion well.


The operator discipline in the eleven additional packages published by the same sicoob NuGet owner — Sicoob-Cooperativa.Sicoob.Auth, Sicoob-Cooperativa.Sicoob.Pix, Sicoob-Cooperativa.Sicoob.OpenFinance, and eight more in the dependency chain — is a second layer of operator discipline. The companion packages do not carry the Sentry exfiltration logic. They look clean on independent inspection. But their existence as a published dependency graph makes the malicious Sicoob.Sdk package look more legitimate at the publisher-consistency layer that some developer-tier package auditors use to gut-check trust. The operator is not just shipping one malicious package. The operator is shipping an entire fake-publisher artifact set, with the malicious payload concentrated in the package most developers will reach for first.



Three Vendor Surfaces, One Attack Chain


Read the full chain and the trust-path-bleed frame collapses three distinct legitimate-vendor surfaces into a single attack:


  1. GitHub — used to host a clean, audit-passing repository under the Sicoob-Cooperativa impersonation organization. Developers reviewing the repo before integrating saw expected code. The GitHub source-of-truth signal was weaponized.

  2. NuGet — used to publish the package as the standard discoverable .NET dependency. The published artifact contained code absent from the source repository. The registry-publishes-source-of-truth signal was weaponized.

  3. Sentry — used as the exfiltration channel. The legitimate error-monitoring SaaS traffic to a real Sentry-hosted ingest endpoint was the cover. The network-egress-trust signal was weaponized.

This is the soft-surface-bleed frame applied across the .NET developer's entire trust-chain in one operation. The hard perimeter holds. The soft surfaces — the trust paths between systems — bleed across three vendor identities in series. The defender posture that monitors each vendor in isolation does not catch this. The defender posture that asks "is this artifact's source-of-truth, distribution, and runtime telemetry consistent across vendors" catches it. That cross-vendor consistency check is not a feature any single vendor's product can provide because no single vendor sees the chain.



What This Costs Defenders


The Socket disclosure prompted Sicoob's security team, Sentry's security team, and NuGet's security team to coordinate. Sentry investigated the abusive project. NuGet blocked the package. The disclosure cycle worked the way the responsible-disclosure model is designed to work. The remediation question is harder.


For Brazilian financial-services organizations whose developers may have integrated the malicious package between May 5 and the takedown: every PFX certificate exposed to that integration must be assumed compromised. The certificate rotation cost is not trivial. PFX certificates against Sicoob's API are the authorization token for real-time payment operations. Revocation and re-issuance during a banking-business-hours window has downstream cost across every consuming application. The plaintext PFX password storage in the constructor is the part of the attack that closes the impact loop — once the password and the encrypted PFX contents have both been exfiltrated, the attacker has bearer credentials against the banking API for as long as the certificate remains valid.


For the broader .NET supply-chain defender population: this is the first publicly-reported case we have read where Sentry telemetry was the exfiltration channel for a registry-distributed malicious package. The pattern will not be the last. Sentry is one of dozens of legitimate developer-tooling SaaS surfaces with low-friction client SDKs that initialize from a hardcoded DSN. Datadog, Honeycomb, New Relic, Rollbar, Bugsnag, Mixpanel, Segment, Amplitude — every observability and analytics vendor whose client SDK accepts arbitrary user-supplied event payloads is a potential candidate for the same exfiltration pattern. The defender egress monitoring at the FQDN tier blocks none of them by default.



The Broader Frame


This is the soft-surface-bleed playbook with a new color of paint and a Brazilian banking target. NuGet was the registry. Sentry was the exfil. Google AI search was the trust-launderer. The trust-path-bleed across three legitimate vendor surfaces in one chain is the recognizable shape of operator iteration in 2026 — operators are not building new offensive primitives, they are recombining legitimate trust surfaces in new sequences faster than the defender posture is calibrating.


The defender posture that follows is the one we have been writing all month. Audit the publish path on every package you depend on, not just the source repository. Apply Koos's npm evaluation methodology and its NuGet equivalent (still being defined — provenance is the gap to file). Inspect the SDK's outbound traffic destination set, not just whether the destination is on a known-good list. Treat every observability and analytics SaaS as a potential dual-use channel. Cross-check artifact provenance across the source, distribution, and runtime tiers — not at any single tier in isolation.


The receipts compound. Yesterday's TanStack postmortem was npm. Yesterday morning's Malware-Slop was npm. Yesterday's Nx Console federal mandate was VS Code Marketplace. This morning's Kimsuky update was VS Code Tunnels. This week's Sicoob.Sdk is NuGet plus Sentry plus Google AI search. The trust-path-bleed frame is now active across at least seven vendor surfaces in series across the last sixty days of public reporting. The defender mental model that treats each surface in isolation is one cycle behind the operator population.


The Socket Research team gets the primary-research credit on this one. We are downstream of their disclosure and our contribution is the cross-corpus correlation — the Sicoob.Sdk Sentry DSN and ingest endpoint go into our iocs index tonight under the source tag research-import-socket-sicoob-2026-05-30, joining the small but growing set of NuGet-tier supply-chain atoms our corpus has indexed (one record before today; three after tonight). The receipts persist regardless of whether the operator population iterates the technique next week.




How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.


bottom of page