| Name |
Inclusion of Code in Existing Process |
|
| Likelyhood of attack |
Typical severity |
| Low |
High |
|
| Summary |
The adversary takes advantage of a bug in an application failing to verify the integrity of the running process to execute arbitrary code in the address space of a separate live process. The adversary could use running code in the context of another process to try to access process's memory, system/network resources, etc. The goal of this attack is to evade detection defenses and escalate privileges by masking the malicious code under an existing legitimate process. Examples of approaches include but not limited to: dynamic-link library (DLL) injection, portable executable injection, thread execution hijacking, ptrace system calls, VDSO hijacking, function hooking, reflective code loading, and more. |
| Prerequisites |
The targeted application fails to verify the integrity of the running process that allows an adversary to execute arbitrary code. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Determine target process] The adversary determines a process with sufficient privileges that they wish to include code into. |
- On Windows, use the process explorer's security tab to see if a process is running with administror privileges.
- On Linux, use the ps command to view running processes and pipe the output to a search for a particular user, or the root user.
|
| 2 |
Experiment |
[Attempt to include simple code with known output] The adversary attempts to include very simple code into the existing process to determine if the code inclusion worked. The code will differ based on the approach used to include code into an existing process. |
|
| 3 |
Exploit |
[Include arbitrary code into existing process] Once an adversary has determined that including code into the existing process is possible, they will include code for a targeted purpose, such as accessing that process's memory. |
|
|
| Solutions | Prevent unknown or malicious software from loading through using an allowlist policy. Properly restrict the location of the software being used. Leverage security kernel modules providing advanced access control and process restrictions like SELinux. Monitor API calls like CreateRemoteThread, SuspendThread/SetThreadContext/ResumeThread, QueueUserAPC, and similar for Windows. Monitor API calls like ptrace system call, use of LD_PRELOAD environment variable, dlfcn dynamic linking API calls, and similar for Linux. Monitor API calls like SetWindowsHookEx and SetWinEventHook which install hook procedures for Windows. Monitor processes and command-line arguments for unknown behavior related to code injection. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-114 |
Process Control |
| CWE-829 |
Inclusion of Functionality from Untrusted Control Sphere |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-251 |
The attacker forces an application to load arbitrary code files from the local machine. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways. |
|
| Taxonomy: ATTACK |
|
Entry ID
|
Entry Name
|
| 1505.005 |
Server Software Component: Terminal Services DLL |
| 1574.006 |
Hijack Execution Flow: Dynamic Linker Hijacking |
| 1574.013 |
Hijack Execution Flow: KernelCallbackTable |
| 1620 |
Reflective Code Loading |
|