Technique T1055

Process Injection

After leading the 2020 Threat Detection Report, Process Injection fell to number six in the 2021 report, which is exactly where it ranks among the most prevalent ATT&CK techniques in this year’s report.

Pairs with this song

#6

Overall rank

21.7%

Percent of customers affected

1235

Total threat volume
 

Analysis Icon

Analysis

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 14 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 14 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)
  • 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.

Visibility icon

Visibility

 

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.

Collection Icon

Collection

 

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.

Icon-threat detection

Detection

We have more than 80 detection analytics that seek out various forms of process injection. By and large, these analytics look for legitimate processes doing unexpected things like making external network connections, writing files, or spawning with unexpected command-line arguments—including no command-line arguments at all.

PowerShell injecting into… anything

There’s some exceptions here—surely varying from one environment to the next—but, generally speaking, you’ll want to be wary of process access activity where PowerShell is accessing any other processes.

process == powershell.exe
&&
handle_granted_to [any other process]

Process executing sans command lines

One major tell for process injection is the absence of command lines. Detecting the absence of anything, including a command line, can be tricky, and this pseudo-analytic only works for processes where you expect corresponding commands. However, you may be able to iterate on the following amalgamation of detection logic to improve detection coverage. Hint: adding a network connection or child process execution to these may help you home in on malice.

process == ('backgroundtaskhost.exe' || 'svchost.exe' || 'dllhost.exe' || 'werfault.exe' || 'searchprotocolhost.exe' || 'wuauclt.exe' || 'spoolsv.exe' || 'rundll32.exe' || 'regasm.exe' || 'regsvr32.exe' || 'regsvcs.exe')
&&
Command_line == (“”)*

*Empty quotes (i.e., “”) signify a blank command line.

Network connections where there shouldn’t be

Detecting purely on processes making network connections has the potential to generate a torrent of false positives. However, it can also identify suspicious injection activity—particularly if you tune the logic to filter out the eccentricities in your specific environment.

Process == notepad.exe 
&&
has_network_connection

Injection into LSASS

Since injection into lsass.exe is common, impactful, and frequently suspicious, it deserves to be called out individually. To that point, it would be worth your time to determine and enumerate the processes in your environment that routinely or occasionally obtain a handle to lsass.exe. Any access outside of the baseline should be treated as suspicious. The following analytic offers a good starting place with a pattern of behavior that is very commonly malicious:

process == rundll32.exe
&&
cross_process_handle_into ('lsass.exe')

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.

Testing Icon

Testing

Start testing your defenses against Process Injection using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View atomic tests for T1055: Process Injection. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using an elevated PowerShell prompt:
mavinject.exe ((Get-Process lsass).Id) /INJECTRUNNING C:\Windows\System32\vbscript.dll

What to expect

mavinject.exe will inject vbscript.dll into the running lsass.exe process using Dynamic-link Library Injection. We chose to use mavinject.exe as an example for its simplicity.

Useful telemetry will include:
VisibilityTelemetryCollection
Visibility :

Process monitoring

Telemetry:

A mavinject.exe process will start.

Collection:

EDR, Sysmon Events ID 1 and 10, and Windows Event IDs 4688 and 4633 should collect relevant telemetry.

Visibility :

Command monitoring

Telemetry:

Command-line logging will capture the context of what is executed.

Collection:

EDR, Sysmon Event ID 1, and Windows Event ID 4688 should collect relevant telemetry.

Visibility :

Module monitoring

Telemetry:

vbscript.dll will load in the lsass.exe process.

Collection:

EDR and Sysmon Event ID 7 should collect relevant telemetry.

A more detailed test

The mavinject.exe test above offers defenders a really simple way to test their ability to observe and detect process injection. The following, however, is a more in-depth test that will inject and execute benign shellcode into a notepad.exe process. This test replicates T1055.002: Portable Executable Injection. Copy it into a PowerShell prompt.

 # Start a notepad process. This will be our injection target
$NotepadProcess = Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{ CommandLine = 'notepad.exe' }
 
# Compile and load Windows API functions that will be needed to inject into another process
Add-Type -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
 
namespace Win32 {
	public class NativeMethods {
        [DllImport("kernel32.dll", SetLastError = true)] public static extern IntPtr OpenProcess(int processAccess, bool bInheritHandle, int processId);
        [DllImport("kernel32.dll", SetLastError = true)] public static extern IntPtr VirtualAllocEx(IntPtr hProcess, IntPtr lpAddress, uint dwSize, int flAllocationType, int flProtect);
        [DllImport("kernel32.dll", SetLastError = true)] public static extern bool WriteProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, uint nSize, ref uint lpNumberOfBytesWritten);
        [DllImport("kernel32.dll", SetLastError = true)] public static extern bool CloseHandle(IntPtr hObject);
        [DllImport("ntdll.dll")] public static extern int RtlCreateUserThread(IntPtr ProcessHandle, IntPtr SecurityDescriptor, bool CreateSuspended, IntPtr StackZeroBits, IntPtr StackReserved, IntPtr StackCommit, IntPtr StartAddress, IntPtr StartParameter, ref IntPtr ThreadHandle, ref IntPtr ClientID);
	}
}
'@
 
# Benign shellcode to inject into notepad - 0x90 (NOP), 0x90 (NOP), 0x90 (NOP), 0xC3 (RET)
[Byte[]] $Code = @(0x90, 0x90, 0x90, 0xC3)
 
# Obtain a handle to the open notepad process
$TargetProcessHandle = [Win32.NativeMethods]::OpenProcess(0x001FFFFF, $False, $NotepadProcess.ProcessId)
 
# Allocate read/write/execute memory in the notepad process for the shellcode
$TargetProcessBaseAddress = [Win32.NativeMethods]::VirtualAllocEx($TargetProcessHandle, [IntPtr]::Zero, $Code.Length, 0x3000, 0x40)
 
# Write the shellcode buffer to the notepad process​
$BytesWritten = 0
$null = [Win32.NativeMethods]::WriteProcessMemory($TargetProcessHandle, $TargetProcessBaseAddress, $Code, $Code.Length, [Ref] $BytesWritten)
 
# Execute the shellcode in the notepad process
[IntPtr] $RemoteThreadHandle = [IntPtr]::Zero
[IntPtr] $CliendId = [IntPtr]::Zero
$null = [Win32.NativeMethods]::RtlCreateUserThread($TargetProcessHandle, [IntPtr]::Zero, $False, [IntPtr]::Zero, [IntPtr]::Zero, [IntPtr]::Zero, $TargetProcessBaseAddress, [IntPtr]::Zero, [Ref] $RemoteThreadHandle, [Ref] $CliendId)
 
# Cleanup
$null = [Win32.NativeMethods]::CloseHandle($RemoteThreadHandle)
$null = [Win32.NativeMethods]::CloseHandle($TargetProcessHandle)
Stop-Process -Id $NotepadProcess.ProcessId 

What to expect

powershell.exe will inject shellcode into notepad.exe and have notepad.exe execute the shellcode.

Useful telemetry will include:
VisibilityTelemetryCollection
Visibility:

Process monitoring

Telemetry:

powershell.exe will inject code into notepad.exe

Collection:

EDR, Sysmon Event IDs 1 and 10, and Windows Event ID 4688 relevant telemetry.

Visibility:

Command monitoring

Telemetry:

Command-line logging will capture the context of what is executed.

Collection:

EDR, Sysmon Event ID 1, Windows Event IDs 4688, 4104, 4103, and 800, and AMSI should collect relevant telemetry.

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented?
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.