THREAT ANALYSIS REPORT: DLL Side-Loading Widely (Ab)Used

This Threat Analysis Report is part of the Purple Team Series. In this series, the Managed Detection and Response (MDR) and Threat Intelligence teams from the Cybereason Global Security Operations Center (GSOC) explore widely used attack techniques, outline how threat actors leverage these techniques, describe how to reproduce an attack, and report how defenders can detect and prevent these attacks.

Purple Team Series reports include three sections:

• The red team section creates a version of a known attack method
• The blue team section describes the attack in detail and introduces real-life examples
• The purple team section describes how to detect such attacks

DLL Side-Loading Attacks

DLL side-loading attacks leverage vulnerable software to load malicious DLLs that enable the malware to persist and evade security mechanisms.

Key Points

• DLL side-loading is a popular technique: Attackers use DLL side-loading in a large number of attack scenarios, possibly because vulnerable targets are relatively easy to find.
• DLL side-loading will remain popular: The MITRE database shows examples of DLL side-loading in 2017, though initial evidence of the technique dates from earlier. Attackers currently use DLL side-loading and will likely continue to use this technique. 
• DLL side-loading can be challenging to detect: Security analysts must know and deliberately hunt for signs of DLL side-loading. 

The DLL Side-Loading Technique

DLL side-loading attacks use the DLL search order mechanism in Windows to plant and then invoke a legitimate application that executes a malicious payload. Threat actors commonly use this technique for persistence, privilege escalation, and defense evasion. Traditionally, the technique is called DLL side-loading because the attacks abused the Microsoft SxS (Side by Side) directory.

Why Side-Loading?

DLL side-loading has several important advantages:

• DLL side-loading attacks often use legitimate, trusted, and even signed executables as their initial loader. 
• A number of security products and configurations have "safe lists" that specifically include many of these trusted executables.
• Even if they aren’t safe-listed explicitly, there is a high likelihood that a detection involving a trusted executable will be listed as a false positive.

DLL Side-Loading Initiation

The challenge of any sort of DLL Side-Loading attack is that the attacker needs “write” permissions to the directory where the DLL needs to be in, at load time.

Traditionally, DLL attacks involved taking advantage of an incorrectly configured manifest file of an executable to drop and successfully execute a malicious DLL in the Microsoft SxS (Side by Side) directory. This is where the ‘’ aspect of the name originated from.

Nowadays, attackers can circumvent the permissions challenge by employing a method where they provide their own DLL to be used for the side-loading.

Example Attack

Attackers who conduct a DLL side-loading attack might follow these steps:

• Find a trusted executable that has a DLL side-loading vulnerability.
• Construct a malicious DLL that has the same name as a legitimate DLL.
• Package the DLL and the trusted executable in the same directory as several hidden files.
• Create a malicious shortcut (LNK) file and use this LNK file for execution:
• The LNK file masquerades as a legitimate file. The attacker tricks the user into executing the LNK file.
• The parameters of the LNK call the trusted executable.
• When the trusted executable starts, because of the way Windows searches for files, the trusted executable finds and loads the malicious DLL before the executable finds the legitimate DLL.
• Compress all files needed for the attack in an archive file such as a ZIP file, and deliver that archive to victims through phishing.

Known Side-Loading Attacks

DLL side-loading is a very popular attack technique that MITRE has tracked since 2017. Cybereason has addressed this technique in the following and other publications:

• Operation CuckooBees: A Winnti Malware Arsenal Deep-Dive 
• Operation SoftCell
• Attackers incriminate a signed Oracle process for DLL Side-Loading, running Mimikatz

For descriptions of several more DLL side-loading attacks, see the Blue Team section below.

Red Team: Building and Delivering a DLL Side-Loading Attack

Note: Our example uses an atomic test from the Red Canary Atomic Red Team framework. The Cybereason team modified the test source code and delivery mechanism of this test.

The process of building a DLL side-loading attack is as follows:

• Find an executable file that includes a side-loadable DLL.
• Determine the exports of the executable file.
• Build the malicious DLL.
• Weaponize and deliver the malicious DLL.

Find an Executable File

Lists of side-loadable DLLs are available from sources such as the XForceIR SideLoadHunter repository in GitHub and the Hijack Libs project. For more information about the Hijack Libs project, see the Hijack Libs section in this report. 

To manually find executables that are vulnerable to DLL side-loading: 

• In any program directory, locate all executable files.
• Copy these executable files to an empty directory.
• Run the files and observe error messages.
• If an executable file returns a "DLL file not found" error message, start the Microsoft Sysinternals Process Monitor tool, and then run the executable file again.
• Observe the Process Monitor output.

If Process Monitor shows that the executable file tries to locate missing DLL files in the same directory where you run the executable file or in other locations, you might be able to use this executable file in a DLL side-loading attack:

"Libcurl.dll was not found" error message 

Example: GUP.exe

A DLL side-loading vulnerability affects an older version of GUP.exe. This file is the executable for WinGup, a generic updater for Windows executables that is found in Notepad++, the popular Notepad replacement application. The location of this executable is generally the \Program Files\Notepad++\updater\ directory. 

To determine whether GUP.exe could offer a DLL side-loading possibility, we copied GUP.exe to an empty directory and then ran the file. We received the following error message:

The code execution cannot proceed because libcurl.dll was not found. Reinstalling the program may fix this problem.

Next, we started Process Monitor, and then we ran GUP.exe from the empty directory again. The GUP.exe file attempted to locate the libcurl.dll module in the same directory, as well as in multiple additional locations: 

Process Monitor output showing GUP.exe attempting to locate libcurl.dll

The screenshot shows GUP.exe attempting to locate the libcurl module in the same directory as well as multiple locations that fall in line with the Windows DLL search order. This tells us that we may be able to create our own libcurl.dll that would be loaded by GUP.exe. 

Determine the Exports

Next, we loaded GUP.exe into IDA Pro to see the import address table (IAT) and found the names of the required functions and exports that the executable imports. The GUP.exe file imports several exports from libcurl.dll:

We could reference the cURL documentation for these exports and build the functions as needed: 

Example cURL documentation

Note: The source code from the Red Canary atomic test project shows that the exports do not have to be functional. To facilitate the attack process, the header section of the code only needs to declare these exports:

Header section declaring exports for libcurl.dll 

Build the Implant DLL

We stored the malicious command in the DllUnregisterServer() method. This method executes at load time when DLL_PROCESS_ATTACH is called from DllMain():

The DllUnregisterServer() method storing the malicious command

At load time, our malicious version of libcurl.dll executed a PowerShell command that retrieved a Meterpreter payload from a remote server. 

Weaponize and Deliver the Implant DLL

We used the following attack path:

• The LegitDocument.zip archive opens a LNK shortcut file.
• The LNK shortcut file starts the cmd.exe process.
• The cmd.exe process starts the GUP.exe process.
• The GUP process side-loads the malicious libcurl.dll file.
• The malicious libcurl.dll file starts the cmd.exe process.
• The cmd.exe process starts the PowerShell.exe process, which loads the malicious command.
• The PowerShell.exe process connects to a command and control center.

The following diagram shows the attack path we followed:

To weaponize our attack, we created a shortcut (LNK) file that we modified to call cmd.exe and execute GUP.exe. Gup.exe loads the malicious libcurl.dll file and launches the Meterpreter payload.

To make the LNK file appear legitimate, we changed the icon to look like a document file icon, added comments that appeared to be file metadata, and marked GUP.exe and libcurl.dll as hidden files. We then packaged all the files in a password-protected ZIP file:

Weaponized LNK file

Staged ZIP file ready for delivery 

On execution of the LNK, PowerShell launches as expected and we have our meterpreter session:

Meterpreter session 

Analyze the Resulting Processes 

This section describes the analysis of the resulting telemetry created on the victim machine.

Process Tree

After we started the malicious DLL we had created, several processes started.

The Cybereason process tree shows that the LNK file executed GUP.exe. When GUP.exe loaded our malicious DLL, the DLL created child processes of cmd.exe and PowerShell.exe so that the Meterpreter payload could execute:

Process tree showing cmd.exe and PowerShell.exe child processes as seen in the Cybereason Defense Platform

Cybereason detected and created a MalOp for this behavior based on the PowerShell.exe loader:

Child processes resulting from the Meterpreter session commands as seen in the Cybereason Defense Platform

Blue Team: Analysis of DLL Side-Loading Attacks

DLL side-loading attacks are common and widespread. Well-known attacks include the Netwire and Remcos and Kaseya attacks in 2021 and Operation SoftCell in 2018. In 2022, the Mustang Panda group leveraged DLL side-loading to load PlugX, a random access Trojan (RAT) with multiple embedded modules that has become widely popular among threat actors.

For more information about the popularity of the DLL side-loading attack technique, see Hijack Labs.

NetWire and Remcos (2021)

In March 2021, a campaign targeting US taxpayers delivered two prominent commercial RATs, NetWire and Remcos, with documents that purported to contain tax-related content:

The malicious libcrypto-1_1.dll is side-loaded by the legitimate openvpn-gui.exe, ultimately loading Remcos/NetWire as seen in the Cybereason Defense Platform

The NetWire RAT injects malicious code into tracert.exe, which downloads the OpenVPN client (openvpn-gui.exe) along with a trojanized DLL file called libcrypto-1_1.dll. When a user executes this DLL file, the malware side-loads libcrypto-1_1.dll to the OpenVPN client, ultimately injecting the malicious code into a notepad.exe process that corresponds to NetWire.

Kaseya (2021)

In 2021, a threat actor used Kaseya, a managed service provider (MSP), to deploy REvil, a ransomware as a service (RaaS) program, in a supply chain attack on companies across the globe.

The REvil malware gained initial access through the Kaseya agentmon.exe agent, then leveraged MsMpEng.exe, the Microsoft Defender vulnerability binary, to side-load a malicious mpsvc.dll module:

Kaseya compromised agent loaded the legitimate msmpeng.exe, which side-loaded a malicious version of mpsvc.dll as seen in the Cybereason Defense Platform

Operation SoftCell (2019)

In 2019, Cybereason identified an advanced persistent attack targeting telecommunications providers that had been underway for several years. One phase used the PoisonIvy (PIVY) RAT to maintain access in the compromised environments:

Runhelp.exe side-loads ssMUIDLL.dll, and spawns nslookup.exe as seen in the Cybereason Defense Platform

This attack used a DLL side-loading technique to drop the PIVY payload along with RunHelp.exe, a trusted and signed Samsung tool:

• The malware created a Nullsoft Scriptable Install System (NSIS) package that contained a legitimate, signed Samsung tool.
• When a user executed the NSIS package, the installer script extracted the Samsung tool and added a fake DLL that had the same name as a legitimate DLL, ssMUIDLL.dll. The Samsung application requires ssMUIDLL.dll.
• The Samsung tool loaded the fake ssMUIDLL.dll file, which contained a PIVY stager.
• The fake DLL decrypted a blob payload in the same folder. This folder also contained the PIVY payload.
• To achieve persistence, the PIVY malware created a rogue scheduled task.

Investigation: Mustang Panda Loading PlugX

We analyzed a PlugX malware sample to determine how this malware leverages the DLL side-loading technique.

Mustang Panda, a Chinese cyberespionage group, has targeted many organizations with a revised version of the PlugX malware. PlugX is a RAT embedded with multiple modules.

The Cybereason GSOC team investigated a 2022 incident in which the Mustang Panda group used a set of files stored on a USB device to load the PlugX payload

The USB device contained four files: 

• D:\AdobeHelp.exe: A malicious executable file that triggers DLL side-loading
• D:\RECYCLERS.BIN\AAM Update.exe: A legitimate Adobe update executable file that is vulnerable to DLL side-loading
• D:\RECYCLERS.BIN\hex.dll: A loader DLL file that executes the PlugX payload
• D:\RECYCLERS.BIN\adobeupdate.dat: The encrypted payload

Note: The names of these files can vary. Many payloads have a .dat extension:

The files used in this attack

The image below represents the attack chain for this incident:

In that incident : 

• AdobeHelp.exe is launched by the victim, upon inserting the USB key 
• This, in turn, executes the legitimate AAM Update.exe file
• AAM Update.exe side-loads a malicious hex.dll
• Hex.dll loads PlugX after decrypting the payload stored in adobeupdate.dat
• PlugX then executes the post-infection actions : Reconnaissance and Command & Control

Initial Access: PlugX Loading

To access a victim's computer, the threat actor executes the initial binary, adobehelp.exe. The Cybereason NGAV engine detects this binary: 

Adobeupdate.exe file element as seen in the Cybereason Defense Platform

The signer of the file, Wuhan Aixinsen Technology Co., Ltd., is also the signer for the other malicious executable files in this example. The following process tree results from the execution of adobehelp.exe:

PlugX loading process tree as seen in the Cybereason Defense Platform

First, adobehelp.exe executes adobeupdate.exe, a legitimate binary that is digitally signed by Adobe. However, because adobeupdate.exe is vulnerable to DLL side-loading, adobeupdate.exe side loads a module, hex.dll, from the RECYCLERS.BIN folder instead of loading the legitimate version of hex.dll from its legitimate folder.

The hex.dll module is actually the PlugX loader. The hex.dll module loads and then decrypts adobeupdate.dat to obtain the PlugX payload. The Loaded Modules screen in the Cybereason platform shows the adobeupdate.exe and aam update.exe processes loading the hex.dll file:

Adobeupdate.exe and aam update.exe load hex.dll as seen in the Cybereason Defense Platform

Mustang Panda side-loads the malicious hex.dll file in all subsequent Adobe processes. The Cybereason platform shows access to the hex.dll file in file events related to adobeupdate.exe: 

File events associated with the adobeupdate.exe process as seen in the Cybereason Defense Platform

Process Monitor also shows the hex.dll file loading:

Process Monitor showing hex.dll loading 

The hex.dll module loads and then decrypts adobeupdate.dat to obtain the actual PlugX payload. Then, when hex.dll has loaded PlugX, the binary copies the different files to another folder, C:\Users\[username]\AAM Updatevlm\, and executes AAM Update.exe from that folder.

The system events related to these processes show adobeupdate.exe reading the adobeupdate.dat file, which is the encrypted PlugX payload: 

Process Monitor showing adobeupdate.exe reading adobeupdate.dat

Persistence 

This sample contains a persistence mechanism that has three phases. The malware: 

• Copies the files to a folder on the machine main volume.
• Creates a registry key to ensure that the malware executes automatically each time a user logs on to the computer.
• Maintains remote access by connecting to attacker-controlled endpoints.

File Copying

To ensure that a copy of the malicious PlugX loader will remain on the machine even if the USB device is removed, the binary creates a specific folder named C:\Users\[username]\AAM Updatevlm\, and copies the following files to this folder:

• AAM Update.exe

• hex.dll

• Adobeupdate.dat

• AdobeHelp.exe

Adobeupdate.dat creates C:\Users\[username]\AAM Updatevlm\ and copies files from the USB device

Registry Manipulation

In the host’s Windows registry, the binary sets the following paths to create an Autorun key so that PlugX runs each time a user logs on to the machine: 

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run\AAM Updatevlm
• HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run\AAM Updatevlm

Registry events associated with the adobeupdate.exe process

Process Monitor shows this behavior: 

Process Monitor showing the set registry values 

Remote Connections

To maintain remote access, the aam update.exe process connects to IP address 45.251.240[.]55: 

Network connections from the aam update.exe process as seen in the Cybereason Defense Platform

This IP address, which is linked to Mustang Panda, tries to contact a URL of http[:]//45.251.240[.]55:443/update. The malware connects to TCP ports 443 (HTTPS), 8080, and 8000.

Reconnaissance

When the filename binary is configured to infect other devices through a USB, the sample executes a BAT file automatically by using the following command:

C:\Windows\system32\cmd.exe /c D:\RECYCLERS.BIN\FEAC369263B0908F\tmp.bat

This BAT file issues the following OS and network reconnaissance commands: 

• Ipconfig
• Netstat
• Arp
• Systeminfo
• Tasklist 

This action creates the following process tree. In this case, this binary is run with the -app argument:

Process tree showing OS and network reconnaissance when USB infection mode is enabled as seen in the Cybereason Defense Platform

Purple Team: Detection and Hunting Strategies

How to Detect DLL Side-Loading 

To detect DLL side-loading attacks, you can look for specific warning signs or consult open source projects. Signs of DLL side-loading attacks include unsigned DLLs in signed portable executable (PE) files, suspicious loading paths, and timestamps that show gaps between the PE compilation time and DLL loading time:

Signed PEs Loading Unsigned DLLs

Legitimate PEs are most often digitally signed, and the DLLs that these PEs load are also often digitally signed. A legitimate, digitally signed PE loading an unsigned DLL can be a sign of an attack, especially if processes are running that have elevated privileges. 

Suspicious Loading Paths

DLL side-loading often abuses the Windows DLL search order so that malicious files load before safe files. The paths for these files can include signs that the files are malicious. The paths to legitimate, verified software files generally include clear references to well-known businesses or products. For example, the path to a Cybereason DLL file might be C:/<username>/programs/Cybereason/1234.dll. If a DLL loads from a path that includes text such as “Desktop”, “Downloads”, or “%programdata%”, the DLL might be malicious.

Compilation Timestamp

Each PE has a timestamp that indicates the time when the binary file was compiled. If the compilation timestamp for the executable is very different from the timestamp for one of the PE's loaded DLLs, the loaded DLL could be a malicious implant.

Open Source Projects

Several open source projects address DLL side loading, including Windows Feature Hunter, DLL Spy, and Hijack Libs.

Windows Feature Hunter 

Windows Feature Hunter (WFH) is a proof of concept Python script that uses Frida, a dynamic instrumentation toolkit, to help identify common vulnerabilities or “features” in Windows executables. 

WFH can automatically identify potential DLL side-loading and Component Object Model (COM) hijacking opportunities at scale:

Screenshot of the help output of WFH

DLLSpy

DLLSpy detects DLL side-loading and and other side-loading attacks in running processes, services, and static PEs by using three approaches:

• Dynamic: The tool scans the loaded modules for each process by iterating the loaded module list for the process. DLLSpy then tries to write to each module's file location on disk to determine if the module could be side-loaded or overwritten.
• Static: The tool searches the binary files of currently running processes for strings that contain a DLL name or DLL path.
• Recursive: The tool scans all DLLs in the previously examined processes, looking for any additional DLLs that these process DLLs have loaded. The tool then determines whether any found DLLs are vulnerable to side-loading.

Example output from DLLSpy

Hijack Libs

Hijack Libs provides a list of PEs that are vulnerable to DLL side-loading and other DLL hijacking attacks. The repository enables defenders to gain understanding on potentially targeted DLLs within their environments. 

Hijack Libs entry for wsc.dll

Cybereason GSOC MDR

To efficiently detect DLL side-loading attacks, Cybereason recommends the following:

• In the Cybereason platform, enable the Signature and Artificial Intelligence (AI) features, and make sure to select the Detect and Prevent modes for both features.
• Be careful with files that originate from external sources, including email and the internet.
• Contact a Cybereason Defender. The Cybereason MDR team provides custom hunting queries for detecting specific threats. To find out more about threat hunting and managed detection and response with the Cybereason Defense Platform, see Managed Detection and Response.
• If you are a Cybereason customer, see the NEST for more information, including custom hunting queries for detecting this threat.

Cybereason is dedicated to teaming up with Defenders to end cyber attacks from endpoints to enterprise and everywhere else. Learn more about Cybereason XDR powered by Google Chronicle, check out our Extended Detection and Response (XDR) Toolkit, or schedule a demo today to learn how your organization can benefit from an operation-centric approach to security.

Researchers

	Derrick Masters, Principal Security Analyst, Cybereason Global SOC Derrick Masters is a Senior Security Analyst with the Cybereason Global SOC team. He is involved with threat hunting and purple teaming. Derrick's Global Information Assurance Certification (GIAC) professional certifications include GIAC Certified Forensic Analyst (GCFA), GIAC Certified Detection Analyst (GCDA), GIAC Certified Penetration Tester (GPEN), GIAC Python Coder (GPYC), and GIAC Security Essentials Certification (GSEC).
	Loïc Castel, Principal Security Analyst, Cybereason Global SOC Loïc Castel is a Principal Security Analyst with the Cybereason Global SOC team. Loïc analyses and researches critical incidents and cybercriminals to better detect compromises. In his career, Loïc has worked as a security auditor in well-known organizations such as the French National Agency for the Security of Information Systems (ANSSI) and as Lead of Digital Forensics & Incident Response at Atos. Loïc loves digital forensics and incident response, but is also interested in offensive aspects such as vulnerability research.
	Chen Erlich, Lead Threat Researcher, Cybereason Nocturnus Chen has almost a decade of experience in threat intelligence and research, incident response, and threat hunting. Before joining Cybereason, Chen spent three years dissecting advanced persistent threats (APTs), investigating underground cybercriminal groups, and discovering security vulnerabilities in known vendors. Previously, he served as a Security Researcher in the Israel Defense Forces (IDF).