The resource section in the Windows PE file format is used by the executable

and is not considered part of the executable. Examples of the normal contents
of the resource section include icons, images, menus, and strings. Launchers
will often store malware within the resource section. When the launcher is
run, it extracts an embedded executable or DLL from the resource section
before launching it.
As you have seen in previous examples, if the resource section is com-
pressed or encrypted, the malware must perform resource section extrac-
tion before loading. This often means that you will see the launcher use
resource-manipulation API functions such as FindResource, LoadResource,
and SizeofResource.
Malware launchers often must be run with administrator privileges or
escalate themselves to have those privileges. Average user processes can’t
perform all of the techniques we discuss in this chapter. We discussed privi-
lege escalation in the previous chapter. The fact that launchers may con-
tain privilege-escalation code provides another way to identify them.

Process Injection
The most popular covert launching technique is process injection. As the name
implies, this technique injects code into another running process, and that
process unwittingly executes the malicious code. Malware authors use pro-
cess injection in an attempt to conceal the malicious behavior of their code,
and sometimes they use this to try to bypass host-based firewalls and other
process-specific security mechanisms.
Certain Windows API calls are commonly used for process injection.
For example, the VirtualAllocEx function can be used to allocate space in an
external process’s memory, and WriteProcessMemory can be used to write data
to that allocated space. This pair of functions is essential to the first three
loading techniques that we’ll discuss in this chapter.

DLL Injection
DLL injection—a form of process injection where a remote process is forced
to load a malicious DLL—is the most commonly used covert loading tech-
nique. DLL injection works by injecting code into a remote process that calls
LoadLibrary, thereby forcing a DLL to be loaded in the context of that pro-
cess. Once the compromised process loads the malicious DLL, the OS auto-
matically calls the DLL’s DllMain function, which is defined by the author of
the DLL. This function contains the malicious code and has as much access
to the system as the process in which it is running. Malicious DLLs often have
little content other than the Dllmain function, and everything they do will
appear to originate from the compromised process.
Figure 12-1 shows an example of DLL injection. In this example, the
launcher malware injects its DLL into Internet Explorer’s memory, thereby
giving the injected DLL the same access to the Internet as Internet Explorer.
The loader malware had been unable to access the Internet prior to injection
because a process-specific firewall detected it and blocked it.

254 Chapter 12
 Hard Drive Memory

Launcher Launcher Blocked

Malicious DLL
Injection
Internet

iexplore.exe
iexplore.exe
Malicious DLL

Figure 12-1: DLL injection—the launcher malware cannot access the Internet until it
injects into iexplore.exe.

In order to inject the malicious DLL into a host program, the launcher
malware must first obtain a handle to the victim process. The most common
way is to use the Windows API calls CreateToolhelp32Snapshot, Process32First,
and Process32Next to search the process list for the injection target. Once the
target is found, the launcher retrieves the process identifier (PID) of the tar-
get process and then uses it to obtain the handle via a call to OpenProcess.
The function CreateRemoteThread is commonly used for DLL injection to
allow the launcher malware to create and execute a new thread in a remote
process. When CreateRemoteThread is used, it is passed three important param-
eters: the process handle (hProcess) obtained with OpenProcess, along with the
starting point of the injected thread (lpStartAddress) and an argument for
that thread (lpParameter). For example, the starting point might be set to
LoadLibrary and the malicious DLL name passed as the argument. This will
trigger LoadLibrary to be run in the victim process with a parameter of the
malicious DLL, thereby causing that DLL to be loaded in the victim process
(assuming that LoadLibrary is available in the victim process’s memory space
and that the malicious library name string exists within that same space).
Malware authors generally use VirtualAllocEx to create space for the mali-
cious library name string. The VirtualAllocEx function allocates space in a
remote process if a handle to that process is provided.
The last setup function required before CreateRemoteThread can be called
is WriteProcessMemory. This function writes the malicious library name string
into the memory space that was allocated with VirtualAllocEx.
Listing 12-1 contains C pseudocode for performing DLL injection.

hVictimProcess = OpenProcess(PROCESS_ALL_ACCESS, 0, victimProcessID );

pNameInVictimProcess = VirtualAllocEx(hVictimProcess,...,sizeof(maliciousLibraryName),...,...);
WriteProcessMemory(hVictimProcess,...,maliciousLibraryName, sizeof(maliciousLibraryName),...);
GetModuleHandle("Kernel32.dll");
GetProcAddress(...,"LoadLibraryA");
 CreateRemoteThread(hVictimProcess,...,...,LoadLibraryAddress,pNameInVictimProcess,...,...);

Listing 12-1: C Pseudocode for DLL injection

C ov e rt M a l w a r e L a u n c h ing 255
 This listing assumes that we obtain the victim PID in victimProcessID
when it is passed to OpenProcess at  in order to get the handle to the victim
process. Using the handle, VirtualAllocEx and WriteProcessMemory then allocate
space and write the name of the malicious DLL into the victim process. Next,
GetProcAddress is used to get the address to LoadLibrary.
Finally, at , CreateRemoteThread is passed the three important parameters
discussed earlier: the handle to the victim process, the address of LoadLibrary,
and a pointer to the malicious DLL name in the victim process. The easiest
way to identify DLL injection is by identifying this trademark pattern of Win-
dows API calls when looking at the launcher malware’s disassembly.
In DLL injection, the malware launcher never calls a malicious function.
As stated earlier, the malicious code is located in DllMain, which is automati-
cally called by the OS when the DLL is loaded into memory. The DLL injec-
tion launcher’s goal is to call CreateRemoteThread in order to create the remote
thread LoadLibrary, with the parameter of the malicious DLL being injected.
Figure 12-2 shows DLL injection code as seen through a debugger. The
six function calls from our pseudocode in Listing 12-1 can be seen in the dis-
assembly, labeled  through .





Figure 12-2: DLL injection debugger view

Once you find DLL injection activity in disassembly, you should start
looking for the strings containing the names of the malicious DLL and the
victim process. In the case of Figure 12-2, we don’t see those strings, but they
must be accessed before this code executes. The victim process name can
often be found in a strncmp function (or equivalent) when the launcher

256 Chapter 12
 determines the victim process’s PID. To find the malicious DLL name, we
could set a breakpoint at 0x407735 and dump the contents of the stack to
reveal the value of Buffer as it is being passed to WriteProcessMemory.
Once you’re able to recognize the DLL injection code pattern and iden-
tify these important strings, you should be able to quickly analyze an entire
group of malware launchers.

Direct Injection
Like DLL injection, direct injection involves allocating and inserting code
into the memory space of a remote process. Direct injection uses many of
the same Windows API calls as DLL injection. The difference is that instead
of writing a separate DLL and forcing the remote process to load it, direct-
injection malware injects the malicious code directly into the remote process.
Direct injection is more flexible than DLL injection, but it requires a lot
of customized code in order to run successfully without negatively impacting
the host process. This technique can be used to inject compiled code, but
more often, it’s used to inject shellcode.
Three functions are commonly found in cases of direct injection:
VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. There will typi-
cally be two calls to VirtualAllocEx and WriteProcessMemory. The first will allo-
cate and write the data used by the remote thread, and the second will
allocate and write the remote thread code. The call to CreateRemoteThread
will contain the location of the remote thread code (lpStartAddress) and
the data (lpParameter).
Since the data and functions used by the remote thread must exist in the
victim process, normal compilation procedures will not work. For example,
strings are not in the normal .data section, and LoadLibrary/GetProcAddress
will need to be called to access functions that are not already loaded. There
are other restrictions, which we won’t go into here. Basically, direct injection
requires that authors either be skilled assembly language coders or that they
will inject only relatively simple shellcode.
In order to analyze the remote thread’s code, you may need to debug
the malware and dump all memory buffers that occur before calls to
WriteProcessMemory to be analyzed in a disassembler. Since these buffers
most often contain shellcode, you will need shellcode analysis skills, which
we discuss extensively in Chapter 19.

Process Replacement
Rather than inject code into a host program, some malware uses a method
known as process replacement to overwrite the memory space of a running pro-
cess with a malicious executable. Process replacement is used when a mal-
ware author wants to disguise malware as a legitimate process, without the
risk of crashing a process through the use of process injection.
This technique provides the malware with the same privileges as the
process it is replacing. For example, if a piece of malware were to perform
a process-replacement attack on svchost.exe, the user would see a process

C ov e rt M a l w a r e L a u n c h ing 257