Attackers leverage PyPI to sideload malicious DLLs

ReversingLabs researchers have observed a clear trend in which open-source platforms and code have become the stage for a growing and diverse range of malicious activity and campaigns. This trend includes hosting malicious command-and-control (C2) infrastructure, storing stolen data, and delivering second- and third- stage malware including downloaders and rootkit programs. The team's most recent discovery suggests that trend is continuing in 2024. 

On January 10, ReversingLabs reverse engineer Karlo Zanki discovered two suspicious packages on the open-source package manager Python Package Index (PyPI). The packages, NP6HelperHttptest and NP6HelperHttper, were observed using DLL sideloading, a well-documented technique that malicious actors use to execute code without attracting the attention of security monitoring tools. 

The latest discovery is an example of DLL sideloading executed by an open-source package that suggests the scope of software supply chain threats is expanding. Here is how the two packages were discovered — and key implications for both development teams and end-users.

Discussion

One of the biggest challenges to developers who rely on open source code (and that is pretty much every developer) is assessing the quality and reliability of what they find online. The open-source ecosystem is vast and diverse, with a constantly shifting landscape made up of new software modules and actively managed code, not to mention the long, long tail of loosely managed, inactive, or obsolete open source code. Complicating matters for developers, there is no common identity or reputation provider for open-source modules. That makes it easy for malicious actors, with minimum effort, to insert themselves and their wares into otherwise legitimate software supply chains. 

As ReversingLabs has documented, typosquatting and repojacking attacks are two common methods of doing this, with malicious actors floating malicious look-alike packages for active or abandoned open-source modules in the hopes of fooling developers into incorporating them into their applications. But there are even more subtle ways to infiltrate legitimate applications, as ReversingLabs' latest discovery shows.  

This discovery happened as a result of our standard monitoring of open-source repositories for packages with specific combinations of suspicious behaviors. In this case, our platform was looking for network communication features hidden in the setup.py file. That scan turned up the two malicious PyPI packages, NP6HelperHttptest and NP6HelperHttper. With further investigation, it became clear that the targets of those files were two existing, legitimate PyPI packages: NP6HelperHttp and NP6HelperConfig. These are helper tools originally published by a PyPI developer with the username NP6. 

If that name sounds familiar, it is because NP6 is also a marketing-automation tool developed by the firm Chapvision. However, the NP6 PyPI account is not an official Chapvision account. Instead, it is a personal account linked to a Chapvision developer. It is unclear whether the company was aware of the existence of that account or the NP6HelperHttp and NP6HelperConfig tools. However, when informed about the existence of the packages, Chapvision confirmed to ReversingLabs that the helper tools were published by one of their employees. Around the same time, those packages were removed from PyPI.

The malicious packages uncovered, NP6HelperHttptest and NP6HelperHttper, employ typosquatting, using names that are nearly identical to one of the legitimate NP6 packages. The goal is to fool developers into downloading and opening the malicious wares, thereby facilitating further attacker access, as explained below. Zanki said the blurring of lines that separate official from unofficial or even malicious packages poses a major challenge to development organizations.

“Development organizations need to be aware of the threats related to supply chain security and open-source package repositories. They also need to be proactive about supply chain security. Even if they are not using open-source package repositories, that doesn't mean that threat actors won't abuse them to impersonate companies and their software products and tools."
—Karlo Zanki

Several open-source package repositories offer features to counter issues such as the one raised by the NP6 account. For example, both the npm and NuGet package managers allow publishers to register package or username prefixes (such as NP6) without the need to publish any content. That can prevent easy impersonation attacks that float malicious packages. “Think of it like registering a domain name, to prevent others from registering it before you," Zanki said.

Malicious script abusing DLL sideloading

Close examination of the malicious packages by ReversingLabs revealed that both contain a setup.py script, which extends setuptools commands with custom code designed to download two files:

• ComServer.exe, a legitimate file from Beijing-based Kingsoft Corp., and properly signed with a valid certificate belonging to the same company.
• dgdeskband64.dll, a malicious file that downloads and runs a stage-two payload.

Figure 1: setup.py - Downloading the files

Hiding malicious code in setup.py is a strategy that RL researchers have seen employed in previous attacks, including a December 2023 campaign. In that instance, custom setuptools commands were used to decode a Base64 encoded URL and fetch malicious, Base64-encoded Python commands that were then executed in a new process.

In this latest campaign, the setup.py Python script downloads the ComServer.exe and dgdeskband64.dll files, and then executes the signed file ComServer.exe in a new process.

ComServer.exe is a legitimate software application that is a part of the larger DriverGenius software package, a popular driver management tool. One of the purposes of ComServer.exe is to load a library, dgdeskband64.dll, and invoke its exported function Dllinstall, which is used to install a specified module inside the named software. The catch: The version of dgdeskband64.dll included in the malicious packages is not the legitimate version of the library that ComServer is expecting to find on the system where it is executed. Instead, the threat actor crafted their own version of dgdeskband64.dll to facilitate the attack, with the same Dllinstall export function as the legitimate Dgdeskband64.dll library. 

As the graphic below shows, the malicious dgdeskband64.dll contains only one exported function, rather than five.

Figure 2: Different exports for the legit and malicious dll

DLL sideloading is a well-documented hacking technique used by both cybercriminal and nation-state actors to load malicious code while evading detection. In one prominent example, the North Korea-linked Lazarus Group used DLL sideloading to replace an internal IDA Pro library, win_fw.dll, with a malicious DLL to download and execute a payload.

DLL sideloading also isn’t novel in the context of open-source software attacks. In February 2023, for example, RL researcher Lucija Valentić wrote about her discovery of Aabquerys, a malicious npm package that employed typosquatting on a legitimate npm module to carry out DLL sideloading of malicious components.

In that campaign, malicious actors targeted a Windows PE (portable executable) file, wsc_proxy.exe,  which is known to be vulnerable to the sideloading attacks. It has been involved in a number of malware campaigns. The malicious Aabquerys package, when executed, placed a dll file named wsc.dll with an exported function named run in the same folder as wsc_proxy.exe. When the legitimate wsc_proxy.exe executable is launched, it would invoke the run method from the sideloaded, malicious wsc.dll. That DLL then downloaded a third-stage malicious component, Demon.bin, from an external command and control site. 

In the case of the new PyPI DLL examples, sideloading was used to avoid detection of the malicious code, as was the case with Aabquerys. Specifically, that was carried out by loading malicious code located in an unsigned (and therefore untrusted) DLL from the context of a signed PE executable. With this method the attackers lower the risk that their malicious code will be detected by security tools.

Figure 3: Malware infection stages

Dllinstall brings malicious functionality

Looking closer at the various elements of this attack, it's clear that execution of the malicious code is achieved by registering an exception handler inside the Dllinstall export function. 

An exception handler is a common component of modern operating systems that manages exceptions encountered by running processes according to policies that are specific to the operating system in question. Actions could range from displaying an error message, to terminating the program generating the exception. 

In the case of this malicious campaign, however, the exception handler is used to pass along malicious code. Specifically, after the exception handler is registered, the program enters a loop where it divides numbers until division by zero happens, causing an exception and inherently transferring the code flow to the malicious subroutine.

The subroutine then establishes a connection with an external server (hxxps://us.archive-ubuntu.top/components/an.gif?type=lastest) and downloads an.gif. That action would not appear suspicious. However, the downloaded file is not a GIF file at all, but a payload file, x86_64 shellcode. Once downloaded, the shellcode is streamed to memory and the execution is then redirected to it through a callback registered for the NotifyIpInterfaceChange function. 

As with DLL sideloading, this method of abusing windows APIs to execute shellcode is not new. It has been observed and documented by researchers for close to 10 years. 

Analyzing the shellcode

Taking a look at the shellcode in question: we can see that it is encrypted using a simple XOR encryption with a moving key (Figure 4).

Figure 4: Shellcode decryption routine

After decrypting it, RL discovered traces of a PE file (Figure 5). The string “MZARUH'' appears in a place where the PE magic string “MZ\x90\x00” normally appears. Just that string alone is a good indicator that this is a Cobalt Strike Beacon.

Cobalt Strike is a security tool designed for red teams to aid in their penetration testing tasks. However, as with any tool (especially the ones designed for red teams), threat actors can leverage it without investing too much effort into building similar tools themselves.

[ See Webinar: How Cobalt Strike is weaponized against organizations ] 

The portable executable (PE) file that was decrypted was located just after the decryption routine, so it starts executing it right after it gets decrypted. The reason “MZARUH” is here instead of the normal PE magic string is that the CPU is trying to execute the bytes that make up that string. Coincidentally or intentionally, the string MZARUH and the data coming after it make up valid assembly instructions which can be executed normally.

Figure 5: Hex-view after decrypting and traces of a PE file

Evidence points to a wider campaign

Is this latest discovery a single instance or a part of a bigger campaign? The ReversingLabs Titanium Platform helps answer that question. 

Using ReversingLabs’ YARA Retro Hunt, RL researchers looked back in time to find other packages that share characteristics with previously discovered malicious packages. Retro Hunt scans all samples uploaded to RL's Titanium Cloud over the last three months and allows organizations to match them against a specific YARA rule.

In this case, the RL research team wrote a YARA rule to look for either the malicious C2 domain (us.archive-ubuntu.top) or the headers and user-agent used to download the fake dgdeskband64.dll and used that to perform a retro hunt, which turned up another sample that appears to be part of this campaign.

Figure 6: A1000 retrohunt matches

This second sample that turned up in Retro Hunt is also a DLL, but it is not exploiting DriverGenius’ ComServer.exe to load a DLL. Instead, it uses a different pair, including an .exe and target DLL, windowsaccessbridge-64.dll. Still, the functionality is identical, and the same URL downloads the same payload as the other PyPI packages, suggesting that this sample is part of the same campaign. 

The ReversingLabs Titanium Platform can also display the sources of analyzed samples, providing even more insight into the packages. Analyzing that data, it appears that the top level container for the second discovered sample is a zip archive that contains the .exe and target DLL, windowsaccessbridge-64.dll. Similarly, using the RL platform to check the sources for the top level container yielded a Titanium Cloud Service source match: the zip file was downloaded from the web location hxxps://cdn.0c.sk/1101012.zip.

That web location has been spotted in Titanium Cloud Services previously in connection with a malicious .NET sample. That .NET sample was observed downloading a ZIP file (hxxps://cdn.0c.sk/1101012.zip), which extracted an .exe file from the archive along with the malicious windowsaccessbridge-64.dll. It then launched the exe, which performs DLL sideloading in an identical fashion as the NP6HelperHttptest and NP6HelperHttper PyPI packages that initially caught the RL research team's attention. Furthermore, the .NET sample was self signed using a certificate issued to “Sex Shop SRL” (cert-serial:e3214c81339540a3804fca656f5aea7d). Data from the RL platform shows that this is not the first time this certificate was used to sign malware. In fact, ReversingLabs has samples signed with that same certificate that date as far back as June 2022.

Taken together, the data strongly supports the conclusion that the newly discovered PyPI packages are a part of the same campaign as the .NET sample, which implied that these packages are not a final act. Expect to see more malicious activity from this threat actor.

Conclusion

As this latest discovery shows, malicious actors at all levels of sophistication are increasingly turning to open source code and related infrastructure such as package managers to further their malicious campaigns. As they develop the tools and techniques threat actors deploy are becoming more diverse.

Bad actors that might have previously turned to well-tested techniques such as spearphishing to lure their targets into installing malware are adapting their methods. Planting malware in open-source package repositories and then waiting to see who downloads and uses the compromised code is proving to be a popular choice for malicious cyber-actors, who are increasingly using subtle means to insert their malicious wares into software supply chains. 

The emergence of DLL sideloading attacks are one clear example of this emerging attack vector. These attacks have been used for years by threat actors to increase their leverage and control within compromised environments while escaping detection, but less often seen in attacks leveraging open-source packages. This report suggests that may be changing. 

The discovery of these two malicious PyPI packages, as well as the subsequent discovery of a larger campaign and additional, malicious packages proves that threat actors are warming to the use of DLL sideloading to further software supply chain attacks — and inflict harm on both software producers and enterprises that rely on them. Over time, that is increasing pressure on both software producers and organizations to monitor the security and integrity of their software supply chain and the software packages that flow out of that supply chain.

Indicators of Compromise (IOCs)

Indicators of compromise (IoCs) are 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.

PyPI packages:

Additional Indicators: