MITRE ATT&CK T1055 Process Injection

Our research has found that Process Injection was the most prevalent MITRE ATT&CK technique used by adversaries in their malware. Adversaries emphasize an increased level of stealth, persistence, and privilege in their advanced cyber attacks. As a mechanism that can provide these features, it is not surprising that Process Injection is the most frequently used technique.

The purpose of this blog post is to review:

the fundamentals of the process injection technique,
the most used target processes for injection,
its use cases by threat actors, and
red, blue, and purple teaming exercises for this technique.

Introduction

It is easy to detect malware processes by listing the running processes and filtering out legitimate ones that are part of the operating system or installed software. If the malware can encapsulate its malicious code within a legitimate process, it will hide on the infected system. Process injection is in fact an “old but gold” technique consisting in running arbitrary code within the address space of another process. As a result, this technique enables access to the target process’s memory, system, and network resources.

On this account, the technique provides three significant benefits for adversaries:

Executing code under a legitimate process may evade security controls. The legitimate process camouflages the malicious code to evade detection since it is whitelisted.
Since the malicious code executed inside the legitimate process’s memory space, it may also evade disk forensics.
If the target process has elevated privileges, this technique will enable privilege escalation. For example, if the target process has access to network resources, the malicious code can communicate legitimately over the Internet and with other computers on the same network.

Processes Targeted by Adversaries for Process Injection

Security controls may quickly detect custom processes. Therefore, threat actors use common Windows processes such as:

Built-in native Windows processes including explorer.exe, svchost.exe, regsvr32.exe, dllhost.exe, services.exe, cvtres.exe, msbuild.exe, RegAsm.exe, RegSvcs.exe, rundll32.exe, arp.exe, PowerShell.exe, vbc.exe, csc.exe, AppLaunch.exe and cmd.exe
Processes of common software including iexplore.exe, ieuser.exe, opera.exe, chrome.exe, firefox.exe, outlook.exe, and msinm.exe

Target Process Selection Methods

Adversaries use the following methods when picking their target process for malicious code injection:

A specific target process is called out in the code. In this case, explorer.exe and svchost.exe are the most commonly used ones.
A list of target processes is defined in the code. For example, the Turla cyber espionage group’s Carbon backdoor includes a configuration file consisting of a list of target processes for injection[1]. A typical list includes native Windows and browser processes.
In some attack scenarios, the target process is not previously defined, and a suitable host process is located at runtime in this type of attack. For example, the CopyKittens group used Windows API functions to extract a list of currently active processes and to get a handle to each target process in its campaign[2].

Use Cases by Malware and Threat Actors

Example Process Injection Method: Reflective DLL Injection

Reflective DLL injection (loading) is one of the most used process injection methods employed by adversaries. This method allows injecting and executing a DLL inside another process by creating a DLL that maps itself into memory when executed, instead of relying on Window’s API’s loader calls. This technique avoids storing the DLL on disk and calling the Windows API’s LoadLibrary that might be detected by security tools.

Red Teaming - How to simulate?

Powersploit’s Invoke-ReflectivePEInjection [19] module can be used to simulate the reflective DLL injection technique. In addition to loading a DLL or EXE into the PowerShell, It can reflectively load a DLL into a remote process. Because of its capabilities, adversaries are also using this module for injection, such as the Turla APT Group [20].

The below command is a simulation of reflective DLL injection using the Invoke-ReflectivePEInjection module. With this command, contents of the calc.exe file are read into the $PEByte byte array using the ReadAllBytes [21] method. Then the byte array containing the calc.exe is loaded and executed locally using the -PEBytes parameter.

powershell -c "Unblock-File %TMP%\Invoke-ReflectivePEInjection.ps1;
Import-Module %TMP%\Invoke-ReflectivePEInjection.ps1;$PEBytes = [IO.File]::ReadAllBytes('%windir%\System32\calc.exe'); Invoke-ReflectivePEInjection -PEBytes $PEBytes"

Blue Teaming - How to detect?

Sigma Rule

To detect the reflective DLL injection technique, we need logs that include PowerShell activities. Event log entries in the Microsoft-Windows-PowerShell/Operational log includes such activities. The Event ID 4104 (script block logging) records accurate blocks of code as they are executed by the PowerShell engine. Script block logging captures the de-obfuscated full contents of the code as it is executed, including scripts and commands, as shown in the following figure.

When the DLL is injected into the target process, the malware has to map the DLL’s raw binary into virtual memory. It uses kernel32.dll and VirtualAlloc, GetProcAddress, and LoadLibraryA functions to get the correct address of the injected export function. Picus Labs’ Blue team developed the following Sigma rule by taking advantage of this finding mechanism and utilizing the Microsoft-Windows-PowerShell/Operational log with the Event ID 4104.

title:Reflective Portable Executable Injection via PowerShell status: stable   description: Detects the attempt of reflective portable executable (DLL/EXE) injection by PowerShell that uses API calls. This method is used by adversaries to evade detection from security products since the execution is masked under a legitimate process.
author: Picus Security
references:
     -https://attack.mitre.org/techniques/T1055/
     -https://attack.mitre.org/tactics/TA0004/
     -https://attack.mitre.org/tactics/TA0005/
logsource:
     product: windows
     service: powershell/operational
     definition1: 'Requirements: Group Policy : Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell\Turn On Module Logging'
     definition2: 'Requirements: Group Policy : Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell\Turn On PowerShell Script Block Logging'
detection:
     selection:
        EventID: 4104
    keyword1:
        - '*kernel32.dll*'
    keyword2:
        - '*LoadLibraryA*'
    keyword3:
        - '*GetProcAddress*'
    keyword4:
        - '*VirtualAlloc*'
    condition: All of them
falsepositives:
    - Unlikely, legitimate use in red teaming activities
level: high
tags:
    - attack.defense_evasion
    - attack.privilege_escalation
    - attack.t1055
    - attack.ta0004
    - attack.ta0005

Splunk SPL Query

(source="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode="4104" "*kernel32.dll*" "*LoadLibraryA*" "*GetProcAddress*" "*VirtualAlloc*")

IBM QRadar AQL Query

(LOGSOURCETYPENAME(devicetype)='Microsoft Windows Security Event Log' and EventID='4104' and UTF8(payload) ilike '%kernel32.dll%' and UTF8(payload) ilike '%LoadLibraryA%' and UTF8(payload) ilike '%GetProcAddress%' UTF8(payload) ilike '%VirtualAlloc%')

YARA Rule

The following YARA rule can be used to detect PowerShell scripts used for reflective DLL injection. This rule detects both Powersploit’s Invoke-ReflectivePEInjection module and Mimikatz’s PE Reflective Injection method [22].

rule power_pe_injection
{
meta:
description = "PowerShell with PE Reflective Injection"
author = "Benjamin DELPY (gentilkiwi)"

strings:
$str_loadlib = "0x53, 0x48, 0x89, 0xe3, 0x48, 0x83, 0xec, 0x20, 0x66, 0x83, 0xe4, 0xc0, 0x48, 0xb9"

condition:
$str_loadlib
}