From Intrusion Analysis to HijackLibs: DLL Sideloading Research

Introduction

Over the past few weeks, I’ve spent a growing amount of time researching DLL sideloading opportunities and contributing my findings to HijackLibs. What started with a single contribution has developed into multiple accepted entries, and I’ve since become one of the project's most active recent contributors.

My contributions so far have involved identifying executable/DLL combinations susceptible to DLL sideloading, validating the behaviour and documenting the resulting combinations for inclusion in the project.

In this post, I’ll cover how I approach that research, why I’ve enjoyed contributing to HijackLibs, and why I think the project is particularly useful from a defensive perspective. I’ll also take a closer look at one of my contributions: the VMware vmware-vmx.exe and libcrypto-3-x64.dll pairing, which was identified during a recent investigation being abused in the wild.

What is HijackLibs?

HijackLibs is an open-source project that maintains a curated collection of DLL hijacking and sideloading opportunities involving legitimate executables. It provides a valuable reference for defenders, threat hunters, detection engineers and red teamers looking to better understand how trusted applications can be abused to load attacker-controlled DLLs.

For defenders, HijackLibs provides multiple Sigma feeds and datasets that can be used to incorporate documented sideloading combinations into detection engineering and threat hunting workflows, including Sigma feeds for suspicious image loads, file writes and unsigned DLL loads. The available detection content can be found here: HijackLibs Detection Content

For red teamers, the project can help identify legitimate executable and DLL combinations that may be abused to achieve DLL hijacking during adversary simulation and security testing.

DLL sideloading is a well-established and repeatedly observed adversary technique. It is documented under MITRE ATT&CK T1574.001 - Hijack Execution Flow: DLL and has been observed across numerous intrusion sets and malware families. The technique can be particularly effective because malicious code is loaded through a legitimate executable, potentially allowing the initial process execution to appear trustworthy.

How I Find and Validate DLL Sideloading Opportunities

Threat Hunting for DLL Sideloading:

• Some DLL sideloading opportunities come from threat hunting for suspicious use of legitimate executables. I tend to focus on binaries running from locations that do not match their standard installation path, particularly unexpected or user-writable locations such as %LOCALAPPDATA% and suspicious subdirectories beneath %ProgramData%.

• Persistence mechanisms can also provide useful leads. For example, a .lnk file or scheduled task configured to launch a legitimate executable from %ProgramData% can be a useful lead, particularly when DLLs are being loaded from the same directory.

• Another useful indicator is a legitimate, digitally signed executable loading an unsigned DLL, particularly from the same directory or another non-standard location.

None of these behaviours necessarily indicate malicious activity in isolation. They become much more useful when correlated with other activity, such as an unusual execution path, recently created files, newly created persistence mechanisms, suspicious network connections or unexpected DLL loads.

DLL Sideloading Spotted in the Wild:

• A lot of opportunities also come directly from daily SOC investigations. While analysing alerts or following an intrusion chain, I will often come across legitimate executables being abused.

• In several ClickFix-style attack chains I've investigated, I've seen legitimate executables downloaded from remote infrastructure and placed alongside attacker-controlled DLLs before execution.

The next step is understanding which DLLs the executable expects to load. From a defensive perspective, this relationship is particularly interesting because the executable itself may be legitimate and digitally signed, while the DLL being loaded contains the malicious functionality.

Static analysis can provide an initial indication of the DLLs an executable expects to use. For example, VirusTotal's Imports table can be used to inspect DLLs referenced by the executable. To further confirm the behaviour, I can then execute the legitimate binary within an isolated environment and monitor its image loads using Sysmon Event ID 7 (Image Load), when Image Load logging is enabled.

Validation is important before treating an executable/DLL pairing as a viable sideloading candidate. I confirm that the legitimate executable actually loads the candidate DLL from the controllable location, ensure that the behaviour can be reproduced, identify the executable's expected installation paths, and check whether the combination is already documented by HijackLibs.

Once validated, I collect the relevant executable and DLL information, expected paths and supporting evidence required for a HijackLibs submission. This has become one of the parts of the project I enjoy most, as it turns an interesting observation into something that can be reused by other defenders and security researchers.

Case Study: VMware vmware-vmx.exe + libcrypto-3-x64.dll

My first contribution to HijackLibs documented the relationship between the legitimate VMware executable vmware-vmx.exe and libcrypto-3-x64.dll.

I originally identified the pairing during an investigation into malicious activity, where a renamed vmware-vmx.exe was being used as part of the attack chain. The renamed executable was legitimate and digitally signed by VMware, but the surrounding execution context was malicious.

Malicious Context

• vmware-vmx.exe was renamed to CobalDecoder.exe.

• CobalDecoder.exe was staged in an unexpected location beneath the %ProgramData% directory and was being launched by a newly created scheduled task.

• While CobalDecoder.exe was digitally signed and resolved to the legitimate VMware Workstation executable on VirusTotal, it was loading libcrypto-3-x64.dll from the same directory. VirusTotal detections and available threat intelligence associated the DLL hash with HijackLoader. VirusTotal Report

At a high level, the observed execution chain looked like this:

Scheduled Task
    ↓
%ProgramData%\random_directory_name\CobalDecoder.exe
    ↓
libcrypto-3-x64.dll

From there, I looked into the expected behaviour of vmware-vmx.exe, including its normal installation paths and DLL imports. The important part was determining whether libcrypto-3-x64.dll could be loaded from the same directory as the executable, rather than simply assuming the two files appearing together meant sideloading was taking place.

After validating the behaviour and confirming that it could be reproduced, I confirmed that the pairing represented a viable DLL sideloading opportunity. I then checked HijackLibs to ensure the combination had not already been documented before preparing the contribution.

The final submission documented the relationship between vmware-vmx.exe and libcrypto-3-x64.dll, along with the expected VMware paths and supporting evidence required by the project.

The contribution can be found here: HijackLibs Contribution

One of the useful outcomes of contributing the pairing to HijackLibs is that it also becomes available through the project's detection content. This provides defenders with a starting point for identifying suspicious use of the combination, such as libcrypto-3-x64.dll being loaded outside of expected VMware installation paths.

From One Finding to Multiple Contributions

Since my first submission, I have contributed multiple executable and DLL combinations to the project. Some have come directly from activity observed in the wild, while others have been identified through dedicated threat hunting of commonly abused or unexpected execution paths.

A few examples of my contributions include:

Conclusion

What started as a single DLL sideloading observation during an intrusion has developed into an area of research that I continue to spend time on. HijackLibs provides a practical way to turn individual findings into documented executable/DLL relationships that can be reused by defenders, detection engineers, red teamers and security researchers.

I plan to continue looking for unusual DLL loading behaviour during investigations and dedicated threat hunting, validating promising candidates and contributing new findings back to the project where possible.