NuGet malware targets Nethereum tools

This year, ReversingLabs (RL) researchers have discovered malware on various open-source software (OSS) platforms that target crypto users and developers. This is an attack trend RL saw explode in 2024, and it has continued in 2025 with crypto among threat actors favored prey. 

This past year alone, RL researchers have identified crypto-focused malware on:

• The Python Package Index (PyPI), where developers in the Solana ecosystem were targeted 
• npm, where threat actors attempted to steal crypto funds by injecting code into local, legitimate packages 
• VS Code, where a malicious pull request infected a legit extension that was used for Ethereum smart contract development. 

Despite these varied approaches on several different OSS platforms, NuGet, the OSS platform for .NET, has been pretty quiet this year. That is until this past October, when RL made a new discovery targeting the crypto ecosystem via NuGet.

On October 17, RL published a post on X about a new malicious NuGet package, “Netherеum.All,” which impersonates Nethereum, a .NET integration library for the Ethereum decentralized blockchain. Since our initial discovery, RL has discerned that this package is a part of a broader campaign that started in July 2025, which includes 14 packages — all published over the span of several months by various authors. 

All of the packages impersonate legitimate crypto-related tools and copy their functionality, but are enriched with malicious functionality intended to steal crypto funds from victims. For example, some of the packages are designed to redirect transaction funds to attacker-controlled wallets, while others are designed to exfiltrate secrets that can later be used to access victim wallets and extract funds from them. 

Malicious functionality is well hidden inside the code that attackers copied from legitimate packages, making analysis and detection of the malware more difficult. Threat actors also used several techniques to make the malicious packages look trustworthy, tricking unsuspecting users into a false sense of security.

Image 1: NuGet summary of the malicious package

Some of the techniques used in this latest campaign were also used in a July 2024 attack on NuGet discovered by RL threat researcher Karlo Zanki. The most notable techniques previously used include:

1. The use of homoglyphs: The package name uses a character that visually resembles a common letter or symbol. However,to a computer the character has an entirely different meaning. 
2. Version bumping: Pushing dozens of new versions in a short period of time in order to create an illusion of package upkeep and reliability.
3. Inflating download counts: Artificially raising the download count of a package to create the illusion of widespread package use and popularity. However, the metrics are unreal, with millions of downloads racking up just after the package has been published. 

These techniques, especially when used together for a single malicious package, give it the illusion of legitimacy, credibility and security that can convince developers that the package is safe to use. These social engineering efforts make NuGet users more susceptible to downloading innocuous-looking packages that actually exhibit malicious functionality.

Image 2: Version bumping & inflating download counts

Image 2 shows a clearer view of how the version bumping a package works: In this latest campaign, the threat actor pushed multiple versions at the same time, and artificially inflated the download counts for most versions of the package. The latest version in Image 2 is the only one that actually has the true download count displayed.

The 14 malicious NuGet packages detected by RL can be split up into three groups based on the type of malicious payload each delivered to victims:

Group one: The wallet stealer

Nine packages in total, including the Netherеum.All package, used the same method to steal sensitive crypto data.

In contrast to the simpler malicious packages RL researchers see on a daily basis that try to steal as much data as quickly as possible, often executing harmful code immediately upon installation, this malware takes a more subtle approach. This latest set of malicious packages is designed to be used by developers and embedded into other applications, so most of its codebase appears completely legitimate. However, at few critical functions within the code, malicious code has been subtly injected.

By hiding the payload inside these key execution points, the malware activates only when those specific functions are called. This allows it to blend in, remain undetected, and strike at the perfect moment.

To exfiltrate sensitive data, a new function Shuffle was created (Image 3). The purpose of this function is really simple, in that it just takes an argument (a message) and sends it to a remote URL. In this case, the remote URL is not defined as clear-text – most likely to avoid detection. Instead, it is created on the fly by decrypting a char array using a XOR cipher. In all nine packages, the exfiltration URL is “hxxps://solananetworkinstance[.]info/api/gads,” which mentions Solana Networks, a network monitoring vendor – representing a domain confusion scenario.

Image 3: Malicious method used to exfiltrate data

This function is then inserted into various routines at critical points, in order to exfiltrate different kinds of sensitive data, such as wallet addresses and their private keys, seed phrases, and Wallet Import Format (WIF) keys. With this information, the threat actors can gain full access to the victim’s wallet and freely move or drain their crypto assets.

Image 4: Example of the malicious function, Shuffle, being used to exfiltrate private and public keys

Group two: The crypto-funds stealer

The second group consists of three Nuget packages, one of them being Coinbase.Net.Api, which uses a similar trick to the prior group. Coinbase.Net.Api was published by the same author as some of the previously mentioned sensitive wallet info stealer packages. Again, a single malicious function is added to the code base and then wrapped into carefully chosen routines.

In this case, however, no sensitive data is being exfiltrated directly to a remote URL. Instead, the attacker created a function named MapAddress that contains a key-value pair of strings. The “key” being short-hand “cryptocurrency” and “value” being the wallet address of a given cryptocurrency ecosystem belonging to the attacker. The function receives a cryptocurrency ecosystem as a string, and it will respond with the corresponding wallet address — unless the ecosystem is not defined, in which case it will default to use the address that was passed to this function as an argument.

Image 5: Attacker’s wallet addresses

How is this exploited?

As mentioned above, the attacker inserts the malicious function at a critical point in the SendMoneyAsync, a method that is responsible for sending cryptocurrency. They overwrite the destination wallet address with one of their own – essentially funneling any money from transactions higher than $100 to themselves. Stealing the funds in this way mitigates the risk of the attacker getting detected during lower amount transactions.

Image 6: Usage of malicious function overwriting the transaction's destination

Group three: The Google Ads OAuth stealer

The last package, GoogleAds.API, works nearly identically to the Netherеum.All package mentioned previously. However, instead of exfiltrating wallet data secrets, the malware focuses on Google Ads OAuth.

The malicious code quietly transmitted victims’ data to the attacker’s external server, such as developer tokens, OAuth Client IDs and Client secrets — all similar to the malicious packages described earlier. These values are highly sensitive, because they allow full programmatic access to a Google Ads account and, if leaked, attackers can impersonate the victim’s advertising client, read all campaign and performance data, create or modify ads, and even spend unlimited funds on malicious or fraudulent campaigns.

Image 7: Google Oath exfiltrated by the SendLog function

Astute readers might have noticed that this blog initially called out the discovery of 14 malicious packages, yet this analysis only accounted for 13 of the packages. That’s because the last package, SolnetAll, was removed from NuGet before RL researchers could analyze it. However, it was published by the author DamienMcdougal, which is the same author that pushed NBitcoin.Unified, one of the 13 packages, which steals wallet information from users. Therefore, it’s not far fetched to assume that the removed SolnetAll package performs similarly.

What’s the impact?

Crypto assets are one of the most popular targets observed in OSS supply chain attacks. The popularity of this target is a given, since the obvious motivation for attackers in these scenarios is financial gain. 

While the Nuget campaign we discovered primarily targeted developers, its reach could have extended much further. That’s because developers who unknowingly installed and used any of the 14 malicious packages as part of new applications may have, without realizing it, passed the infection downstream to their own user base. This means that the threat wasn’t just limited to individual developers losing sensitive data and their crypto funds. Rather, the malicious actors behind these Nuget packages could have affected entire projects, organizations and communities that relied on applications that incorporated the malicious code– putting them and their cryptocurrency assets at risk.

This latest campaign is yet another reminder that a single compromised dependency can quickly propagate through the software supply chain — embedding malicious functionality in otherwise legitimate products.

The weakest link remains trust

Once again, this latest malicious campaign on NuGet should serve as a reminder that malicious actors continue to exploit the weakest link in the supply chain: trust. What appears to be a small and harmless dependency can in reality act as a silent backdoor, as was the case for this latest set of malicious packages.

This latest campaign follows the same patterns as we’ve seen across PyPI, npm and VS Code, showing that no OSS repository is immune to these threats, regardless of how big they are or what kinds of users they serve. Prior to this, however, the Nuget platform had seen a big drop in malicious package detections, from 34 last year to just two in the first 10 months of 2025. That may reflect stronger security features, such as mandatory two factor authentication for all maintainer accounts, which Nuget implemented in July, 2024. 

The attackers behind this latest set of packages utilized social engineering tactics, such as the artificial inflation of download counts, version bumping and manipulated package names in order to appear legitimate. 

Developers should always double check the legitimacy of OSS packages before installing them, and not simply scan a package’s stats. For example, developers should: 

1. Take a close look at the package’s publish date: When was it posted? Could it be possible that a new package gathered that many downloads since the time it was released?
2. Inspect the author: Is it a known publisher, or a new account with no other packages? Or, do the author’s other packages bear similar suspicious contents?
3. Review the package for suspicious content: Look for obfuscated code or unexplained connections with external servers. 

Stop NuGet threats with Spectra Assure Community

To help developers avoid threats like those uncovered in this campaign, Spectra Assure Community (secure.software) offers NuGet users quick and easy-to-understand insights into packages.

Image 8: Malware detection on Spectra Assure Community

In addition to analyst-vetted research, users can review automatically surfaced issues for any package they’re considering – helping them determine whether it’s trustworthy before installation.

RL’s triggered Threat Hunting (TH) policies further highlight suspicious behaviors within packages. For example, a TH policy such as “Detected presence of files with behaviors that match the infostealer malware profile” (TH15108) acts as an immediate red flag. When alerts like these appear, developers are strongly encouraged to avoid the package and perform thorough manual review before integrating it into their projects.

Image 9: Threat Hunting policies on Spectra Assure Community

Indicators of Compromise (IOCs) 

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.
The following IOCs were collected as part of ReversingLabs investigation of this software supply chain campaign. 

NuGet packages: