DLL Hijacking
DLL Hijacking
Simply put, DLL hijacking refers to tricking a legitimate application into loading an arbitrary DLL. There are various approaches to achieving this, and we will go over some of these in this article.
DLL hijacking is a classic technique used by malware. It has been used for at least a decade and is still relevant. Even some APTs are using this technique to this day. It is a simple technique, yet it is surprisingly stealthy and difficult to detect. This is likely what makes it such a popular technique.
Load order hijacking
Typically when a DLL is imported by a program, only its base name is provided, not a full path. When only a name is given, the OS will search for it in specific paths, in a specific order. Attackers can abuse this fact to evade detection, escalate privileges and more. If we are able to place our copy-cat DLL in a path which is higher up in the search order, than the real one, then our DLL will be loaded, granting us execution.
ProcMon can be used to find a hijackable DLL, by looking at CreateFile events resulting in "PATH NOT FOUND". This will show you when a DLL is searched for in a path where it does not exist.
It's important to note that certain DLLs, called Known DLLs can not be hijacked, as they are always loaded from the path set for said Known DLL (the path is listed in the registry). These DLLs include subsystem DLLs such as kernel32.dll, ntdll.dll, user32.dll, gdi32.dll, among others.
Another possibility is that a DLL is loaded from a fixed path. Some applications do this for certain (or all) DLLs. As an example I have observed some popular browsers such as Firefox to do this. If a DLL is loaded from a fixed path, it can not be hijacked in this way. To hijack a DLL loaded like this, you must overwrite it or modify environment variables.
DLL sideloading
This is the most common form of DLL hijacking. It is simple to do and doesn't require elevated privileges. The idea is to just copy an application into an user-writable location, along with the malicious DLL. The application could be copied from the target machine, or it could be packaged as part of the malware.
There's not much more to say about it, it's that simple. Regardless of simplicity, it is surprisingly challenging to detect, as it can look very similar to benign behavior, as it is common for applications to have custom DLLs placed in the same directory as the application. The act of copying the target application into a user-writable path could be used as a detection surface, or if the destination path is suspicious. However, well performed DLL sideloading produces more difficulties.
Environment variable-based hijacking
Another clever approach is to modify environment variables. There are many environment variables for paths such as Program Files, AppData, Windows directory, and specific ones like the path of OneDrive. If we modify these environment variables to point to a directory under our control, and create copy-cat DLLs there, we can make vulnerable programs load our arbitrary DLL.
There are many common programs which are vulnerable to environment variable -based hijacking, including classics like calc.exe.