DLL hijacking attacks revisited 2023
This article is about DLL hijacking attacks revisited.
This article is all about the various DLL hijacking attack techniques used by malware to achieve persistence. We will discuss DLL search order hijacking, DLL-side loading, and DLL phantom hijacking techniques. We will also see how we can detect it and prevent a DLL hijacking attack.
What is DLL Hijacking attacks ?
A DLL provides common code that executables can use statically or dynamically. Such codes are stored in different files and are recalled or loaded into RAM only when the associated code is required. This saves the size of the application and prevents application resources from being overwhelmed. DLL hijacking is a technique where instead of the harmless DLL normally loaded by the application, the loader is tricked into loading a malicious DLL. DLL hijacking has various techniques that are slightly different from each other. They are mainly classified under:
DLL search order hijacking
Windows looks for the DLLs needed for the executable in a certain order. So if the executable doesn’t look for a DLL via some hard-coded path, then a malicious DLL can be placed in the search order and the executable will load it. But what is this search path?
Search for a way
The search path is well documented by Microsoft and the default value is:
The directory from which the application is loaded
Current directory
The system directory, usually C:WindowsSystem32 (The GetSystemDirectory function is called to get this directory.)
16-bit system directory – There is no dedicated function to get the path to this directory, but it is also searched.
Windows directory. The GetWindowsDirectory function is called to get this directory.
Directories that are listed in the PATH environment variable
As we can see above, anyone who can write to the current directory can potentially load a rogue DLL, and since the load order of DLLs from the current directory is high, the executable will load it as the first match.
What are the known DLLs?
When the loader encounters the DLL import section of an executable file, the first thing the loader does is look for the KnownDLL directory, which contains known system DLLs. If the DLL specified in the import name matches a KnownDLL, that DLL will be mapped to the process’s address space.
KnownDLLs are listed in the registry key
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs
And their location is mentioned by key DllDirectory (64bit DLL) and DllDirectory32 (32bit DLL)
Attackers can also modify the registry key in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager ExcludeFromKnownDlls to exclude DLLS from KnownDLLs for processing.
DLL side-loading attack
The WinSxS feature is used by many applications to prevent problems that may occur due to an updated and duplicate DLL version. A DLL side-loading attack exploits the WinSxS directory. It is located in C:WindowsWinSxS and contains several versions of the DLLs. When an application uses this directory to load a DLL, then it must have a manifest. The manifest lists the DLL that this application can use at runtime, and which the loader uses to determine which version of the DLL to use.
Now this technique/folder has less validation than what is stated in the metadata itself, so a fake DLL can be placed and loaded in this directory. You can see a well-documented sideloading DLL attack by FireEye here.
Phantom DLL hijacking
This attack uses some very old DLLs that applications still try to load even though they are completely useless. All attackers have to do is type the malicious DLL name into the search path and the new malicious code will be executed. An example is replacing fxsst.dll(Fax Service)DLl in the Systems 32 folder with a malicious counterpart.
Also read:Everything you need to know about Ethical Hacking as a Career by Blackhat Pakistan 2023
DLL Hijack Detection
Look for DLLs with the same name in multiple places in the search order. There is a tool here that can be used to detect possible DLL abuse. It is available for both 32-bit and 64-bit versions. By default it runs in verbose mode, which means it will give output like wherever the DLLs are in multiple places in the search order, both signed and unsigned. To filter, use the /unsigned switch on this tool to display only unsigned DLLs. Below is an example of running this tool. This tool will throw false positives, so make sure the full context of the loaded DLL is checked.
DLL Hijack Prevention
Enable SafeDllSearchMode to make it more difficult for an attacker to abuse the search path. Hwne SafeDllSearchMode enabled search path order changes to be controlled.- The directory from which the application was loaded.
System directory. The GetSystemDirectory function can be used to obtain the path to this directory.
16-bit system directory. - Windows directory. The GetWindowsDirectory function can be used to obtain the path to this directory.
Current directory
Directories that are listed in the PATH environment variable. Note that this does not include the per-app path specified by the App Paths registry key. The App Paths key is not used when calculating the DLL search path.
As we can see above, Current Directory is moved from 2nd to 5th position in search path order.
A developer other than this should write secure code or a command to load directories only from the specified path. Also, make sure that only signed DLLs are loaded for most system processes and applications.
Sources
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
