In a new report by PwC UK security researcher Wietze Beukema, we find that nearly 300 executables on Windows 10 are vulnerable to DLL hijacking.
"It turns out that almost 300 executables in the System32 folder are vulnerable to relative path DLL hijacking. Did you know that with a simple VBScript some of these EXEs can be used to elevate these executions, completely bypassing UAC? " explained Beukema.
The vulnerability mentioned here is relative path DLL hijacking, which is when an attacker can cause a legitimate Windows executable to load an arbitrary DLL of their choice, likely with malicious intent.
It turns out nearly 300 executables in your System32 folder are vulnerable to relative path DLL Hijacking.
Did you know that with a simple VBScript some of these EXEs can be used to elevate such executions, bypassing UAC entirely?
Full blog post here ???? https://t.co/tBuFRk7ERg pic.twitter.com/ge1RXAqvtY
The problem of DLL hijacking
DLL hijacking attacks can be useful to a skilled attacker as they grant features such as arbitrary code execution, privilege escalation, and persistence on the target system.
The various DLL hijacking techniques covered by Beukema's blog post include DLL replacement, DLL proxy, DLL search order hijacking, phantom DLL hijacking, DLL redirection, WinSxS DLL replacement, and path DLL hijacking relative.
To demonstrate relative path DLL hijacking in practice, Beukema focused on the libraries present in the "C:WindowsSystem32" folder on a Windows 10 (v1909) machine.
It copied the legitimate winstat.exe process to the downloads folder on your system. He then ran the process monitoring tool, procmon, to better understand the DLLs the EXE is looking for during execution.
This allows us to identify all DLLs queried by each application, which will be all possible candidates for a hijackable DLL. But it doesn't automatically follow that all of these are also loaded (and therefore executed).
"The most reliable way to find out which DLLs are loaded correctly is to compile our own version of the DLL and have it write to a unique file after successful loading. If we repeat the above approach for all executables and target DLLs , this will result in a collection of files that tell you which DLLs are confirmed to be vulnerable to DLL hijacking."
What poses a challenge for the attacker, however, is to compile a custom version of the DLL that can be launched by the executable without any problems. To gain a reliable understanding of a legitimate DLL structure, Beukema recommends using tools like DLL Export Viewer for analysis.
This tool provides information about the structure of the DLL we are trying to recompile, enumerating all the external function names that would be duplicated in a DLL-hijacking exploit.
The researcher provided a comprehensive list of libraries that are good candidates for hijacking attacks.
He added: "These are not mere theoretical targets, they are tested and confirmed to work. The list includes 287 executables and 263 unique DLLs."
A CSV with a complete list of these libraries has been provided via GitHub.
Detection and prevention techniques
Beukema presents some prevention methods that can be used to stop such attacks like looking for activity in the simulated windows folder in case one is present on your machine.
Also, adjusting the UAC settings to "always notify" can help prevent attacks like this if the end user is savvy enough to understand what is about to be performed.
Another strategy is to monitor DLL build and load instances from unexpected file paths:
"You can look to build or load any of the aforementioned DLLs from unexpected paths, mostly in temporary locations like %appdata%.
After all, the name of the (legitimate) application that loads the DLLs can be changed, but the filenames of the DLLs are always corrected."
When building applications, suggests Beukema, developers should apply the use of absolute and non-relative paths to load DLLs, among several other techniques.
None of this alone can be foolproof enough. However, when properly applied together, preventative measures such as those explained by the researcher can prevent DLL hijacking attacks in the long run.
