Malicious NuGet Package Impersonates Sicoob SDK to Steal Banking Certificates and Passwords

A malicious NuGet package impersonating a Sicoob software development kit was caught stealing banking authentication material from .NET applications, including client IDs, PFX certificate files, and plaintext PFX passwords.

The package, named Sicoob.Sdk, was analyzed by Socket, which said versions 2.0.0 through 2.0.4 exfiltrated sensitive data through a hardcoded third-party Sentry endpoint. The package has since been blocked by NuGet after abuse reports.

The attack targeted developers building integrations with Brazil’s Sicoob banking APIs. That made the package especially dangerous because banking SDKs often handle real certificates, private keys, passwords, client IDs, and payment data during normal application startup.

What the Malicious Sicoob.Sdk Package Did

The package presented itself as a .NET 8 SDK for Sicoob API integrations. Its public-facing description suggested that it handled authentication, mutual TLS certificates, and access to Sicoob financial and non-financial APIs.

That claim matched what a developer might expect from a banking integration. The official Sicoob developer portal provides access to financial services and APIs, which means developers may search for SDKs or helper libraries to simplify integration work.

The hidden behavior appeared when a developer created a SicoobClient instance with production credentials. The malicious DLL read the PFX certificate file from disk, encoded it, and sent it with the client ID and PFX password to an external Sentry project.

Stolen data	Why it matters
Client ID	Identifies the application or banking integration
PFX certificate archive	May contain the certificate and private key used for mutual TLS
PFX password	Can unlock the certificate archive
Boleto API responses	May expose payment status, amounts, due dates, and payer or payee details

Why PFX Theft Creates Serious Banking Risk

A PFX file is not just a normal configuration file. It often contains a client certificate and private key used to prove an application’s identity during mutual TLS authentication.

If attackers obtain both the PFX archive and its password, they may be able to impersonate a legitimate banking integration, depending on Sicoob-side controls, API permissions, certificate binding, and fraud detection rules.

That makes this attack more serious than ordinary package telemetry abuse. The malicious package placed the exfiltration logic inside the exact part of the SDK where developers were expected to provide sensitive production credentials.

The NuGet Package Looked Legitimate at First Glance

Attackers used branding and naming to make the package appear trustworthy. Sicoob.Sdk claimed to be an official C# SDK and linked to a GitHub organization that also used Sicoob-related naming.

Socket’s investigation found multiple red flags around that identity. The GitHub organization was newly created, unverified, had no visible public members, and did not have a Sicoob-controlled reverse reference confirming that it was authorized.

The source code visible in the linked GitHub repository also did not include the malicious Sentry exfiltration logic. That mismatch suggests a deliberate source-to-package gap, where a clean-looking repository served as a trust façade while the NuGet artifact carried the real malicious behavior.

How Sentry Was Abused for Exfiltration

The package did not use a typical command-and-control server. Instead, it abused Sentry, a legitimate monitoring and error-reporting platform, to send stolen credentials as telemetry.

This approach can help attackers blend into normal developer or production traffic. Many organizations allow telemetry tools through firewalls and proxy systems, so outbound Sentry traffic may not look suspicious at first.

In this case, the data was not reasonable diagnostic telemetry. A legitimate SDK might report sanitized metadata, such as a certificate thumbprint or an error code. It should not transmit a full certificate archive or the password needed to use it.

Which Versions Were Affected

The confirmed malicious versions were Sicoob.Sdk 2.0.0 through 2.0.4. Socket reported that the package reached 484 downloads across multiple versions before NuGet blocked it.

The same NuGet publisher also hosted other Sicoob-branded packages. Those related packages did not independently show the same Sentry-based PFX exfiltration logic in Socket’s analysis, but they remain risky because they came from the same suspicious publishing identity.

Developers should not replace the package with another module from the same publisher. Any Sicoob integration should come only from channels verified through the official Sicoob developer portal or direct bank-approved documentation.

What Affected Teams Should Do Immediately

Organizations that installed Sicoob.Sdk should remove it immediately and determine whether any developer workstation, CI job, build agent, staging environment, or production service created SicoobClient with real credentials.

If real credentials were used, teams should treat the PFX certificate, PFX password, and client ID as compromised. They should revoke and replace affected certificates, rotate passwords, and review Sicoob API logs for unusual activity.

Teams should also check build logs, package restore logs, deployment pipelines, and production telemetry for signs that affected versions ran in environments with live banking credentials.

• Remove Sicoob.Sdk from all projects and build systems.
• Search package lock files for versions 2.0.0 through 2.0.4.
• Revoke and replace any PFX certificate used with the package.
• Rotate PFX passwords and related client IDs where possible.
• Review Sicoob API activity for unusual authentication, Pix, boleto, payment, or Open Finance activity.
• Check DNS, proxy, firewall, and EDR logs for outbound traffic to the reported Sentry ingest endpoint.
• Audit CI/CD secrets, deployment variables, and mounted certificate stores.

How Developers Can Reduce NuGet Supply Chain Risk

This incident shows why dependency review matters most when a package handles authentication material. Banking SDKs, cloud SDKs, payment SDKs, identity libraries, and signing tools should receive stricter checks than ordinary utility packages.

Microsoft recommends NuGet Package Source Mapping as one way to improve supply chain security, especially when organizations use both public and private package sources. Source mapping lets teams define which package names can restore from which source.

That control would not automatically detect malicious behavior inside a package, but it can reduce dependency confusion and accidental restores from untrusted sources. It also gives teams a clearer policy for packages that should only come from internal or verified repositories.

Control	How it helps
Package source mapping	Limits which sources can provide specific package names
Lock files	Help detect unexpected version changes
Signed packages	Support integrity and origin checks when properly used
Private mirrors	Allow security teams to review packages before internal use
Secret scanning	Finds credentials exposed in repositories or pipelines

Package Signing and Review Still Matter

Microsoft’s NuGet package signing guidance says signed packages help with content integrity verification and package authenticity. That can make tampering harder to hide when teams require trusted signatures.

Package signing alone does not prove that a package is safe. A malicious publisher can still sign malicious code. But signing, source mapping, lock files, private package feeds, and human review together create stronger defenses than trusting names and logos alone.

For high-risk SDKs, teams should compare source repositories with compiled package contents. The Sicoob.Sdk case shows why a clean GitHub repository cannot prove that the package on NuGet contains the same code.

Why Financial SDKs Are Attractive Targets

Financial integrations often run in privileged environments. They may process payment instructions, account data, Pix transactions, boleto records, certificates, secrets, and production client credentials.

A malicious SDK can quietly steal that material while appearing to perform its normal job. This makes the attack harder to spot than malware that drops obvious files or launches noisy system commands.

Developers should apply extra caution when a package claims to represent a bank, payment processor, identity provider, or government service. They should verify the publisher through an official website, compare package names carefully, and avoid relying on search summaries or package descriptions alone.

The Bigger Lesson for Software Supply Chains

The malicious Sicoob.Sdk package shows how attackers can turn a trusted developer workflow into a credential theft channel. The package did not need to exploit a vulnerability in .NET or NuGet. It simply convinced developers to install code that asked for secrets and then leaked them.

Socket’s analysis of Sicoob.Sdk also highlights a growing risk in financial software supply chains: attackers increasingly target the tools that sit between developers and sensitive APIs.

The safest response is to verify the package source before installation, limit which packages can enter production builds, and treat any SDK that handles certificates or passwords as high risk by default. For .NET teams, NuGet Package Source Mapping and package signing should be part of that review process.

FAQ