Wietze Beukema: almost 300 Windows 10 executables are vulnerable to DLL hijacking
I've already written about DLL Hijacking, but today I'd like to share a really interesting research by Wietze Beukema.
Researcher discovered that almost 300 Windows 10 executables are still vulnerable to DLL hijacking.
The hijacking techniques covered by the Beukema's research [1] includes:
DLL replacement: replace a legitimate DLL with an evil DLL. This can be combined with DLL Proxying, which ensures all functionality of the original DLL remains intact.
DLL search order hijacking: DLLs specified by an application without a path are searched for in fixed locations in a specific order. Hijacking the search order takes place by putting the evil DLL in a location that is searched in before the actual DLL. This sometimes includes the working directory of the target application.
Phantom DLL hijacking: drop an evil DLL in place of a missing/non-existing DLL that a legitimate application tries to load.
DLL redirection: change the location in which the DLL is searched for, e.g. by editing the
%PATH%environment variable, or.exe.manifest/.exe.localfiles to include the folder containing the evil DLL.WinSxS DLL replacement: replace the legitimate DLL with the evil DLL in the relevant WinSxS folder of the targeted DLL. Often referred to as DLL side-loading.
Relative path DLL Hijacking: copy (and optionally rename) the legitimate application to a user-writeable folder, alongside the evil DLL. In the way this is used, it has similarities with (Signed) Binary Proxy Execution. A variation of this is (somewhat oxymoronically called) ‘bring your own LOLbin’ in which the legitimate application is brought with the evil DLL (rather than copied from the legitimate location on the victim’s machine).
The research
Beukema focused on the libraries present in the “C:\Windows\System32” folder on a Windows 10 (v1909) machine:
To monitor which DLLs each process attempts to load, we’ll use the well-known Procmon tool. The approach taken is therefore: (1) copy trusted executable to a user-writable location; (2) run copied executable; (3) use Procmon to identify DLLs looked for in user writable location.
This allows us to identify all DLLs queried by each application, which will be all potential hijackable DLL candidates. But it does not automatically follow that all of these are also loaded (and therefore executed).
Then, the researcher has provided a comprehensive list of libraries that are good candidates for hijacking attacks, provided via GitHub [2].
these are not mere theoretical targets, these are tested and confirmed to be working. The list comprises 287 executables and 263 unique DLLs.