Windows Privilege Escalation via DLL Hijacking

Windows Privilege Escalation DLL Hijacking

Sharing is caring!


This Blog Post is focused on providing a crystal-clear view on one of the most used techniques for privilege escalation by the Threat Actors. DLL Hijacking also known as DLL Search Order Hijacking is a technique that leverages the issue of improper DLL loading by the application. Threat Actor uses this technique to achieve privilege escalation and also high-level persistence on the attack surface.

But first, let’s understand the mechanism of DLL loading by any application.

DLL  stands for Dynamic Link Library which is a library file that contains the code and data that can be accessed and used dynamically by more than one application at the same time. DLL was introduced by Microsoft for implementing the concept of shared library which promotes code reuse and efficient memory usage.

In the following example, application 1 and application 2   tries to import (dynamically) the required functions to run the application from the system.dll.

Explanation of DLL Search Order:

In order to import any functionality from the DLL, the application needs to define the particular path from which the dll can be successfully loaded. In case the application doesn’t have a defined path to load the Dll, system follows a search order which can be utilized to search the DLL. The paths defined in the Search Order are the paths in which the system searches and if found loads the DLL. But before the system searches for the DLL by the search order, it checks the following:

  • If a DLL with same module name is already loaded in memory, the system uses the loaded DLL.
  • If the DLL is on the list of known DLLs for the version of Windows on which application is running, the system uses its copy of the known DLL.

Now if the system doesn’t find the DLL with the same module name already loaded in memory and DLL on the list of known DLLs the system will follow the search order.

DLL Search Order:

The Dynamic-Link Library Search Order is as follows:

  • The directory from which the application loaded.
  • The system directory. (C:\Windows\System32\)
  • The 16-bit System Directory. (C:\Windows\System\)
  • The Windows directory. (C:\Windows\)
  • The current directory.
  • The directories that are listed in the PATH environment variable.

The Following Diagram explains the searching order of dll:

Addressing the Issue:

If the application follows the Dynamic-Link Library Search Order to load the DLL and if the custom-made malicious DLL by the attacker with the same module name is placed in one of the paths of the search order, the malicious DLL will be executed instead of the legitimate DLL.

Below Diagram explains the issue which causes the DLL Hijacking.


In this Blog post, we will take the example of an open-source free antivirus which was suspected to be vulnerable to DLL Hijacking. It is also one of the applications which were part of the CIA’s project Fine Dining which was revealed by WikiLeaks. These applications were also called as malware-laced spy apps.

ClamWin Portable was suspected to be vulnerable to DLL Hijacking. The link to the disclosure can be found here.

All the applications which were part of the fine dining tool can be found here.

Lab Setup:

Operating SystemOS VersionIPv4 Address
Windows 7Windows 7 Professional 32 Bit192.168.152.146
KaliKali 2018.2192.168.152.128


In order to look for the possible DLL Hijacking Vulnerability, we will use Procmon a tool from Windows Sysinternals Suite. Windows Sysinternals Suite can be found here.

To display the desired results of all the DLL that are attempted to be loaded from the paths where the DLL doesn’t exist we need to apply some filters.

The Filters are as follows:

  • Process Name is ClamWinPortable.exe
  • Process Name is ClamWin.exe
  • Path ends with DLL
  • Result is Name Not Found

The first two filters will display only the activities related to the process name ClamWinPortable and ClamWin.

The third filter will display the path that ends with DLL .

The last filter will display the DLL that was attempted to be loaded from the path were DLL was not found.

The Desired Output will be:

In the above output, there are a number of DLLs that can be hijacked but respecting the limitation of this blog we will try to hijack only the highlighted DLL i.e. Version.dll.

Introduction to DLL Proxying:

In order to maintain the functionality of the application and also hijacking the DLL improperly loaded by the application we will use the concept of DLL Proxying. In this concept the custom-made malicious DLL forwards all the legitimate functions that exported by the legitimate DLL by using pre-processor directives (pragma also known as pragmatic). In a nutshell, custom-made malicious DLL calls all the functions from the legitimate original DLL which are required to maintain the functionality.

To find the functions that are exported by the legitimate DLL we will use dumpbin. Dumpbin is Microsoft COFF Binary File Dumper that displays information about Common Object File Format (COFF) binary files.

 dumpbin.exe /EXPORTS C:\Windows\System32\version.dll


The output is shown in the image below.


We will use a PowerShell script Get-Exports from the Powershell Suite maintained by FuzzySecurity.  This PowerShell script will get us the list of all exported functions in the legitimate DLL . The script also provides the functionality of exporting the functions to a C++ pragma-based parser. The Script can be found here.


Import-Module .\Get-Exports.ps1
Get-Exports -DllPath C:\Windows\System32\version.dll -ExportsToCpp version.txt


Output file version.txt will look something like the below image:

We will replace the “[FORWARD_DLL_HERE]” with the legitimate DLL which is “C:\\Windows\\System32\\version.dll” and also replace the single-quotes with double-quotes.

Now we will make our malicious DLL , for which we will need to copy the output from the PowerShell script to a C++ file in Visual Studio. In this scenario, I am using Visual Studio 12 community version.

Firstly, we will create a Win32 C++ based project.

Next, we will select which kind of application file we want to get in our output and what common header files should be added.

Code can be found here.

Before we build the dll we need to set the important options:

LoadLibraryA(); will load our malicious dll which we have made using Metasploit.

Now we just need to place our custom-made version.dll and poc.dll in the Directory C:\Users\User\Desktop\ClamWinPortable\.

We just need to open the application and our version.dll will be loaded to perform the operation. On the Attacker’s side, we will get a meterpreter based reverse-shell.

Note: The application should run with administrative privilege.

The below figure explains the Final Working of the exploit.

Mitigations :

  • Absolute paths should be defined by the developer while building the application to load the Dynamic Link Library.
  • Auditing tools should be used which capable of detecting this vulnerability.

References :


Written by : Satyam Dubey



You may also like...

1 Response

  1. Avatar Cybernyze says:


    This article on Windows privilege escalation is a great read, thanks for putting it together. In fact, I find your thoughts on DLL proxying very interesting.

    I’m happy I found another amazing cyber security blogger.

    More grease to your elbow… 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *