Code Injection &

Hooking
Virtual Memory
• Address Space Expansion
• Memory Isolation
• Page File for Efficiency
Virtual Memory
• Virtual memory is segregated into process memory (process space or user space) and
kernel memory (kernel space or system space). The size of the virtual memory address
space depends on the hardware platform. For example, on a 32-bit architecture, by
default, the total virtual address space (for both process and kernel memory) is a
maximum of 4 GB. The lower half (lower 2 GB), ranging from 0x00000000 through
0x7FFFFFFF, is reserved for user processes (process memory or user space), and the
upper half of the address (upper 2 GB), ranging from 0x80000000 through 0xFFFFFFFF,
is reserved for kernel memory (kernel space).
Process Memory Components (User Space)
Process Memory Components (User
Space)
Process Memory Components (User
Space)
Kernel Memory Contents (Kernel Space)
Kernel Memory Contents (Kernel Space)
User Mode And Kernel Mode
1.User and Kernel Space Distinction:
• Virtual memory is divided into user-space and kernel space.
User-space contains user-mode code, while kernel space
houses the operating system's kernel and device drivers. This
separation ensures restricted access for user-mode
applications, preventing direct interaction with hardware.
2.Execution Modes:
• User mode and kernel mode represent different privilege
levels. User mode restricts access, while kernel mode allows
high-privileged execution. Kernel components, like
ntoskrnl.exe, can interact with both user and kernel space.
Third-party drivers, when signed, can execute in kernel mode.
User Mode And Kernel Mode

3.API Calls and System Service Routines:

• User-mode applications make API calls, which often lead to the
execution of system service routines in the kernel executive
(ntoskrnl.exe). This intermediary step ensures controlled access
to hardware resources. For instance, WriteFile API, when invoked,
eventually interacts with the kernel to perform disk writes.
4.Gateway Functions in User-Space:
• Key dynamic-link libraries (DLLs) like ntdll.dll and user32.dll act
as gateways between user-space and kernel-space functionalities.
These libraries facilitate the transition of API calls, enabling
communication with the kernel. Understanding this process is
crucial for analyzing malware attempting to interact with the
system.
User Mode And Kernel Mode
Windows API Call Flow
Code Injection Techniques
Code Injection Techniques
1. Process Enumeration for Target Identification:
• Malware uses API calls like CreateToolhelp32Snapshot(),
Process32First(), and Process32Next() to enumerate running
processes on the system. This helps identify the target process
for code injection by gathering information such as executable
name, process ID, and parent process ID.
2. Code Injection Strategies:
• Malicious processes employ various code injection techniques,
injecting either DLLs, executables, or Shellcode into the
address space of a legitimate process. The objective is to force
the legitimate process to execute the injected code. This can
occur either in an already running process or by launching a
new process.
Code Injection Techniques
3. Flexible Code Storage:
• Depending on the chosen code injection technique, the
malicious component to be injected may reside either
on the disk or in the memory. Malware authors employ
different strategies to achieve their goal, adapting to
the specific requirements of the attack. Understanding
these techniques is crucial for effective threat detection
and mitigation.
Code Injection Techniques
Remote DLL Injection
• In this technique, the target (remote) process is forced to load a malicious DLL into its
process memory space via the LoadLibrary() API. The kernel32.dll exports
LoadLibrary(), and this function takes a single argument, which is the path to the DLL
on the disk, and loads that DLL into the address space of the calling process. In this
injection technique, the malware process creates a thread in the target process, and
the thread is made to call LoadLibrary() by passing a malicious DLL path as the
argument. Since the thread gets created in the target process, the target process loads
the malicious DLL into its address space. Once the target process loads the malicious
DLL, the operating system automatically calls the DLL's DllMain() function, thus
executing the malicious code.
• For detail steps read section 3.1
DLL Injection Using APC (APC Injection)

• The APC injection technique is similar to remote DLL injection, but instead of using
CreateRemoteThread(), a malware makes use of Asynchronous Procedure Calls (APCs)
to force the thread of a target process to load the malicious DLL.
• An APC is a function that executes asynchronously in the context of a particular thread.
Each thread contains a queue of APCs that will be executed when the target thread
enters an alertable state. As per Microsoft documentation (read online), a thread
enters an alertable state if it calls one of the following functions:
SleepEx(),
SignalObjectAndWait()
MsgWaitForMultipleObjectsEx()
WaitForMultipleObjectsEx()
WaitForSingleObjectEx()
• For detail steps read section 3.2
DLL Injection Using SetWindowsHookEx()
• 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.
• For detail steps read section 3.3
DLL Injection Using The Application Compatibility

Shim
• The Microsoft Windows application compatibility infrastructure/framework (application
shim) is a feature that allows programs created for older versions of the operating
system (such as Windows XP) to work with modern versions of the operating system
(such as Windows 7 or Windows 10). This is achieved through application compatibility
fixes (shims). The shims are provided by Microsoft to the developers so that they can
apply fixes to their programs without rewriting the code. When a shim is applied to a
program, and when the shimmed program is executed, the shim engine redirects the
API call made by the shimmed program to shim code; this is done by replacing the
pointer in the IAT with the address of the shim code.
• In other words, it hooks the Windows API to redirect calls to the shim code instead of
calling the API directly in the DLL. As a result of API redirection, the shim code can
modify the parameters passed to the API, redirect the API, or modify the response from
the Windows operating system.
• For detail steps read section 3.3
DLL Injection Using The Application Compatibility

Shim
Creating A Shim
Creating a shim for an application can be broken down into four
steps:
• Choosing the application to shim.
• Creating the shim database for the application.
• Saving the database (.sdb file).
• Installing the database.
How Attackers Use Shims
• The following table outlines some of the interesting shims and their descriptions:
Remote Executable/Shellcode Injection

• In this technique, the malicious code is injected into the target process memory
directly, without dropping the component on the disk. The malicious code can be a
shellcode or an executable whose import address table is configured for the target
process. The injected malicious code is forced to execute by creating a remote thread
via CreateRemoteThread(), and the start of the thread is made to point to the
code/function within the injected block of code. The advantage of this method is that
the malware process does not have to drop the malicious DLL on the disk; it can extract
the code to inject from the resource section of the binary, or get it over the network
and perform code injection directly.
• For detail steps read section 3.5
Hollow Process Injection (Process Hollowing)

• Process hollowing, or Hollow Process Injection, is a code injection technique in which

the executable section of the legitimate process in the memory, is replaced with a
malicious executable. This technique allows an attacker to disguise his malware as a
legitimate process and execute malicious code. The advantage of this technique is that
the path of the process being hollowed out will still point to the legitimate path, and, by
executing within the context of a legitimate process, the malware can bypass firewalls
and host intrusion prevention systems.
• For detail steps read section 3.6
Hollow Process Injection Steps
Hooking Techniques

By hooking an API, an attacker can control the execution path of

the program and re route it to the malicious code of his choice. The
malicious function can then:
• Block calls made to the API by legitimate applications (such as
security products).
• Monitor and intercept input parameters passed to the API.
• Filter the output parameters returned from the API
IAT Hooking
Inline Hooking (Inline Patching)
In-memory Patching Using Shim
• In inline hooking, we saw how the series of bytes in a function are patched to redirect
control to malicious code. It is possible to perform in-memory patching using the
application compatibility shim (the details of the shim were covered previously).
Microsoft uses the feature of in-memory patching to apply patches to fix vulnerabilities
in their products. Inmemory patching is an undocumented feature, and is not available
in the Compatibility Administrator Tool (covered earlier), but security researchers,
through reverse engineering, have figured out the functionality of in-memory patches,
and have developed tools to analyze them. The sdb-explorer by Jon Erickson
(https:/​/​github.​com/​evil-​e/​sdbexplorer) and python-sdb by William Ballenthin
(https:/​/​github.​com/ williballenthin/​python-​sdb) allow you to inspect in-
memory patching by parsing the shim database (.sdb) files.