Fake Banking SDK Turns a Trusted Dependency into a Secret Collector

A package name that looks routine can matter as much as any exploit chain. In this case, a counterfeit .NET dependency presented itself as a Sicoob SDK and was reported to be harvesting banking-related secrets during initialization, not after a dramatic break-in. That is what makes package supply-chain abuse so dangerous: the attacker does not always need to penetrate the target network if the trust gap already sits inside the build and install process.

Fast Facts

• Sicoob.Sdk was reported as a malicious NuGet package.
• The package impersonated banking integration tooling tied to Sicoob’s developer ecosystem.
• Researchers reported credential material being gathered during SDK initialization.
• The package was described as sending data through a hardcoded outbound endpoint.
• The case highlights the risk of counterfeit packages in regulated software supply chains.

How the Trick Works

NuGet is the package system many .NET teams rely on for dependencies, and that convenience is exactly what attackers try to exploit. A package that borrows the name and purpose of a legitimate SDK can blend into normal development habits, especially when teams install libraries from public feeds or mirrored internal repositories.

In this incident, the malicious package was reported to collect sensitive material tied to banking integration, including client ID information and PFX-related secrets, during SDK initialization. That detail matters because certificate-based authentication is not just another login. A PFX file usually contains certificate material and a private key protected by a password, so exposure can have a wider operational impact than a simple API token leak.

Researchers also reported that the data was sent to a hardcoded telemetry endpoint. From a defensive perspective, that is a useful camouflage pattern: outbound traffic aimed at analytics or error-reporting services can be harder to distinguish from routine software chatter than a direct upload to an obvious attacker-controlled host. The available information supports a risk analysis, not a definitive claim about every environment that may have touched the package.

The broader lesson is that supply-chain abuse often targets the software life cycle before a system ever enters production. A developer workstation, CI runner, or build agent can become the point where secrets are handled, copied, or exposed if a dependency behaves maliciously at install time or first use.

What Defenders Should Watch

For security teams, the first step is provenance. Inventory projects that reference the package name, confirm which feeds were allowed to provide it, and trace where those artifacts were restored. In general, package signature checks and trusted-signer policies can reduce the chance of installing an untrusted dependency, although they are controls, not a guarantee of business legitimacy.

Teams that handle banking integrations should treat SDKs touching certificates, passwords, or mutual TLS material as high-risk dependencies. Unexpected outbound connections from such components deserve review, especially when the destination is not documented by the vendor. If the package was used in a real environment, certificate rotation and password reset should be treated as urgent follow-up steps.

Conclusion

This incident is a reminder that the softest target is often trust itself. A package registry can deliver useful tools, but it can also deliver a lookalike that turns initialization into secret collection. For modern defenders, package identity, dependency review, and outbound traffic monitoring are not paperwork tasks - they are part of the perimeter.

WIKICROOK

• NuGet: Microsoft’s package manager for .NET projects, used to install and restore libraries and SDKs.
• SDK: Software Development Kit, a bundle of tools and code used to build or connect applications.
• PFX: A password-protected certificate file format that can store certificates and private keys.
• Mutual TLS: A setup where both client and server authenticate each other with certificates.
• Package provenance: The origin and trust history of a software package, including who published it and how it was signed.