Malicious Sicoob NuGet SDK and Typosquatted npm Packages Target Cloud Secrets

---

---

A counterfeit banking SDK slips into the .NET ecosystem

Security researchers at Socket identified a malicious NuGet package named Sicoob.Sdk that pretended to be an official C# client library for Brazil’s Sicoob cooperative banking network. Versions 2.0.0‑2.0.4 silently read a developer‑provided PFX certificate, Base64‑encode its contents, and ship the certificate, its password and the supplied client ID to a hard‑coded Sentry endpoint.

“When a developer calls new SicoobClient(clientId, pfxPath, pfxPassword), the library pulls the PFX from disk, encodes it, and posts it to https://sentry.example.com/collect. The same code also logs raw Boleto API responses to a second endpoint,” explains Kirill Boychenko, senior threat analyst at Socket.

The package was downloaded ≈ 500 times before NuGet removed it. Because the PFX files authenticate businesses to the Sicoob API, an attacker who captures them can impersonate the victim’s payment flows, generate fraudulent Pix QR codes, and read sensitive Boleto transaction data.

Why the attack succeeded

• Search‑engine amplification – Google’s AI‑enhanced search surfaced the malicious package as a legitimate SDK, pushing it to developers who typed “Sicoob SDK C#”.
• Source‑to‑package mismatch – The GitHub repo linked from the NuGet page contained only clean example code. The malicious payload lived exclusively in the binary uploaded to the registry, making static analysis of the repo ineffective.
• Low visibility – The package name matches the official brand exactly, so developers see no warning in the NuGet UI.

---

Typosquatted npm modules harvest cloud credentials

In the same week, Microsoft Defender Security Research uncovered 14 npm packages published by a single actor (vpmdhaj, email [email protected]). The packages masquerade as utilities for OpenSearch, ElasticSearch, DevOps tooling, and environment configuration. Each package installs a pre‑install hook that runs a credential‑harvesting script, then sends the entire process.env object to https://oob.moika.tech/report.

The stolen data includes:

• AWS access keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
• HashiCorp Vault tokens
• npm authentication tokens
• CI/CD pipeline secrets (GitHub Actions, Azure Pipelines, GitLab CI)

These modules are part of a broader surge of supply‑chain abuse:

• 164 malicious npm packages across five namespaces using post‑install payloads to download second‑stage JavaScript.
• 141 packages abusing npm as free static hosting for ad‑monetized proxies.
• 176 packages employing dependency‑confusion version tricks (99.99.99) to push malicious scripts.

“The shift from classic typo‑squatting to ‘manufactured legitimacy’ means attackers are now naming packages to blend into everyday developer workflows,” notes Michael Warren, senior researcher at BlueVoyant. “One poisoned dependency can cascade through CI pipelines and compromise downstream releases.”

---

Practical steps for developers and security teams

1. Immediate containment

1. Remove the packages – Run dotnet remove package Sicoob.Sdk and npm uninstall <malicious‑module> on all affected machines.
2. Revoke compromised credentials – Treat every extracted PFX, AWS key, Vault token, and npm token as compromised. Generate new certificates, rotate keys, and update passwords.
3. Invalidate client IDs – Contact Sicoob support to disable the exposed client identifiers and re‑issue new ones.

2. Audit and forensic review

• Search package registries – Query NuGet and npm for any packages published by the accounts sicoob and vpmdhaj. Use tools like dotnet list package --vulnerable and npm audit to surface hidden threats.
• Inspect build logs – Look for unexpected network calls to sentry.* or oob.moika.tech. Enable outbound‑traffic monitoring on build agents.
• Review API logs – Sicoob API endpoints should be examined for anomalous request patterns (e.g., repeated authentication attempts from unknown IPs).

3. Harden the software supply chain

• Enable package provenance – Require packages to be signed with a trusted certificate (e.g., NuGet’s Repository Signature feature) before they can be installed in production pipelines.
• Pin exact versions – Avoid floating version ranges (^1.0.0) in packages.config, *.csproj, or package.json. Lock dependencies to known‑good hashes.
• Run automated SBOM checks – Tools like CycloneDX or Syft can generate a bill‑of‑materials for each build and compare it against an allow‑list.
• Isolate build environments – Run npm installs and dotnet restores inside containers that have no access to production secrets. Use environment‑variable redaction tools (e.g., GitHub Actions mask feature) to prevent accidental leakage.

4. Educate developers

• Teach verification – Encourage developers to verify the publisher of a package on the registry UI and to inspect the source repository before adding a dependency.
• Use “search‑engine safe‑mode” – When searching for libraries, add site:nuget.org or site:npmjs.com to limit results to official registries.
• Adopt a “zero‑trust” stance for third‑party code – Treat every external library as a potential attack vector until proven otherwise.

---

Looking ahead

The Sicoob SDK incident and the npm typosquatting wave illustrate how attackers are blending social engineering (search‑engine manipulation) with technical tricks (pre‑install hooks, source‑to‑package mismatches). As supply‑chain attacks become more sophisticated, organizations must move beyond reactive scanning and embed continuous verification into their development lifecycle.

For deeper technical details, see the full Socket advisory here and the Microsoft Defender report on the npm campaign here.

---

Stay vigilant, keep your dependencies clean, and remember that a single rogue package can expose an entire financial ecosystem.