NuGet in the Wild: `Sicoob.Sdk` & the Cloud Heist Trend
Just caught the report from Socket regarding the malicious Sicoob.Sdk package on NuGet. It’s a targeted hit on the Brazilian financial cooperative ecosystem, specifically exfiltrating Client IDs and PFX certificates.
Technical Breakdown:
- Malicious Package:
Sicoob.Sdk - Affected Versions: 2.0.0 – 2.0.4
- Payload: The package includes obfuscated code designed to scan for and exfiltrate PFX certificates. Since these certs contain private keys, the attackers effectively bypass MFA to gain direct access to banking APIs.
This mirrors the disturbing trend we're seeing with npm packages targeting cloud secrets (AWS/Azure keys). The attackers are no longer just typosquatting; they are publishing functional SDKs to build trust before weaponizing them.
If you have any .NET devs consuming Sicoob.Sdk, you need to audit your obj/project.assets. files immediately. A quick PowerShell scan of your source repos might save you a headache:
# Recursively search for the malicious package version in project assets
Get-ChildItem -Path . -Recurse -Filter "project.assets." | Select-String "Sicoob.Sdk.*2.0.[0-4]" | Select-Object Path
NuGet has pulled the package, but the supply chain lag is real. The exfil traffic likely looks like standard HTTPS, so network detection is tough without SSL inspection.
How are you handling supply chain hygiene in your CI/CD pipelines? Are you blocking unsigned packages by default, or is that still too operational heavy for most .NET shops?
Blocking unsigned packages is a must in 2026. We use a policy in Azure Artifacts that acts as an allow-list. If a package isn't signed by a trusted certificate (or the author's known cert), the restore fails.
For detection on the endpoint, since the malware exfiltrates PFX files, watch for processes making outbound connections immediately after accessing the local certificate store. This KQL query helps us spot the anomaly:
DeviceProcessEvents
| where FileName in ("powershell.exe", "dotnet.exe")
| where InitiatingProcessFileName has "nuget"
| where NetworkIPAddresses != ""
The PFX theft is the scary part here—reissuing banking certificates is a nightmare compared to rotating an API key.
We run Syft and Grype in our pipelines to generate SBOMs and scan for known bad hashes, but zero-days like this are hard. We've started pinning exact versions in csproj files rather than using floating ranges (e.g., 2.0.*) to prevent accidental auto-updates to malicious patched versions. It adds overhead to maintenance, but it stops this specific attack vector.
The reliance on software-based PFX files is the root vulnerability here. Since you can't easily steal what isn't stored in software, we mandate hardware security modules (HSMs) for all code signing and banking certificates. If an attacker gets disk access, the private key remains on the device. For teams still transitioning, you can audit your global packages to ensure you didn't inadvertently install the bad versions:
dotnet nuget locals global-packages --list
While HSMs are ideal, we also need a safety net for detection. If a malicious package slips through, we rely on DLP rules to flag PFX/P12 files attempting to leave our dev subnets.
For those using Zeek, this script helps catch the magic bytes of a certificate file in transit:
zeek event http_request(c: connection, method: string, original_URI: string, ...) { if ( method == "POST" && /application/x-pkcs12/ in c$http$mime_type ) { print fmt("PFX Exfil detected from %s", c$id$orig_h); } }
Solid points. From a compliance audit perspective, we need to verify ingestion. You should immediately query your NuGet feed logs to ensure no one internally pulled versions 2.0.0–2.0.4. If you're using Azure DevOps, you can use this KQL query to confirm exposure:
kusto NuGetAudit
| where Name == "Sicoob.Sdk"
| where Version in ("2.0.0", "2.0.1", "2.0.2", "2.0.3", "2.0.4")
This provides the necessary evidence for your incident report.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access