DLL Hijacking is a way for attackers to execute unexpected code on your machine. This means that if an attacker can get a file on your machine (by social engineering, remote control, etc.) that file could be executed when the user runs an application that is vulnerable to DLL Hijacking. To understand how it works, you must first understand two important concepts:
- What is a DLL
- What is the PATH variable in Windows
What is a DLL?
Here is how Microsoft defines a DLL:
“For the Microsoft Windows operating systems[…], much of the functionality of the operating system is provided by dynamic link libraries (DLL). Additionally, when you run a program on one of these Windows operating systems, much of the functionality of the program may be provided by DLLs. For example, some programs may contain many different modules, and each module of the program is contained and distributed in DLLs.”
For the purpose of understanding DLL Hijacking, all we need to know is that a DLL contains executable code and that most applications rely on DLLs that are already installed on your computer. This is important so that programmers don’t have to “reinvent the wheel” each time they want to do something. For example, each internet browser on your machine doesn’t have to include instructions on how to lookup domain names. Instead, they can just use Windows DLLs that already know how to do that. Here is an example of Firefox loading Windows DLLs when it starts:
What is the PATH variable in Windows?
The next important thing to understand is the PATH variable in Windows. When you try to execute a command, the PATH variable tells Windows where to start looking for the command if it not found in the current directory. Every Windows machine should have a PATH variable. Look at the following example of trying to run a python program:
What happened? I told the machine to run a program named “python” but Windows couldn’t find Python.exe in the current directory. Let’s add Python to the PATH variable so windows knows where to look for “python.exe”:
It worked, because even though we are in “somerandomdirectory”, Windows now knows to look for executables such as “python.exe” in the folder “C:\Python27”.
So what? Who cares? How is that exploitable?
Applications in Windows can search for DLLs in the same way we searched for “python.exe” above. If applications designers don’t consider this when designing applications, then the app could be vulnerable to DLL Hijacking. Attackers care about DLL Hijacking. If an application is vulnerable to DLL Hijacking, attackers can put malicious DLLs in the PATH or other location that is searched by the application and have them executed by the application. This comes in handy for privilege escalation and for persistence. For example, let’s say a service runs as SYSTEM, and you only have a user with very limited privileges. By observing that the service searches for the DLL in a number of locations, and one of those happens to be writable by the user, a malicious DLL placed in that location would exploit DLL Hijacking to provide you with SYSTEM privileges.
For privilege escalation, an attacker would find a high-privileged application vulnerable to hijacking. By placing a malicious DLL in the PATH, that code would be executed with the same privileges as the vulnerable application. Or imagine if a tool that only administrators use were vulnerable. The attacker could gain administrative privileges through DLL Hijacking.
Similarly, attackers could leave malicious DLLs on a system that are executed by applications or users. This could ensure an attacker has a persistent way back into the system later.
How to test for DLL Hijacking
Most often, the Sysinternal’s Process Monitor utility (Procmon) is used to test for DLL hijacking. It is simple to run Procmon to observe processes and files requested. With Procmon listening, any requests for DLLs can be observed. Multiple “Not Found” requests that crawl over the PATH locations are easy to single out.
For example, let’s look at that Firefox process list. Firefox IS NOT vulnerable to DLL Hijacking, but below is highlighted the type of request that would indicate it is vulnerable. If the “Not Found” errors were indicated in every folder listed in the PATH, then this would indicate the application is vulnerable.
Generally the best way to check a service for DLL Hijacking is to setup procmon to filter on exes and dlls, where the result is “NAME NOT FOUND”.
Powershell Empire and Metasploit also have some nice tools to search system-wide for DLL Hijacking for the purpose of Privilege Escalation, but that’s a blog post for another time.
Once you have found a vulnerable location, you can create a proof-of-concept dll using msfvenom.msfvenom -f dll -p windows/exec CMD="C:\windows\system32\calc.exe" -o runcalc.dll
I hope this helps provide a basic understanding of how DLL Hijacking works. Happy Hacking!