new memory for the malware, and uses WriteProcessMemory to write each of
the malware sections to the victim process space, typically in a loop, as
shown at .
In the final step, the malware restores the victim process environment so
that the malicious code can run by calling SetThreadContext to set the entry
point to point to the malicious code. Finally, ResumeThread is called to initiate
the malware, which has now replaced the victim process.
Process replacement is an effective way for malware to appear non-
malicious. By masquerading as the victim process, the malware is able to bypass
firewalls or intrusion prevention systems (IPSs) and avoid detection by appear-
ing to be a normal Windows process. Also, by using the original binary’s path,
the malware deceives the savvy user who, when viewing a process listing, sees
only the known and valid binary executing, with no idea that it was unmapped.
Hook Injection
Hook injection describes a way to load malware that takes advantage of Win-
dows hooks, which are used to intercept messages destined for applications.
Malware authors can use hook injection to accomplish two things:
To be sure that malicious code will run whenever a particular message is
intercepted
To be sure that a particular DLL will be loaded in a victim process’s
memory space
As shown in Figure 12-3, users generate events that are sent to the OS,
which then sends messages created by those events to threads registered to
receive them. The right side of the figure shows one way that an attacker can
insert a malicious DLL to intercept messages.
USER USER
Events Events
Windows OS Windows OS
Messages Messages
Threads Malicious DLL
Process/ Threads
Application
Process/
Application
Figure 12-3: Event and message flow in Windows
with and without hook injection
C ov e rt M a l w a r e L a u n c h ing 259
Local and Remote Hooks
There are two types of Windows hooks:
Local hooks are used to observe or manipulate messages destined for an
internal process.
Remote hooks are used to observe or manipulate messages destined for a
remote process (another process on the system).
Remote hooks are available in two forms: high and low level. High-level
remote hooks require that the hook procedure be an exported function con-
tained in a DLL, which will be mapped by the OS into the process space of a
hooked thread or all threads. Low-level remote hooks require that the hook
procedure be contained in the process that installed the hook. This proce-
dure is notified before the OS gets a chance to process the event.
Keyloggers Using Hooks
Hook injection is frequently used in malicious applications known as
keyloggers, which record keystrokes. Keystrokes can be captured by register-
ing high- or low-level hooks using the WH_KEYBOARD or WH_KEYBOARD_LL hook
procedure types, respectively.
For WH_KEYBOARD procedures, the hook will often be running in the con-
text of a remote process, but it can also run in the process that installed the
hook. For WH_KEYBOARD_LL procedures, the events are sent directly to the pro-
cess that installed the hook, so the hook will be running in the context of the
process that created it. Using either hook type, a keylogger can intercept key-
strokes and log them to a file or alter them before passing them along to the
process or system.
Using SetWindowsHookEx
The principal function call used to perform remote Windows hooking is
SetWindowsHookEx, which has the following parameters:
idHook Specifies the type of hook procedure to install.
lpfn Points to the hook procedure.
hMod For high-level hooks, identifies the handle to the DLL containing
the hook procedure defined by lpfn. For low-level hooks, this identifies the
local module in which the lpfn procedure is defined.
dwThreadId Specifies the identifier of the thread with which the hook
procedure is to be associated. If this parameter is zero, the hook proce-
dure is associated with all existing threads running in the same desktop
as the calling thread. This must be set to zero for low-level hooks.
The hook procedure can contain code to process messages as they come
in from the system, or it can do nothing. Either way, the hook procedure
must call CallNextHookEx, which ensures that the next hook procedure in the
call chain gets the message and that the system continues to run properly.
260 Chapter 12
Thread Targeting
When targeting a specific dwThreadId, malware generally includes instructions
for determining which system thread identifier to use, or it is designed to
load into all threads. That said, malware will load into all threads only if it’s a
keylogger or the equivalent (when the goal is message interception). How-
ever, loading into all threads can degrade the running system and may trig-
ger an IPS. Therefore, if the goal is to simply load a DLL in a remote process,
only a single thread will be injected in order to remain stealthy.
Targeting a single thread requires a search of the process listing for the
target process and can require that the malware run a program if the target
process is not already running. If a malicious application hooks a Windows
message that is used frequently, it’s more likely to trigger an IPS, so malware
will often set a hook with a message that is not often used, such as WH_CBT (a
computer-based training message).
Listing 12-4 shows the assembly code for performing hook injection in
order to load a DLL in a different process’s memory space.
00401100 push esi
00401101 push edi
00401102 push offset LibFileName ; "hook.dll"
00401107 call LoadLibraryA
0040110D mov esi, eax
0040110F push offset ProcName ; "MalwareProc"
00401114 push esi ; hModule
00401115 call GetProcAddress
0040111B mov edi, eax
0040111D call GetNotepadThreadId
00401122 push eax ; dwThreadId
00401123 push esi ; hmod
00401124 push edi ; lpfn
00401125 push WH_CBT ; idHook
00401127 call SetWindowsHookExA
Listing 12-4: Hook injection, assembly code
In Listing 12-4, the malicious DLL (hook.dll) is loaded by the malware,
and the malicious hook procedure address is obtained. The hook procedure,
MalwareProc, calls only CallNextHookEx. SetWindowsHookEx is then called for a thread
in notepad.exe (assuming that notepad.exe is running). GetNotepadThreadId is a
locally defined function that obtains a dwThreadId for notepad.exe. Finally, a
WH_CBT message is sent to the injected notepad.exe in order to force hook.dll to
be loaded by notepad.exe. This allows hook.dll to run in the notepad.exe process
space.
Once hook.dll is injected, it can execute the full malicious code stored in
DllMain, while disguised as the notepad.exe process. Since MalwareProc calls only
CallNextHookEx, it should not interfere with incoming messages, but malware
often immediately calls LoadLibrary and UnhookWindowsHookEx in DllMain to ensure
that incoming messages are not impacted.
C ov e rt M a l w a r e L a u n c h ing 261
