Recently, X-Force Red released a tool called Windows Feature Hunter, which identifies targets for dynamic link library (DLL) side-loading on a Windows system using Frida. To provide a defensive counter-measure perspective for DLL side-loading, X-Force Incident Response has released SideLoaderHunter, which is a system profiling script and Sysmon configuration designed to identify evidence of side-loading on Windows systems. This post will talk about why IBM X-Force thinks the tool is needed, describe its functions and analyze some use cases.

What Is DLL Side-Loading?

In Microsoft Windows, programs can define which libraries are loaded at runtime by specifying a full path or using another mechanism such as a manifest. A program manifest is an external file or embedded resource within an application used to manage the names and versions of shared side-by-side assemblies to which the application should load upon execution. A program manifest can include DLL redirections, filenames or full paths. If a manifest refers to only a library filename, it is considered a weak reference and is vulnerable to a DLL side-loading attack.

If a weak reference is made to a library, Windows attempts to locate the DLL through a pre-defined search order. The first location that Windows will search is the directory from which the application is loaded.

A DLL side-loading attack is an adversarial technique that aims to take advantage of weak library references and the default Windows search order by placing a malicious DLL file masquerading as a legitimate DLL on a system, which will be automatically loaded by a legitimate program.

For more information regarding DLL side-loading, reference MITRE ATT&CK Technique T1574.002.

DLL Side-Loading Threat Landscape

DLL side-loading is not a new technique, as the search-order hijacking vulnerability within Windows has existed since Windows XP. X-Force has observed DLL side-loading used by the Metamorfo banking Trojan, which drops malicious MSI files that extract a signed binary and a malicious DLL to execute a second-stage malware loader. Due to the default search order built into Windows, the signed binary will load the malicious DLL and continue the malicious execution flow.

While not the most common technique leveraged by threat actors, DLL side-loading is increasingly being used by ransomware operators, which have leveraged DLL side-loading to execute the ransomware payload to evade detection by security products.

For example, ransomware operator REvil leveraged a DLL side-loading vulnerability within a Windows Defender executable (MsMpEng.exe) to load a malicious DLL named mpsvc.dll containing the ransomware payload.

Detecting DLL Side-Loading

X-Force has not observed many threat actors or malware overwriting existing binaries or modules on a system to execute a DLL side-loading attack because this could cause a system to crash or create errors that could lead to detection.

Instead, threat actors or malware that have leveraged DLL side-loading commonly rely on two behaviors prior to executing an attack:

1. Plant a signed executable in a target directory along with the malicious DLL.
2. Move a Windows executable from System32 or SysWow64 on the target machine to a non-standard directory and plant the malicious DLL within the same folder.

The first use case is a fairly straightforward detection methodology. While the binary may be signed, its execution would still be considered an anomaly within a program execution dataset. In the previously mentioned Metamorfo example, the malware planted Avast’s memory dump utility AVDump32.exe, renamed as jesus.exe, which side-loaded a malicious DLL named dbghelp.dll.

In this example, identification of jesus.exe was accomplished by performing frequency analysis on the filenames recorded within a program execution dataset.

Figure 1: Frequency analysis on binary name in program execution dataset

The second use case can be more difficult to detect as it commonly leverages trusted, standard Windows applications to execute the malicious DLL, which helps the malicious activity blend in with non-malicious program execution data. There are detection opportunities through frequency analysis of the full path of the binary within a program execution dataset, but without any sort of filtering this analysis is far too inefficient.

Instead, the program execution dataset can be filtered only to include executable names that reside within System32 or SysWow64 by default. In this case, the analysis would be performed on all program execution data associated with System32 or SysWow64 executables where the full path of the binary did not match the default.

To perform this analysis, create a lookup table of the default System32 and SysWow64 executables from Windows systems, which will act as a control dataset, against which defenders can identify anomalies.

The following PowerShell script will enumerate executables within System32 and SysWow64 and export the results into a CSV.

Using sysbins.csv as a control group enables identification of program execution and provides evidence of Windows applications outside of their default System32 or SysWow64 directories.

Figure 2: Frequency analysis on the full path of System32 binaries

It is important to note that threat actors can evade detection using filename matching by renaming the binary executable, as the side-loading technique will remain viable regardless of the name of the executable.

Figure 3: Side-LoadSide-Loading mspaint.exe (renamed as notmspaint.exe) with msftedit.dll

One way to detect renamed executables is through further profiling of the hash values of System32 and SysWow64 executables on Windows machines or collecting the internal name of executable files from target systems. Some process execution monitoring solutions like Sysmon will capture the internal name of an executable upon execution. Additionally, PowerShell has the capability to enumerate the original filename of an executable after it has been renamed.

Figure 4: Listing original filename attribute in PowerShell

The following script will enumerate a list of executable hashes in the System32 and SysWow64 directories, which can also be used as a control dataset to identify standard Windows executables in non-standard locations.

Figure 5: PowerShell script to collect file hashes

However, the aforementioned detections are more effective when there is centralized process execution data and the ability to establish baselines of activity over time within an environment. That’s very rare during an investigation.

To overcome this challenge, X-Force deploys data collection utilities to gather metadata from endpoints at scale. One of those utilities is SideLoadHunter, which will profile the endpoint for DLLs and executables within user profiles, System32 and SysWow64. Once the executables and DLLs have been profiled, X-Force performs comparative analysis to identify possible evidence of DLL side-loading through filenames, hash values and internal names. Additionally, program execution artifacts are analyzed for evidence of side-loaded executables that no longer exist on disk. This tool has been ported over to PowerShell and is available to download here.

SideLoadHunter

The main functions of SideLoadHunter are:

• Get-SideLoadDetect: Comparative analysis function designed to identify situations where a System32/SysWow64 executable is located in a userland directory along with a DLL that matches a System32/SysWow64 DLL name but is not signed by Microsoft.
• Get-SusShimcache: To provide some detections for side-loaded executables that are no longer on disk, SusShimcache will analyze ShimCache entries for System32 and SysWow64 executables that have executed from a non-standard location.
• Get-SusExecs & Get-SusDLLs: Profiles a system to locate System32 and SysWow64 executables and DLL files that do not exist within their default location.

Figure 6: Side-Loadhunter.ps1 execution

SideLoadDetect

Through continued research of executable files vulnerable to side-loading on Windows systems, X-Force has identified a list of executable names and the associated DLLs that can be side-loaded.

A full list of side-load targets can be found here.

To assist in the real-time detection of these side-load targets, X-Force has migrated the known side-load list into a Sysmon configuration aimed to log module loads for the associated executables and DLLs.

Sysmon configuration can be found here.

Figure 7: Sysmon event from Side-Loadhunter.xml

More Than System32 and SysWow64

While malware and adversaries commonly target executables within the System32 and SysWow64 directories for side-loading, the potential to side-load a DLL into an executable is not restricted to those directories. For example, through collaborative efforts between X-Force Incident Response and X-Force Red, the executable OneDriveStandaloneUpdater.exe, which exists within %userprofile%\appdata\local\Microsoft\OneDrive by default on Windows 10 systems, can be side-loaded via WofUtil.dll, which resides in %windir%\system32\ by default.

Figure 8: Side-Loading OneDriveStandaloneUpdater.exe with WofUtil.dll

X-Force is currently conducting further research to create a more exhaustive list of executable and DLL files that are targets for side-loading, so stay tuned for future updates.