A NuGet package posing as a Sicoob C# SDK allegedly stole banking API authentication material, while a separate npm cluster targeted cloud and CI/CD secrets. The useful signal is not that package registries are risky in the abstract. It is that routine install and integration steps can now expose banking certificates, cloud credentials, and build pipeline tokens before a developer sees anything obviously wrong.
What changed in this security advisory#
The Hacker News reports that cybersecurity researchers found a malicious NuGet package masquerading as a C# software development kit for Sicoob, one of Brazil’s largest cooperative financial systems. According to the report, versions 2.0.0 through 2.0.4 of the package “Sicoob.Sdk” contained code designed to exfiltrate sensitive data.
The exposed material is not minor telemetry. The package reportedly collected client IDs, PFX certificate files, and PFX passwords. Those certificates are used to authenticate businesses with the Sicoob banking network for automated banking operations, including instant payment processing and dynamic Pix QR code generation.
The mechanism described by security researcher Kirill Boychenko is direct. When a developer instantiated SicoobClient with a client ID, PFX file path, and PFX password, the package read the PFX file from disk, Base64-encoded it, and sent the client ID, PFX password, and encoded certificate data to a hardcoded third-party Sentry endpoint.
The same package also reportedly captured raw Boleto API responses through a separate Sentry path. Boleto is a widely used Brazilian payment method. Raw responses could contain transaction details, payment status, amounts, due dates, identifiers, and payer or payee data.
After responsible disclosure, NuGet blocked the package. The package was estimated to have been downloaded nearly 500 times. The profile behind it, named “sicoob,” also listed 11 other NuGet packages with about 6,000 downloads in total, according to the report.
One detail deserves extra attention: the reported source-to-package mismatch. The GitHub repository appeared clean, while the malicious behavior was allegedly present only in the artifact uploaded to NuGet. That is the uncomfortable part for teams that still treat a visible repository as enough proof of package integrity.
Why it matters for security operations#
This is a banking credential theft case wrapped in ordinary developer workflow. If the report is accurate, a developer did not need to run a suspicious executable or paste a secret into a random website. They only had to install and use a package that appeared to solve a real integration problem.
The risk is also not limited to the developer machine. Compromised Sicoob API authentication material could let an attacker impersonate a victim’s banking API integration. That changes the incident class from “developer secret exposure” to possible payment abuse, financial data leakage, and operational disruption for businesses using the integration.
The AI search angle is worth treating carefully. The report says Google Search AI Mode surfaced the package as a legitimate C# library for interacting with Sicoob banking APIs. That does not prove the AI system caused the compromise. It does show a distribution problem: developer discovery now includes generated answers and recommendation surfaces, not only package search, GitHub stars, and documentation links.
The npm side of the report points in the same direction. Microsoft Defender Security Research Team identified 14 malicious npm packages that typosquatted or imitated OpenSearch, ElasticSearch, DevOps, and environment-configuration libraries. These packages allegedly used a preinstall hook to launch a credential harvester aimed at AWS credentials, HashiCorp Vault tokens, npm tokens, and CI/CD pipeline secrets.
That target list is a clean map of what attackers value. Cloud keys, Vault tokens, npm credentials, and pipeline secrets can provide follow-on access. A single malicious dependency can become reconnaissance, credential theft, package publishing abuse, or access into production-adjacent systems.
The broader npm activity described in the source includes multiple malicious package waves. Some exfiltrated environment variables. Others abused npm as static hosting for ad-monetized proxy pages. Another package allegedly included keylogging, clipboard monitoring, .env scanning, shell history exfiltration, screenshots, remote filesystem access, host inventory, and cryptocurrency wallet scanning.
The pattern is not classic typo-only abuse. Sonatype’s framing is useful here: “typosquatting” is too narrow. Attackers increasingly manufacture legitimacy through plausible names, scopes, prefixes, suffixes, version mimicry, embedded target terms, and workflow-shaped package names. The package does not need to look like a typo. It only needs to look like something a busy developer would reasonably install.
What to check before acting#
Teams that installed Sicoob.Sdk, especially versions 2.0.0 through 2.0.4 as reported, should treat the related PFX material as compromised until proven otherwise. The source recommends removing the package, replacing exposed PFX certificates, rotating PFX passwords, and changing or disabling affected client IDs where applicable.
Audit Sicoob authentication and API logs for unusual activity. Look for unexpected API calls, abnormal payment operations, unfamiliar client IDs, strange source networks, or changes in timing and volume. The exact indicators will depend on how the banking integration is deployed, but the first question is simple: did the compromised credential material authenticate after the package was used?
For npm exposure, check whether any of the named malicious packages were installed in developer machines, CI runners, build images, or test environments. Pay close attention to packages that ran install hooks. A preinstall script can execute before the package is ever imported into application code.
Useful operational checks include:
- Review lockfiles and package manager logs for the suspicious package names.
- Search CI job logs for unexpected install-time network calls.
- Rotate exposed npm tokens, cloud credentials, Vault tokens, and CI/CD secrets if compromise is plausible.
- Inspect build runners and developer workstations that installed suspect packages.
- Compare registry artifacts against source repositories when trust depends on source transparency.
- Disable install scripts by default where workflows allow it, then permit exceptions deliberately.
This is also a good moment to revisit how teams accept open source security evidence. A clean repository is helpful, but it is not the same as a verified build artifact. If the uploaded package differs from the visible source, the registry artifact is the thing that runs.
For background on making security artifacts operational, see GigaTap’s note on OpenSSF’s April signal: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational. The same principle applies here: attestations, provenance, package tests, and artifact comparison matter only when they change daily decisions.
What not to overclaim#
The report does not establish that every download resulted in successful credential theft. A download count is not the same as execution, and execution is not the same as use with real client IDs and PFX material. Treat the number as exposure scope, not confirmed victim count.
It also does not prove that all packages under the same NuGet profile were malicious. The profile had other packages and collective downloads, but each artifact still needs its own analysis. Grouping them together may be useful for triage. It is not proof by itself.
The Google AI discovery detail should not be turned into a simplistic “AI caused the attack” claim. The sharper point is that recommendation systems can amplify malicious packages when they lack strong package provenance signals. That is a search and trust problem, not a magic new exploit class.
The practical lesson is narrower and stronger: install-time trust is now a frontline security operations issue. Package names, repository links, AI summaries, and apparent workflow fit are weak signals on their own. The artifact, its install behavior, its network activity, and its access to secrets are what decide the risk.