Relative path DLL hijacking in Windows programs

As part of a Red Team assessment, a challenge arose to execute our own code via a DLL. The reason for this scenario was the use of Application Allow Listing software, which blocks the execution of unknown executables. The usual options for loading DLLs, such as rundll32, were heavily monitored by the customer's blue team, so we had to look for other options.

After some trial and error in our labs and analyzing the behavior of certain Windows programs at runtime, it turned out that in a recent Windows 11 (as of March 2025), some of Microsoft's own programs had a vulnerability - namely Relative Path DLL Hijacking.

With a little twist, this vulnerability allows attackers to run (malicious) code through trusted applications although security mechanism like application allow listing or monitoring might be in place.

This problem was reported to Microsoft on 21.02.2025 and categorized as "not a security vulnerability" on 07.03.2025. Nevertheless, we are happy to show you in this blog post how you, as a Red Teamer, can use Microsoft programs to load DLLs.

What is Relative Path DLL Hijacking?

Relative Path DLL Hijacking is a vulnerability that occurs when an application does not load a required DLL using a fixed path but instead uses the standard Windows search order (see graphic below). With this order, an attacker can place a DLL with the searched name in a manipulated directory that the attacker can write to. When the application starts, it loads the DLL and runs the code it contains with the rights of the affected program. 

The following figure illustrates the search order for DLLs on Windows. Note that some search paths can be manipulated not only by administrators, but also by normal users.

Affected Windows Components

Some components from the system directory C:\Windows\System32 are vulnerable to the described attack if a little trick is used. The secret lies in the DLL search order, specifically in the "Application Path" entry.  To exploit the behavior, an affected component (e.g. calc.exe) is copied from the System32 folder to another folder that can be written to by the attacker:

copy C:\Windows\System32\calc.exe C:\Users\Public\

The Process Monitor tool can now be used to analyze the start of the process in detail. Filtering the events helps to show only the important information:

• Paths ending with .dll should be included in the output
• Results of events where a file is not found should be included in the output
• All processes that are not calc.exe should be removed from the output

As you can see, calc.exe tries to load different DLLs from the folder in which it was executed.

For example, an adversary could create a DLL named Windows.Storage.dll and place it in the same directory where calc.exe is run. When calc.exe is started, the hijacked DLL would be loaded and the code it contains would be run. 

The following sample code opens a message box that says "Hijacked DLL ..." when the DLL is loaded:

If calc.exe is now started and finds the DLL in the same folder, it is loaded and the message box is opened:

Why is this behavior still a problem?

In this particular case, the affected programs must be placed in a folder together with the malicious DLL and run. This means that the attacker must have taken initial control of the system or otherwise distributed one of the legitimate programs along with its DLL. To the attacker's advantage, the affected applications are digitally signed by Microsoft and are therefore considered trustworthy. This can lead to other security mechanisms being bypassed. Some solutions, such as antivirus software, EDR, and allow listing tools, may initially analyze only the loading process. 

This vulnerability therefore offers attackers an alternative to the so-called LOLBAS (Living Off The Land Binaries and Scripts). These are native Windows programs and scripts that are usually misused by attackers for hidden actions. Since LOLBAS are usually intensively monitored by security solutions and have a higher risk of detection, relative path DLL hijacking in Windows programs opens up additional opportunities for attackers.

Timeline of Responsible Disclosure

Links to further information

• https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
• https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
• https://lolbas-project.github.io/