DLL hijacking attacks revisited

This article is all about different DLL hijacking attacks techniques used by malware to achieve persistence. We will be discussing DLL search order hijacking, DLL Side loading, and Phantom DLL Hijacking techniques. Also, we will see how can we detect it and prevent the DLL hijacking attack.

What is DLL hijacking?

DLL provide common code that can be used by executables statically or dynamically. Such codes are stored in different files and are invoked or loaded into RAM only when the related code is required. Thus, it saves an application size and to prevent resource hogging by the application. DLL hijacking is the technique in which instead of benign DLL usually loaded by the application, the loader is tricked to load a malicious DLL. DLL hijacking has different techniques which slightly vary from each other. They are mainly classified under:

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

DLL search order hijacking

Windows OS search for DLL's needed by executable in a specific order. Thus if the executable is not looking for some 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 path

Search Path is well documented by Microsoft and defaults to:

1. The directory from which the application is loaded
2. The current directory
3. The system directory, usually C:WindowsSystem32 (The GetSystemDirectory function is called to obtain this directory.)
4. The 16-bit system directory - There is no dedicated function to retrieve the path of this directory, but it is searched as well.
5. The Windows directory. The GetWindowsDirectory function is called to obtain this directory.
6. The directories that are listed in the PATH environment variable

As we can see above, anyone who can write to the current directory can potentially introduce rogue DLL, and since the order of loading DLL's from current directory is high, then it will be loaded by the executable as a first match.

What are known DLLs?

When a loader comes across import DLL section of an executable, the first thing the loader will do is to check out for KnownDLL directory which contains known systems DLLs. If the DLL mentioned in the import name matches with KnownDLL, then this DLL will be mapped to process address space.

KnownDLL are specified in the registry key

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs

And their location is mentioned by the key DllDirectory (64 bit DLLs) and DllDirectory32 (32 bit DLLs)

Attackers can also modify the registry key at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager ExcludeFromKnownDlls to exclude the DLLS from KnownDLL for processing.

DLL side-loading attack

WinSxS feature is used by many applications to prevent problems that can arise due to updated and duplicated version of DLLs. DLL side-loading attack makes use of WinSxS directory. This is located in C:WindowsWinSxS and holds multiple versions of DLLs. When an application uses this directory to retrieve DLL, then it needs to have a manifest. Manifest lists the DLL that can be used at run time by this application and is used by loaded to determine which version of DLL to use.

Now this technique/folder has less validation other than what is specified in the metadata itself and thus a spoofed DLL can be placed in this directory and loaded. A well-documented attack of DLL side-loading by FireEye can be seen here.

Phantom DLL hijacking

This attack uses some very old DLLs that are still attempted to be loaded by applications even when they are completely unnecessary. All attackers have to do is to give the malicious DLL name in the Search Path and the new malicious code will be executed. An example of this is to replace fxsst.dll(Fax Service)DLl in Systems 32 folder with a malicious counterpart.

Detection of DLL hijacking

Look out for DLLs with the same name in multiple locations in search order. There is a tool here which can be used to detect possible DLL hijacking. It is available for both 32 bit and 64 bit. It runs in verbose mode by default means it will give the output as wherever there are DLLs in multiple locations in the search order both signed and unsigned. To filter, use the /unsigned switch with this tool which will show only unsigned DLLs. Below is an example of this tool running. There will be false positives from this tool so assure that complete context of loaded DLL is checked.

Prevention from DLL hijacking

Enable SafeDllSearchMode so that exploiting the search path becomes more difficult for the attacker. Hwne SafeDllSearchMode has enabled the search path order changes to follow.

• The directory from which the application loaded.
• The system directory. GetSystemDirectory function can be used to get the path of this directory.
• The 16-bit system directory.
• The Windows directory. GetWindowsDirectory function can be used to get the path of this directory.
• The current directory.
• The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

As we can see above Current Directory is shifted from 2^nd to 5^th position in the order of search path.

Other than this developer should write secure code o order to load directories from specified path only. Also, make sure that only signed DLLs are loaded for most systems process and applications.

Sources

https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/rpt-dll-sideloading.pdf

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

https://github.com/adamkramer/dll_hijack_detect/releases