In the previous chapter (refer to Section 1.3.2, Keylogger Using SetWindowsHookEx), we looked at how malware uses the SetWindowsHookEx() API to install a hook procedure to monitor keyboard events. The SetWindowsHookEx() API can also be used to load a DLL into a target process address space and execute malicious code. To do that, a malware first loads the malicious DLL into its own address space. It then installs a hook procedure (a function exported by the malicious DLL) for a particular event (such as a keyboard or mouse event), and it associates the event with the thread of the target process (or all of the threads in the current desktop). The idea is that when a particular event is triggered, for which the hook is installed, the thread of the target process will invoke the hook procedure. To invoke a hook procedure defined in the DLL, it must load the DLL (containing the hook procedure) into the address space of the target process.

In other words, an attacker creates a DLL containing an export function. The export function containing the malicious code is set as the hook procedure for a particular event. The hook procedure is associated with a thread of the target process, and when the event is triggered, the attacker's DLL is loaded into the address space of the target process, and the hook procedure is invoked by the target process's thread, thereby executing malicious code. The malware can set the hook for any type of event, as long as that event is likely to occur. The point here is that the DLL is loaded into the address space of the target process, and performs malicious actions.

The following describes the steps used by the malware sample (Trojan Padador) to load its DLL into the address space of the remote process and to execute the malicious code:

1. The malware executable drops a DLL named tckdll.dll on the disk. The DLL contains an entrypoint function, and an export function named TRAINER, shown as follows. The DLL entry point function does not do much, whereas the TRAINER function contains the malicious code. This means that whenever a DLL is loaded (its entry point function is invoked), no malicious code is executed; only when the TRAINER function is invoked are the malicious actions performed:

2. Malware loads the DLL (tckdll.dll) into its own address space using the LoadLibrary() API, but no malicious code is executed at this point. The return value of LoadLibrary() is the handle to the loaded module (tckdll.dll). It then determines the address of the TRAINER function by using GetProcAddress():

3. The malware uses the handle to the tckdll.dll and the address of the TRAINER function to register a hook procedure for the keyboard event. In the following screenshot, the 1^st argument, WH_KEYBOARD (constant value 2), specifies the type of event that will invoke the hook routine. The 2^nd argument is the address of the hook routine, which is the address of the TRAINER function determined in the previous step. The 3^rd argument is the handle to the tckdll.dll, which contains the hook procedure. The fourth argument, 0, specifies that the hook procedure must be associated with all of the threads in the current desktop. Instead of associating the hook procedure with all of the desktop threads, a malware may choose to target a specific thread by providing its thread ID:

After performing the preceding steps, when the keyboard event is triggered within an application, that application will load the malicious DLL and invoke the TRAINER function. For instance, when you launch Notepad and enter some characters (which triggers a keyboard event), tckdll.dll will be loaded into Notepad's address space, and the TRAINER function will be invoked, forcing the notepad.exe process to execute malicious code.