Inside the NuGet hackers' toolset

RL researchers recently got a rare and valuable insight into how attackers clone, publish and artificially popularize malicious packages within the NuGet ecosystem after they discovered two NuGet packages containing internal tooling used by threat actors in previously observed malicious campaigns. 

Based on RL’s assessment the packages, named 8y234rtv8yvf  and 3rugfbe8rivferiuv, were published accidentally, exposing scripts that operationalize techniques RL has long suspected supply chain threat actors were employing in NuGet-based supply chain abuse, but lacked the evidence to confirm those suspicions.

Background

Over the years, RL researchers have observed several techniques used by threat actors targeting NuGet. These include methods already familiar to our team, such as leveraging homoglyphs to typosquat popular packages, and artificially inflating version numbers and download counts.

While these behaviors have been documented repeatedly, the tools and mechanics that enable them were unknown and the subject of speculation. But that changed in late January, when RL researchers discovered the two NuGet packages, each containing three scripts that, when analyzed together, form a complete toolchain for creating typosquatted packages and manipulating their reputations. 

Details

On January 26, RL researchers discovered 8y234rtv8yvf and 3rugfbe8rivferiuv, NuGet packages that contained three scripts. When analyzed together, the scripts contained in the two packages form a complete toolchain for package impersonation and reputation manipulation. 

The tooling aligns closely with behaviors seen in recent malicious NuGet campaigns, such as the December campaign targeting Nethereum developers, as well as the recently disclosed campaign targeting developers utilizing the Stripe.net NuGet package. The tools appear to be purpose-built for large-scale, repeatable abuse.

What follows is a detailed analysis of the contents of the package and the functioning of the scripts used to carry out package cloning campaigns. 

First Component: The 'cloner'

The toolchain begins with the selection of a target. Based on our observations, the targets are typically popular packages, often related to cryptocurrency projects. To start, the attacker places the name(s) of the target package(s) they want to scrape inside a file, packages.txt, that is in the same directory as the “cloner” script, which is a data scraper. 

When executed, the “cloner” script does the remaining work of cloning the named package(s) automatically. It visits the target package’s NuGet page and collects metadata including icons, source repository, descriptions, tags, supported frameworks, dependencies, release notes, versions and download statistics. This information is stored in a JSON file for further processing. 

When run successfully, the “cloner” allows the attacker to build a near-perfect metadata replica of the target package without too much effort.

Image 1: Partial functionality of the scraper logic

Second Component: The 'poster'

The second script consumes the scraped metadata and automates the creation and publication of semi-empty NuGet packages based on that scraped data.

Image 2: Processing and publishing to NuGet

This script utilizes the NuGet CLI binary to create an empty .nuspec file, which is a manifest file that contains package metadata, both to build the package and provide information to the users.

The initially empty metadata is populated with information copied from legitimate packages. The package is then built using the NuGet CLI, and published to NuGet. This process repeats for each version discovered during the scraping phase. Once all existing versions of the cloned package have been processed, an additional “future version” is generated and published. This version also contains no functional code but increments the latest version number, creating the illusion of a newer or more actively maintained package compared to the legitimate one being cloned.

The resulting packages appear authentic, despite containing no functional code. They sport the same package icon, name, and version numbers, as well as the same tags and same readme files.

This behaviour is similar to what we saw with previously observed campaigns targeting financial targets, including the campaign targeting Nethereum we wrote about in December. Like the actors behind those campaigns, the attackers here focused on building trust with the targeted developers first, only to add malicious payloads later, often after the third component of the toolchain has been employed.

Third Component: The 'botter'

The third (and final) script is a multi-threaded PowerShell downloader that is designed to artificially inflate package download counts.

Image 3: Worker loop of the botter

The script rotates user-agent strings to diversify reported client types on NuGet and uses a proxy to rotate IP addresses in order to avoid rate limiting. Downloads are attempted continuously from both the NuGet V2 and V3 endpoints, with randomized delays between requests.

This tool directly operationalizes a long-suspected tactic: download count manipulation to boost perceived trustworthiness. And it helps explain eye-popping download counts on brand new packages, like the more than 180,000 downloads attributed to the StripeAPI.net NuGet package just days after it was uploaded.

Discussion

Was this an accident?

Several indicators suggest that this package was not intentionally published as a public artifact. Rather, it was exposed unintentionally during the threat actor’s operations or testing. 

First, the NuGet packages containing the scripts had multiple versions published within a short period of time. That suggests that the threat actors intended to push out a typosquatted version of another NuGet package. But, by mistake, they instead published multiple versions of the NuGet packages containing their cloning tools.

And, the contents of the JSON file found in this package point to the intended target: Nethereum, the same, popular Coinbase-linked NuGet package that we wrote about being targeted in December.

This pattern aligns with the automated publishing behavior implemented by the second component of the toolchain, the “cloner,” which generates and publishes multiple versions of packages in quick succession. However, unlike the malicious packages observed in active campaigns, this toolchain package does not show signs of artificially inflated download counts. That suggests that the package was not fed to the “botter” script  and subjected to the final stage of the workflow.

Why? Presumably, the threat actor behind this campaign intended to publish a cloned package, but instead mistakenly published their internal tooling. That was a gift for defenders, as the published package exposes important details about how the package cloning and promotion is carried out. Those details would otherwise remain internal to the campaign. Now that they are public, however, developers as well as package repositories can begin to monitor for similar behaviors as they look to spot and block malicious supply chain campaigns.

Operational impact

The exposure of this package and the tooling it contains provides a rare look into the automation of typosquatting attacks and package-based threats. Rather than manually crafting deceptive packages, the scripts discovered here enable scalable and repeatable cloning; structured publishing; and systematic reputation manipulation. This level of automation reduces operational friction for threat actors and allows typosquatting campaigns to scale rapidly while maintaining consistency in presentation.

The ability to replicate package metadata with high fidelity is particularly impactful. Developers today are busy and often look to familiar icons, repository references, tags, and descriptions as trust indicators when evaluating packages. By reproducing these elements and boosting the reported downloads, updates and even contributors, attackers can significantly increase the likelihood that a malicious or placeholder package will evade detection and be downloaded by a developer.

For developers working with open source packages, download counts and a detailed version history are commonly interpreted as signals of adoption and stability. A package with frequent updates and high download numbers can appear active, trusted, and widely used. Unfortunately, the tooling discovered- and analyzed by RL Researchers demonstrates that these metrics can be manipulated and should not be taken as proof of legitimacy.

Understanding malicious workflows is key

This discovery provides an uncommon glimpse into the internal tooling and workflows used by threat actors targeting the NuGet ecosystem. The accidental publication of this package exposed a complete, end-to-end workflow for cloning, publishing, and artificially popularizing malicious packages.

By revealing not only individual techniques but the automation that binds them, this case confirms how previously observed behaviors are operationalized at scale. As supply-chain threats continue to evolve, visibility into attacker tooling remains critical for understanding, detecting, and disrupting abuse within open-source package ecosystems.

Our discovery also provides developers, software publishers and open source infrastructure operators with valuable behavioral indicators that can be applied to detect emerging typosquatting campaigns and other efforts to promote malicious or compromised open source packages. 

Spot NuGet Threats with Spectra Assure

To help developers avoid threats like those uncovered in this campaign, the Spectra Assure Community offers NuGet users quick and easy-to-understand insights into packages such as  8y234rtv8yvf  and 3rugfbe8rivferiuv.

In addition to calling out malicious packages and highlighting analyst-vetted research, Spectra Assure Community enables developers to review automatically surfaced issues for any package they’re considering using. 

Finally, RL’s triggered Threat Hunting (TH) policies highlight suspicious behaviors within packages. Developers can scan and check the status of packages found on public repositories before they install them, looking for signs of malware or other security policy violations — helping them determine whether it’s trustworthy before installation.