I am playing around with dll-hijacking and was wondering about something that I haven't been able to find out myself by googling. I get how the basics work with the fact that DLL's are loaded by an executeable/service/installer. I also understand how windows goes through the loading "path" to find the DLL's. So I can get my DLL's to execute calculator when I put my DLL in the path of the program itself when I know for sure it tries to find the DLL's in the path of the program.

But here is my question: How can I find out if a DLL is loaded by an executeable using a relative path?

What I want is to be able to execute that "not found" DLL from a directory in the PATH variable, so if I am just misunderstanding that, that would be possible please tell me as well.


I see that my question isn't a 100% clear by the comments/answers I am getting. So I will clarify a bit: I am just playing around so I have a testlab setup. What the question really is about is if there is any way to see if the DLL's that are loaded by an executable are loaded with a relative path and not by a absolute path. SO if the executable tries to just find test.dll or if it is refering to c:\windows\system32\test.dll. I am using procmon to see what DLL's are loaded by several applications (like Discord). In procmon I cannot see how the executable tries to find the DLL (relative or absolute path) and that is what I want to find out, how to see if the executable goes trough the different paths as described in this Link or if the executable is only trieing to load the absolute path of a dll.

  • Could you not create a DLL that has the different path options and see what each method does under your test conditions? Maybe writing it out to a log file at each step?
    May 29, 2017 at 12:53
  • I am not sure Windows will give the relative path for program using load successfully under relative path, you need to find documentation about windows OS execution namespace. OTH, tThe usual tricks to travel up to root path in windows is use tons of "..\" to travel up to the system folder. e.g. "..\..\..\..\..\..\..\windows\system32\calc.exe"
    – mootmoot
    May 29, 2017 at 13:21

2 Answers 2


Who knows what is happening in your case. Its hard to guess. Try Process monitor. It will monitor all requests to kernel, including DLL loads. There you should be able to find what you are actually looking for.


It's a pretty old threat but the following might help you. Just take the .exe in question and move it to a user writable directory. If you then notice that it tries to load a DLL from the application directory you have a prove that the DLL is loaded not specifying absolute paths, because if that’s the case, the Windows OS has a pre-defined search order for such situation to ultimately be able to load the needed DLL. As an example. I’ve copied the WinSAT.exe from C:\Windows\System32 to C:\test. If I then execute WinSAT.exe from C:\test with Process Monitor running I can clearly see that it tries to load the dxgi.dll from the C:\test directory:

enter image description here If you don’t already know that, folders that are created at the root of a partition are granted permissive rights. And that’s the case with our C:\test directory. Now guess what. YES! You can place a evil DLL under C:\test, name it dxgi.dll and load your DLL with some evil badness. PS. Here’s a nice visualization of the actual search order:

enter image description here

  • 1
    Thanks for the extra explanation!
    – Wealot
    Jun 24, 2020 at 6:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .