As we know, Dynamic-link library(DLL) Side loading / DLL Hijacking is nothing new, nor is Windows Side-by-Side; however, side loading is handy from an adversarial tradecraft perspective, be it for establishing initial access, persistence, privilege escalation, or execution within an environment.
Dynamic-Link Library search order hijacking, often shortened to DLL hijacking, exploits an application's execution flow via external DLLs. By hijacking the search order used to load legitimate content, it is possible to force an application to load a malicious DLL. When a vulnerable application(I've found a few in the wild that are non-WinSxS binaries, including a CVE I got in 2020 for Nvidia) is set to run with elevated privileges, any malicious DLL loaded into it inherits those elevated privileges, thus enabling privilege escalation.
The application's behaviour often remains undisturbed since malicious DLLs are designed to seamlessly load the legitimate ones they replace or in cases where DLL paths aren't explicitly defined.
This discreet DLL launching capability presents myriad opportunities.
In scenarios where the use of Rundll32 is impractical, diverting the execution flow of a trusted binary, adhering to the principle of living off the land, offers a means to deploy malicious DLLs from diverse locations and inject them into legitimate processes.
What this also means is we can leverage legitimate binaries and multiple versions of said binaries for malicious purposes, taking DLL hijacking out of the equation for a moment; what it means is there are several copies of PowerShell and cmd.
Hunt out binaries in WinSxS. Map out DLLs being called from $currentdir.
Run HelloJackHunter and point it in a for loop at the DLLs. Hunting available binaries is relatively easy and just requires some PowerShell to start; the advice would be to do the research on your own dev system and replicate more in the target environment because none of the one-liners supplied are meant to be opsec safe and are more for highlighting quick paths to get the stuff you need/want.
To do this manually, Process Monitor can be leveraged to search through running processes for all DLLs loaded and called by running applications.
Once a list has been achieved of pwnable DLLs, the next step is to mass-build malicious DLLs; this is where HelloJackHunter comes into play.
If you are hunting for non WinSxS binaries, then you might want to add additional filters to exclude standard and trusted directories from which DLLs are loaded, such as C:Windows or any other directory that you consider safe.
The tool scans available DLLs and leverages dumpbin.
As a high-level proof of concept, the following code can be used to prove DLL hijacking; again, this is nothing new.
Occurs when the DLL is unloaded from the process's memory, which can happen either because the process is terminating or because the DLL is being unloaded dynamically by a call to FreeLibrary.
This case is typically used for cleanup tasks such as releasing shared resources, unregistering hooks, and deallocating memory used by the DLL to ensure a clean exit with no resource leaks.
The various functions are nothing new about DLL hijacking.
The new part where HelloJackHunter comes into play is mapping the available functions to trigger when the DLL is executed.
Each can be exploited with a DLL in the local directory and called to execute functions in search order hijacks.
It's important to note that YARA does not directly monitor system behaviour or real-time DLL loading activities.
To effectively monitor DLL loading paths in real-time, you would typically use other tools or system monitoring techniques in combination with something like Sysmon or similar.
This Cyber News was published on blog.zsec.uk. Publication date: Sun, 12 May 2024 09:13:05 +0000