Misbehaving Modalities: Detecting Tools, Not Techniques

Misbehaving Modalities: Detecting Tools, Not Techniques
Jared Atkinson introduced the concept of Execution Modality to better understand and detect malware techniques by focusing on how malicious behaviors are executed rather than just what they do. This approach emphasizes detection as close to the operating system’s source of truth as possible, improving visibility and robustness in threat detection. #ExecutionModality #ElasticSecurity

Keypoints

  • Execution Modality describes the method by which malicious behavior is executed, such as system utilities, scripts, or direct syscalls, rather than the behavior itself.
  • Traditional detection based on high-level telemetry like PowerShell or process creation logs is brittle and covers only a few modalities, often missing many attack vectors.
  • Elastic focuses on kernel-level telemetry, especially configuration manager callbacks and call stacks, to detect malicious service creation and other behaviors close to the OS source of truth.
  • Call stacks reveal execution modalities across runtimes (PowerShell, .NET, RPC, WMI, VBA, Python, Java), allowing distinction between benign and anomalous behavior based on modality.
  • A modality-focused detection approach can identify suspicious API calls from specific modalities, enhancing detection of defense evasion techniques like AMSI patching and ntdll unhooking.
  • Summiting the Pyramid (STP) scores show that kernel ETW-based PowerShell modality detection is significantly more robust (score 5K) compared to traditional PowerShell scriptblock-based detection (score 2A).
  • Despite possible call stack spoofing by malware, combining kernel-collected call stacks with hardware execution tracing and baseline profiling improves detection accuracy and resilience.

MITRE Techniques

  • [T1050] Service Execution – Various modalities such as sc.exe, PowerShell scripts, or direct syscalls modify service configuration, demonstrating different execution paths (‘…installer calls sc.exe create… direct Service Control RPC calls… indirect syscalls to update registry…’).
  • [T1086] PowerShell – PowerShell modality is extended with enhanced logging and detection capabilities, but detection coverage limited to PowerShell misses other modalities (‘…important not to conflate having detection coverage of a technique in PowerShell with coverage of that technique in general.’).
  • [T1218] Signed Binary Proxy Execution – Use of legitimate system utilities like sc.exe or PowerShell to execute malicious service creation behaviors (‘…system utility such as sc.exe…’).
  • [T1036.005] Masquerading: Match Legitimate Name or Location – Attackers use PowerShell or .NET runtimes, blending malicious behavior within trusted runtime modules as revealed by call stacks (‘…runtimes for PowerShell, .NET… leave traces in the call stack.’).
  • [T1090] Proxy Execution – Use of PowerShell scripts that employ suspicious API calls (e.g. VirtualProtect) to evade detection (‘…rule for “Suspicious API Call from a PowerShell Script” was quite effective…’).

Indicators of Compromise

  • [File Names] PowerShell scripts and modules – examples include ‘Get-WinlogonTokenSystem.ps1’ script loaded from GitHub and PowerShell modules like ‘Microsoft.PowerShell.Utility.psd1’ and ‘Microsoft.PowerShell.Utility.psm1’ involved in suspicious behavior.
  • [API Calls] Suspicious API usage – VirtualProtect( kernel32.dll!FatalExit ), WriteProcessMemory, and VirtualAlloc detected during modality-focused analysis as indicators of malicious execution phases.
  • [Process Names] Malicious parent or child process context – powershell.exe, pwsh.exe, powershell_ise.exe observed executing suspicious activities with high integrity levels and unsigned call stacks.


Read more: https://www.elastic.co/security-labs/misbehaving-modalities

Views: 26