In the span of thirteen months, security researchers uncovered at least four distinct malicious NuGet package campaigns, each one exploiting the trust .NET developers place in the public registry. In October 2025, a package using a Cyrillic homoglyph impersonated the popular Nethereum library and racked up 11.6 million downloads within days of publication. A month later, nine packages published under the alias "shanhai666" turned out to contain logic bombs set to sabotage industrial control systems and databases on trigger dates in 2027 and 2028. By early 2026, a single NuGet account had hidden 219 of 224 published package versions while stealing browser credentials and crypto wallet data from tens of thousands of machines, and a fake Brazilian banking SDK was exfiltrating signed certificates within three weeks of going live. Socket.dev's threat research team caught each one — but only after the campaign had already been running. Here's what these incidents reveal about NuGet's exposure, and what actually closes the gap.
Why is NuGet a growing target for supply chain attackers?
NuGet is attractive to attackers because it combines low publishing friction with deep enterprise reach, and 2025-2026 confirmed it. Anyone can register an account and publish a package to nuget.org with no code review and minimal identity verification, the same open-by-design model that made npm and PyPI magnets for typosquatting. But .NET sits underneath a disproportionate share of high-value targets: Windows enterprise software, ASP.NET web backends, financial services tooling, and — critically — industrial automation software written against libraries like Sharp7 for Siemens S7 PLCs. That combination gives attackers a registry that's as easy to abuse as any other open ecosystem, but with a blast radius that can reach production databases, banking APIs, and factory-floor control systems. Every campaign discovered since October 2025 has targeted exactly that mix: crypto wallets, browser-stored credentials, banking certificates, and industrial safety systems, not just developer laptops.
How did a malicious NuGet package steal crypto wallet keys using a Cyrillic typosquat?
Attackers published a package named Netherеum.All — spelled with a Cyrillic "е" (U+0435) instead of a Latin one — to impersonate the legitimate Nethereum .NET library and harvest wallet secrets. Socket's threat research team traced the campaign's origin to early October 2025, when the threat actor first published a plainer typosquat called NethereumNet, then followed up in mid-October with the homoglyph variant designed to pass casual visual inspection in project files and search results. Once referenced, the package ran an XOR-decoding routine to reveal a hardcoded command-and-control endpoint at solananetworkinstance[.]info/api/gads, then exfiltrated mnemonics, private keys, keystore JSON, and signed transaction data over a single HTTPS POST field named "message." Within days of publication, NuGet's own listing showed 11.6 million total downloads for the homoglyph package — a number that only makes sense as scripted download inflation, a technique attackers use to make a malicious package look established enough to trust.
What happens when malicious NuGet packages are built to detonate years later?
They sit dormant in production dependency trees for years, then trigger destructive behavior on a preset date with no further attacker involvement required. In November 2025, Socket's researchers identified twelve packages published between 2023 and 2024 under the account "shanhai666" — nine malicious, three legitimate, the latter apparently included to build a credible publishing history. The malicious set targeted the three database providers most common in .NET applications (SQL Server, PostgreSQL, and SQLite) plus Sharp7Extend, a typosquat of the trusted Sharp7 library used to communicate with Siemens S7 industrial PLCs. Sharp7Extend carried two sabotage mechanisms: immediate random process termination, and silent write failures beginning 30-90 minutes after installation. The database-targeting packages were coded to terminate the host application with a 20% probability on each query — but only after trigger dates in August 2027 and November 2028, years past any reasonable code review window. By the time Socket found them, the packages had already been pulled into 9,488 downloads' worth of projects, each one a live time bomb with no calendar reminder attached.
How did one NuGet account hide 219 of 224 package versions to steal browser and wallet credentials?
An account called "bmrxntfj" published five packages typosquatting well-known Chinese .NET UI and infrastructure libraries — IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, and IR.OscarUI — and then used version churn to dodge detection. Across those five packages, the account published 224 total versions but kept only five visible in public search at any given time, deliberately hiding the other 219. That meant hash-based blocklists and manual review were chasing a moving target: as soon as one version got flagged, a fresh one was already live and unlisted, ready to swap in. The payload targeted saved credentials across 12 Chromium- and Firefox-based browsers, 8 desktop cryptocurrency wallets, and 5 browser wallet extensions, exfiltrating everything to a command-and-control domain, dns-providersa2.com, that had been registered specifically for the campaign. Combined, the five packages accumulated roughly 65,000 downloads — enough to put tens of thousands of developer workstations and CI/CD build servers into scope for credential and wallet theft, according to Socket's analysis.
Why did a fake banking SDK on NuGet only need 484 downloads to matter?
Because the package impersonated a real regional bank's official developer tooling, so every install carried a near-certain chance of exfiltrating a live production certificate. The package, published as "Sicoob.Sdk" to mimic the integration SDK for Brazil's Sicoob banking cooperative, first appeared on NuGet on May 5, 2026, reached version 2.0.4 by May 6, and was blocked by NuGet after an abuse report — a lifecycle of roughly three weeks across versions 2.0.0 through 2.0.4. Rather than casting a wide net, the package waited for a developer to supply a PFX certificate file as part of normal Sicoob API integration, then base64-encoded the certificate contents and sent them, along with the client ID and PFX password, to a hardcoded Sentry telemetry endpoint under the attacker's control. Microsoft's Defender Security Research Team attributed the package to a single threat actor publishing under the alias "vpmdhaj." Only 484 total downloads were recorded — a fraction of the Nethereum or bmrxntfj campaigns — but each one represented a live banking certificate and password handed directly to an attacker, which is why raw download counts are a poor proxy for how much a malicious NuGet package actually matters.
Why do malicious NuGet packages keep getting discovered after the damage is done?
Because registry-level defenses are still largely reactive: packages get scanned, reported, and removed after publication, not blocked before a developer can pull them into a build. NuGet.org has improved its response process, but even that process has stumbled — between July 1 and July 10, 2025, an internal review error led Microsoft to delete roughly 80 packages that depended on Microsoft.Identity.Client after a phishing URL was found in an unrelated comment field, restoring them only after community pushback. That incident pushed NuGet toward preferring un-listing over deletion and adding executive-level review for multi-package actions, but it also illustrates the core problem: registry operators and third-party researchers are triaging abuse reports and scan results after packages are already live, sometimes for months (Sicoob.Sdk) or years (the shanhai666 logic bombs) before anyone notices. Socket.dev has done consistently strong work surfacing these campaigns publicly, but public disclosure is inherently after-the-fact — it tells you a package was malicious once it's already been downloaded tens of thousands of times, not before your build pulls it in.
How Safeguard Helps
Safeguard is built around the assumption that a malicious NuGet package will eventually target your dependency tree, and that catching it after a blog post names it is too late. Instead of relying solely on published advisories and hash blocklists — which the bmrxntfj campaign showed can be defeated with routine version churn — Safeguard continuously monitors NuGet, npm, PyPI, and other package registries for newly published and newly updated packages, flagging suspicious signals like homoglyph names, freshly registered publisher accounts, sudden download spikes disproportionate to a package's age, and unlisted-version patterns before a human researcher would normally notice them.
For threats that don't announce themselves in metadata, Safeguard performs behavioral analysis on package install and build scripts, looking for the kind of obfuscated C2 logic seen in the Netherеum.All XOR routine, and time-based or conditional logic that resembles the shanhai666 logic bombs — code that behaves one way in a sandbox today and another way on a trigger date years from now. Safeguard's SBOM-driven inventory also means that when a campaign like the IR.DantUI or Sicoob.Sdk typosquats gets disclosed, Safeguard can immediately tell you whether any of your repositories, build pipelines, or production artifacts ever referenced the compromised package versions, rather than leaving your team to grep through lockfiles by hand.
Policy enforcement gates block known-malicious and newly-flagged packages at the point of install and in CI/CD, so a typosquat or homoglyph package never reaches a developer's machine or a build artifact in the first place — closing exactly the window that let Netherеum.All rack up 11.6 million downloads and the shanhai666 packages sit undetected for two years. When a package is later reclassified as malicious, Safeguard automatically re-scans historical builds and dependency graphs so teams aren't left wondering, months later, whether a certificate or credential needs to be rotated.
Software supply chain attacks against NuGet aren't slowing down, and the .NET ecosystem's footprint in financial services, enterprise software, and industrial control systems makes the stakes higher than a typical developer credential theft. Safeguard's goal is to move the detection point from "after Socket.dev publishes a writeup" to "before the install finishes."