Abusing Windows Management Instrumentation (WMI)

### Overview In this presentation, Matthew Graeber explores how Windows Management Instrumentation (WMI) can be abused by attackers to establish persistent, asynchronous, and fileless backdoors. Having existed since Windows 98 and Windows NT 4.0, WMI is a deeply embedded administrative technology that provides attackers with extensive post-exploitation, reconnaissance, lateral movement, and command-and-control (C2) capabilities without dropping executable binaries to disk.

### Key Topics - **Living off the Land:** Leveraging built-in Windows management tools such as PowerShell, `wmic.exe`, `winrm.exe`, and `wbemtest.exe` to execute payloads in memory and bypass traditional disk-focused antivirus. - **Remote Protocols & Access:** Remote interaction through DCOM (TCP Port 135 and dynamic secondary ports) and WinRM / PowerShell Remoting (typically Port 5985). - **WMI Eventing Mechanism:** Building permanent event subscriptions that run in the `SYSTEM` context and survive system reboots using three fundamental components: an **Event Filter** (defined via WQL queries), an **Event Consumer** (such as `ActiveScriptEventConsumer` for VBScript/JScript or `CommandLineEventConsumer`), and a **FilterToConsumerBinding** linking them together. - **Event Types:** Using intrinsic events (polling-based object/class lifecycle events like `__InstanceCreationEvent` on `Win32_Process` or namespaces) and extrinsic events (immediate, high-performance events like `Win32_ProcessStartTrace`, `Win32_ModuleLoadTrace`, or `Win32_VolumeChangeEvent`). - **In-the-Wild & Historical Precedents:** Prior weaponization of WMI, including Stuxnet's use of MOF files via the MS10-061 print spooler exploit, the Seadaddy / Seaduke malware family, the WMI Shell tool, and APT29's HammerToss using custom dynamic WMI classes for covert C2. - **Custom & Malicious WMI Providers:** How DLL- or driver-backed WMI providers can be developed or abused to execute shellcode or run PowerShell scripts in the `SYSTEM` context.

### Technical Details - **Fileless Storage:** WMI stores classes, instances, and permanent subscriptions inside the `objects.dat` repository located in `System32\wbem\Repository`. Antivirus historically does not inspect or flag on `objects.dat`, enabling stealthy storage of Base64-encoded payloads. - **C2 & Staging Techniques:** Attackers can dynamically create or modify WMI namespaces, classes, or registry keys (using `StdRegProv`) to stage data, trigger execution via `Win32_Process.Create`, and read back execution outputs remotely. - **Temporary Permanent Subscriptions:** To avoid process and command-line auditing associated with `Win32_Process.Create`, an attacker can register an `ActiveScriptEventConsumer` driven by a timer event, execute the payload via `scrcons.exe`, and have the script delete its own filter, consumer, and binding. - **Proof-of-Concept WMI Backdoor:** Graeber demonstrated a PowerShell-based installer that configures permanent WMI event backdoors targeting actions like file creation/modification (file uploader), removable media insertion (drive infector), and process launching (terminating tools like Process Explorer).

### Takeaways & Defenses - **Forensics & Detection:** Utilities like Autoruns and Kanza can help inspect persistence. Additionally, Graeber highlights research into parsing `objects.dat` directly for forensic analysis. - **WMI as an Agentless Host IDS:** Defenders can register their own permanent WMI subscriptions to alert on suspicious behaviors, such as registry persistence, start menu additions (`Win32_StartupCommand`), or the registration of new permanent WMI event subscriptions. - **Mitigations:** Restricting remote access via firewall rules (blocking Port 135/DCOM), locking down WMI namespace ACLs to restrict method execution like `Win32_Process.Create`, auditing event logs, or disabling the WMI service where remote management is not required.