This micro emulation plan targets compound behaviors related to T1620 Reflective Code Loading. Malware commonly abuses reflective loading to execute malicious code within an otherwise seemingly benign host process. There are many variations of reflectively loading code (this emulation focuses on a few very common variants) that highlight potentially broader defensive lessons learned.
You can access the binary for this micro plan as part of the latest release.
Table Of Contents:
What are we doing? This module provides easy-to-execute code that reflectively loads a shellcode payload (using either Windows API or .NET functions) into the running host process. The shellcode executes a series of local discovery commands via PowerShell:
whoami /groupsqwinstatasklistGet-WmiObject Win32_productnetstat -ano
Why should you care? T1620 Reflective Code Loading is very commonly abused by malware to evade defenses, specifically to execute malicious code within an otherwise benign process. Other techniques, such as T1055 Process Injection and T1574 Hijack Execution Flow, achieve a similar effect but create external detectable artifacts. Adversaries and malware authors may instead opt to use reflective code loading techniques to attempt to contain generated artifacts within the memory of their host process.
Organic system features, such as the Windows .NET Common Language Runtime (CLR), may be loaded into a process to run arbitrary code from private process memory. Malware, such as Cobalt Strike's execute-assembly function in Beacon, abuse this functionality to execute malicious code in-memory without writing payloads to disk.
This module has been compiled into an easy to execute/integrate executable. Source code is available if you wish to customize and/or rebuild the tool (e.g., changing the shellcode payload). You can also download the pre-compiled module.
The reflective_loading.exe tool executes the complete emulation functionality. The tool accepts the following arguments on the command-line, or can be executed with defaults via a double-click:
-dor--dinvoke: execute using MemoryMappedFile & Marshal .NET functions (DEFAULT)-kor--kernel: execute usingVirtualAlloc()andCreateThread()-hor--help: display the help menu
A lot of the related detection telemetry may be low-level since reflective code loading happens within a malicious host process. Monitoring module loads (especially related to .NET and other execution runtimes) into abnormal processes (such as unmanaged, not .NET-based programs) may highlight attempts to execute functions associated with modifying process memory.
Image source: Bring Your Own Land (BYOL) – A Novel Red Teaming Technique
Monitoring API calls of functions commonly abused for reflective code loading could highlight malicious activity, but may also be prone to high noise and false positive rates if not correlated with other signals.
Usage of reflective code loading may be difficult if not impossible to mitigate since the signals are low-level and potentially also associated with legitimate system activity. Efforts can be focused on blocking known, detectable patterns of abuse.