Alert: the NuGet package that pretended to be a bank SDK to steal PFX credentials and certificates

Security researchers have detected a malicious package in NuGet posing as a legitimate SDK for Sicoob, one of the largest financial cooperatives in Brazil, and whose goal was to stealing API credentials and PFX certificates used by companies to authenticate to the banking network and automate payments and charges. The threat is not only technical: it exploits the confidence of developers seeking to integrate banking services, turning a routine installation into a potentially critical gap for payments and financial data.

Technically, the package intercepted the normal customer initialization flow: when a developer provided an ID client, the route to a PFX file and its password, the malicious code read the PFX file from disk, encoded its content and sent that package - along with the ID client and password - to preconfigured endpoints acting as exfiltration receptors. In addition, there were dedicated channels to capture raw responses from the Ticket API, which exposes not only credentials but also details of transactions, amounts, maturities and sensitive identifiers.

There are several points of interest in this campaign that must concern the community: first, the package was distributed from NuGet and reached hundreds of downloads before being blocked, which shows that public records remain an effective vector to spread malicious code. Second, the attackers used a "legitimate manufactured" tactic by associating the package with a seemingly legitimate GitHub repository, creating a discord between the public code and the binary distributed by NuGet; this separation makes manual detection and deceives surface verifiers.

Another amplifier of the problem was the appearance of the package in results generated by IA-based search tools, which recommended it as a valid library to integrate with Sicoob. This combination - public record + legitimate appearance + automatic recommendations - makes unprepared developers install units without proper controls, thus exposing production credentials and critical assets.

This incident is inserted into a wider wave of software supply chain attacks that have mainly affected the npm ecosystem, with campaigns using typosquating, postinstall hooks and dependency techniques to extract credentials from local environments, CI / CD pipelines and .envos files. Security analysts and companies like Sonatype have documented how attackers have left behind simple spelling errors and now design names of packages and versions that seem completely plausible in real workflows, a practice they describe as making legitimacy. To read analysis and recommendations about these techniques, public resources such as Sonatype's blog are useful https: / / www.sonatype.com / blog and projects that promote signature and verification of artifacts such as Sigstore https: / / sigstore.dev.

The practical implications are severe: with a PFX and your password an attacker can supplanting bank integration, create payments or receive funds on behalf of the victim, or filter financial information from third parties. At the organizational level this can result in direct economic losses, fraud, regulatory sanctions and reputational damage, especially in markets where methods such as Pix and Boleto are widely adopted.

In order to reduce the immediate risk, both emergency and strategic measures must be taken. In the immediate response, anyone who has installed the package in question must remove it from its code and repositories, consider PFX material as compromised, revoke or replace the exposed certificates, rotate passwords and disable or regenerate the affected clients. In parallel, it is recommended to audit the authentication and transaction logs in Sicoob in search of abnormal activity and coordinate with the bank's security team if there are signs of abuse.

On a broader preventive level, organizations and developers should avoid storing sensitive material in flat text within repositories or shared disks; instead, it is appropriate to use secret coffers and HSM / Vaults that minimize the presence of keys in the filesystem. The supply chain should be protected by policies to block unverified packages, use of internal registers or whitelists, validation of package signatures, generation of SBOMs and adoption of controls such as SLSA. Implement automatic unit scanning, review differences between the published package and the linked source code, and restrict CI / CD access to sensitive secrets are countermeasures that reduce the attack surface.

Finally, this case serves as a reminder that the security of the payment infrastructure depends on both good cryptographic practices and hygiene in unit management. Automatic recommendation and search tools can accelerate development, but also amplify risks when not combined with human verification and technical controls. The industry needs to move towards flows where the provenance and integrity of each unit are verifiable by default, and development teams must incorporate security reviews at each step of the software life cycle.