Summary
This module is centered on understanding various process injection techniques. Additionally, participants will gain hands-on experience using WinDbg and other tools to analyze process injection techniques and monitor WinAPI functions.
This module is broken down into sections with accompanying hands-on exercises to practice each of the techniques covered. The module ends with a practical hands-on skills assessment to gauge your understanding of the various topic areas. In this module, we will cover:
-
Process Injection Techniques -
Internals and Key Structures -
ETW Threat-Intelligence (ETW-TI) -
Self Injection (Local Process Injection) -
Remote Dynamic-link Library Injection -
Thread Execution Hijacking -
APC Injection -
Early Bird APC Queue Injection -
TLS Callback Injection -
Debugging TLS Callback -
Section View Mapping -
PE Injection -
Process Hollowing -
Reflective Code injection -
Deep dive into LoadLibrary -
RDLL Injection -
Skills Assessment
Participants will gain insight into each technique and its implementation, along with the detection opportunities. This module also contains some real-world examples to illustrate how process injection attacks are conducted and detected. There will also be practical exercises to understand and implement various injection techniques.
You can start and stop the module at any time and pick up where you left off. There is no time limit or "grading," but you must complete all of the exercises and the skills assessment to receive the maximum number of cubes and have this module marked as complete in any paths you have chosen.
The module is classified as "Hard" because there is a certain requirement for working knowledge of using debuggers, analysis tools, an understanding of the Windows command line, and basic system programming. Knowledge of the following will help to understand this module:
- Basic understanding of C programming and structures
- General understanding of the Win32 API and Navtive API
- An idea of how processes & threads work on Windows
- Basic understanding of the Portable Executable (PE) format and its components
Additionally, a firm grasp of the following modules can be considered a prerequisites for successful completion of this module:
- Completion of
Introduction to Malware Analysis - Completion of
Intro to Assembly Language -
Introduction to Windows Command Line
Windows Process Injection Attacks
Process injection is a technique malware uses to run its code within the address space of another process, making it harder to detect and analyze. The idea behind process injection is to stealthily introduce malicious code into the address space of a legitimate process, thereby avoiding detection by security mechanisms that monitor for the creation of new processes or the loading of suspicious executables. This makes it possible for malware to eliminate the involvement of executable files on the disk, and it is often called fileless malware.
The definition of the process injection tactic in MITRE ATT&CK framework is as follows:
Stages of process injection
Typically, a process injection involves a few stages, i.e., target selection, memory allocation, payload injection, and code execution, as shown in the diagram below:
-
Target Selection and Access: The attacker identifies a suitable target process or creates a new one. -
Memory Allocation: Memory space within the target process needs to be allocated to hold the malicious code (payload). -
Payload Injection: The attacker writes the malicious code (payload) into the allocated memory space within the target process. This could be shellcode or a PE/DLL as well. -
Code Execution: The final stage involves triggering the execution of the injected code. This can be achieved through various techniques that we'll cover in this module.
Common Target processes
The malware utilizing the process injection technique operates in memory without leaving any traces of a malicious executable file on disk, making it harder to detect using traditional antivirus and endpoint security solutions. Malware often targets legitimate processes that are commonly found running on systems. The process injection technique in the MITRE framework (T1055) lists many examples of different target processes used by malware to inject malicious code.
Some of the legitimate processes targeted by malware for process injection attacks are as follows:
| Process Name | Description |
|---|---|
lsass.exe |
Used for credential theft because it stores credentials used for interactive logons and contains the Local Security Authority (LSA) subsystem. |
svchost.exe |
Used for evasion and credential theft, svchost.exe is a generic host process name for services that run from dynamic-link libraries (DLLs), allowing injected code to blend in with legitimate Windows services. |
backgroundtaskhost.exe |
A Windows Background Task Host process that runs background tasks. |
dllhost.exe |
Used to host COM components, making it a common target for injection to blend in with legitimate COM processes that are expected to have a short lifetime. |
regsvr32.exe |
Regsvr32.exe is a legitimate Windows program used to register and unregister Object Linking and Embedding (OLE) controls, allowing injected code to blend in with legitimate usage. |
rundll32.exe |
Used to load and run 32-bit dynamic-link libraries. |
searchprotocolhost.exe |
A Windows process that handles the indexing of files for Windows Search, providing an opportunity for injected code to blend in. |
werfault.exe |
Used for evasion and is known to connect to the internet, as it is the Windows Error Reporting process, making injected code less likely to be detected. |
wuauclt.exe |
The Windows Automatic Update Client process. |
spoolsv.exe |
Windows Print Spooler service process. |
Browser processes |
Commonly used for normalizing network connections and information-stealing/banking trojans, as browsers often have high network activity and access to sensitive information. |
Why is process injection done?
The main reasons attackers use the process injection technique to run malicious code are described below:
-
Avoid Static Detection: The malicious payload should not be present on the disk. When an analyst or threat hunter looks at the alerts and logs and notices the path of an initial access script or executable, they won't be able to locate the dropped file. YARA rules or signature-based detection rules can easily flag this activity. In many scenarios, malware deletes the source file from the disk and injects itself into another running process alongside some solid persistence. -
Injected malicious code runs in a trusted process: These processes are targeted because they and their file paths are typically trusted by some security software and whitelisted by detection rules, making them ideal for hiding malicious activities. Since these processes are commonly found running on Windows systems, malicious activity injected into these processes can appear as legitimate system activity, making it harder for security software to detect. For instance, if a SOC Analyst or threat hunter is going through the logs and finds a process running from an unusual location with a custom name, it would look suspicious. Running the malicious code inside a trusted process lets the suspicious events blend in with legitimate activity. -
Inherit Privileges from target process: By injecting code into a process, the injected code can also inherit the privileges of that process. This technique allows the injected code to bypass security restrictions and access parts of the operating system or perform actions that would not be possible under normal circumstances. -
Execute Additional Functionality without Dropping Executables: Attackers often need to execute additional tools or functionalities without leaving many artifacts on disk. By injecting code directly into a process, they can avoid dropping new executables. For example, an attacker may want to run a tool like Mimikatz for credential dumping but avoid placing the Mimikatz binary on disk. By injecting Mimikatz code into an already running process, they achieve their goal without creating new files that could be detected.