Process Injection

Why do adversaries use Process Injection?

Note: Process Injection comprises multiple sub-techniques, but we largely map our detection analytics to the parent. As such, this section focuses generally on the overall technique and not on any individual sub-techniques.

Process Injection is a versatile technique that adversaries leverage to perform a wide range of malicious activity. It’s so versatile that ATT&CK includes 12 sub-techniques of Process Injection. Adversaries perform process injection because it allows them to execute malicious activity by proxy through processes that either have information of value (e.g., lsass.exe) or that blend in with benign operating system activity.

In addition to being stealthy, code can inherit the privilege level of the process it’s injected into and gain access to parts of the operating system that shouldn’t be otherwise available. Another added benefit of process injection is that it allows payloads to be launched within the memory space of a running process without needing to drop any malicious code to disk.

For example, you may be able to build a high-fidelity detection analytic that triggers any time PowerShell makes an external network connection. However, to avoid this method of detection, an adversary might inject their PowerShell process into a browser. In doing so, they’ve taken a potentially suspicious behavior—PowerShell making an external network connection—and replaced it with a seemingly normal behavior—a browser making an external network connection. What was detectable based on process lineage and network connections before process injection now relies on a mix of command-line parameters and binary metadata, to name a couple of telemetry sources.

How do adversaries use Process Injection?

With 12 sub-techniques, there’s no shortage of ways that an adversary can perform Process Injection. However, most of the injection behaviors we detect can be classified into just two categories:

• Evasion: Adversaries inject into a process that is functionally necessary and can’t be killed, that naturally makes high volumes of network connections or module loads, or that allows an adversary to perform an action that seems suspicious in the context of one process but benign in the context of another (e.g., making a network connection).
• Data theft: Adversaries inject into a process that gives them the ability to harvest sensitive information like credentials or otherwise abuse the capabilities of that process.

Across our data set, PowerShell is the most common culprit of process injection, and it injects into many processes to achieve many different goals. Some other process injectors include Microsoft Office applications, regsvr32.exe, rundll32.exe, lsass.exe, and spoolsv.exe.

Inversely, we detect adversaries injecting into a long list of processes, including the following:

• lsass.exe (credential theft)
• calc.exe (evasion)
• notepad.exe (evasion)
• svchost.exe (evasion and credential theft)
• backgroundtaskhost.exe (application control bypass)
• dllhost.exe (commonly used to host COM components, adversaries often inject into this process in order to blend in to a process that executes often and is expected to have a short lifetime)
• regsvr32.exe (application control bypass and other evasion)
• searchprotocolhost.exe (application control bypass and other evasion).
• werfault.exe (evasion)
• wuauclt.exe (evasion)
• spoolsv.exe (evasion)
• browser processes (normalizing network connections, info stealing/banking trojans)

The prevalence of process injection is buoyed in part by popular and widely available malware kits like Cobalt Strike, Metasploit, and other offensive tools that considerably lower the barrier of entry. What once existed mostly in the domain of more capable adversaries has since trickled down to nearly everyone else.

Associated threats

• Nitol botnet
• Qbot
• Cobalt Strike
• Mimikatz
• Dumpert

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Process access activity specifically offers visibility into cross-process events and process injection, but it’s false positive prone and there are many other data sources that you can combine to develop robust detection coverage. Most commercial EDR products and many other security tools will collect the following data sources.

Process monitoring

Process monitoring is a minimum requirement for reliably detecting process injection. Even though injection can be invisible to some forms of process monitoring, the effects of the injection become harder to miss once you compare process behaviors against expected functionality. The overwhelming majority of analytics we’ve developed to catch process injection look for at least one process, often a process executing without a corresponding command line.

Process access monitoring

Cross-process or process access events are an extremely rich source of visibility for process injection-related activity. However, this data source can also include a lot of noise, since there are many legitimate reasons for cross-process access.

Command monitoring

Monitoring for suspicious command-line parameters can be an effective way of observing and detecting potential process injection at scale. In some cases, specific command-line parameters may be an indicator of process injection. However, much of the time, it’s the absence of a command line in conjunction with certain processes that alerts us to process injection.

Network monitoring

Process injection-as-evasion sometimes includes a process that doesn’t usually make network connections (e.g., notepad.exe) injecting into a process that does (e.g., a browser). In these and other cases, network connection telemetry can be a great source for detection enrichment.

Module loads

Since process injection occasionally involves DLLs, collecting information on modules can also help enrich your detection data.

Most commercial EDR products and many other security tools will collect the following data sources, and honestly are needed to effectively attempt to leverage injection telemetry as a detection source at scale.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Sysmon Event ID 10: ProcessAccessed

Sysmon Event ID 10 tracks ProcessAccess or cross-process events, generating a log entry whenever one process opens another process. While malicious process injection necessarily involves one process accessing another, there are many legitimate reasons for process access as well. Therefore, this event ID will likely generate a lot of noise without filtering out known benign cross-process behavior.

Windows Event Event ID 4663: LSASS Access

Introduced in Windows 10, when a handle to lsass.exe is granted, Windows will natively log a 4633 event to the Security log. Kernel object auditing must be enabled in order to surface these events.

Windows Security Event ID 4688: Process Creation

Process Creation (4688) events with command-line argument logging enabled is a great source of telemetry for process starts and commands lines—or, as is often the case with process injection, a lack thereof.

Sysmon Event ID 1: Process creation

Sysmon process creation events are another rich source of telemetry for detecting process injection. Like Windows Security Event ID 4688, process creation events track process starts and corresponding command lines.

LSASS System Access Control List (SACL) auditing

Added in Windows 10, LSASS SACL auditing records all processes that attempt to access lsass.exe, a common target of process injection.

Endpoint Detection and Response (EDR) tools

Many EDR tools will gather telemetry from different sources—like those mentioned above and more—that can be cobbled together in search of malicious process injection.

Weeding out false positives

The analytics that produced the most false positives in our dataset came from looking for CreateRemoteThread calls. Many tools in Windows use process injection legitimately for debugging and virtualization. If you want to write analytics around this API call, focus them on unusual source processes, such as Microsoft Office products and tools that commonly deliver first-stage malware like scripts and Mshta.

Further, processes like lsass.exe and svchost.exe are both common targets for process injection and common processes in general. As such, baselining normal against abnormal will be an important step in fighting false positives:

• In some environments, you might be able to detect reliably on specific processes injecting into lsass.exe. However, you might achieve better detection outcomes by correlating cross processes with executing processes, including LOLBINs like MSbuild, PowerShell, Wscript, Cscript, Msiexec, Rundll32, and more.
• Additionally, adversaries often attempt to use svchost.exe for process injection. Due to the large volume, taking the approach of identifying known processes that may execute code can help reduce the amount of noise generated.