An attack on the NuGet package registry shows how advanced open-source software supply chain attacks have become. It shows how attackers can take advantage of developers’ trust and gaps in registry rules to inject malware that steals data directly into business build processes.
Security researchers from Socket recently found a live homoglyph typosquat on NuGet that copied the Nethereum project. This project was targeted for a reason. Nethereum is the standard .NET library for Ethereum, making it a prime target for attackers wanting to steal crypto or compromise blockchain applications.
The impact of such a breach on business can be severe. The malicious code was made to send sensitive data through an HTTPS POST, which could carry mnemonics, private keys, keystore JSON, or signed transaction data. For any business in FinTech, digital identity, or Web3, losing this data would be a major disaster, leading to financial losses and damaged customer trust.
The attack was carried out using a strategy with several layers, designed to get past both human and automated security checks.
Challenge 1: Tricking with homoglyphs
The attacker released a package called Netherеum.All. At first glance, this looks just like the real project. The trick was simple but worked well: it swaps a Cyrillic ‘e’ into the name to pass casual inspection.
This attack on NuGet shows a key issue with governance. Unlike many other registries, NuGet’s identifier rules do not restrict names to ASCII, which leaves room for Unicode lookalikes. Registries like PyPI and npm, on the other hand, have stricter rules that would likely have stopped this particular attack on the open-source software supply chain. This difference means that defence plans can’t be the same for everyone; they need to be made for the specific risks of each system.
Challenge 2: Faking trust
Just changing the name wasn’t enough. The attacker needed to make the fake package seem popular. The malicious package exploded within days of publication, getting over 11.6 million downloads.
This strongly indicates automated download inflation. By scripting downloads from different cloud hosts and changing IP addresses, the attacker lends false sense of proof when developers glance at the numbers. This is very effective, as development teams often quickly check download counts to see if a package is trustworthy.
Challenge 3: The hidden payload
The most difficult part for defence was how the payload was designed. The malware wasn’t an obvious script. Instead, it was a tiny XOR routine hiding a hardcoded C2.
When a developer installed the malicious package used for the attack from NuGet, it also pulled in real dependencies like Nethereum.Hex and Nethereum.Signer. This made sure the application would compile and perform expected Ethereum operations. The malicious code stayed hidden until a specific method, Shuffle, was used. This method would then XOR decodes the on-disk decoy… into [an] HTTPS POST to send stolen secrets to the attacker’s command and control (C2) endpoint.
Because the malware was within a credible transaction service and the surrounding library does real work, a developer could see the app function normally while sensitive strings quietly leave the process. Standard checks for known CVEs would likely not find this.
However, this wasn’t the only incident. The same attacker was linked to an earlier typosquat, NethereumNet, using the same malicious code.
Even though NuGet’s security team quickly removed the Netherеum.All package after it was reported, the attack had a four day dwell time between publication and takedown. This is more than enough for damage. Importantly, removal does not clean environments; treat exposed secrets as compromised and rotate them.
Here’s a checklist of practical actions to improve software supply chain defence:
- Check publisher identity: Don’t just look at download counts or package names. Make sure development teams verify publisher identity before using a new dependency. Is the publisher the known organisation? Is the account new? This simple step is a good first line of defence.
- Scan for behaviour, not just signatures: This attack wouldn’t be found by tools only looking for known weaknesses. Businesses need to scan dependency changes pre-merge and check for suspicious behaviours. Security tools need to be able to alert on homoglyphs, sudden download spikes, and small decode-and-exfil routines.
- Monitor network egress: The payload was designed to steal data. It’s important to have strong policies to monitor for anomalous network egress from build runners and developer workstations. A build tool should never communicate with an unknown domain.
- Use a zero-trust dependency model: Treat every new or updated package as untrusted. Security should tighten dependency hygiene by default, blocking risky behaviours like install-time scripts or unexpected network calls before they run in a CI/CD environment or on a developer’s machine.
As businesses increasingly rely on cloud platforms from Microsoft, Google, and AWS, developers must take every possible measure to secure all components of the open-source software supply chain — including those obtained from package managers such as NuGet — to guard against these ever more common attacks.
See also: GitLab deploys AI agents to tackle DevSecOps noise
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events, click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.