Living Off the Walled Garden: Abusing the Features of the Early Launch Antimalware Ecosystem

## Overview

The talk focuses on abusing features within Microsoft’s Early Launch Antimalware (ELAM) ecosystem and Protected Process Light (PPL) architecture. ELAM is an anti-tampering security mechanism provided by Microsoft for first-party products (such as Defender for Endpoint and Defender AV) and third-party endpoint security vendors. The speaker builds upon foundational research by James Forshaw and Alex Ionescu (specifically their 2018 REcon presentation).

The research is strictly scoped to attacking and abusing user-mode security boundaries. While kernel-mode bypasses (e.g., abusing signed vulnerable drivers) can bypass PPL and ELAM, the talk investigates how the design, verification mechanisms, and administrative capabilities of PPL and ELAM can be leveraged purely from user space.

---

## PPL and the Antimalware-Light Level

PPL is engineered to prevent user-mode tampering, even by users with administrative or `SYSTEM` privileges: - **Tampering Restrictions:** PPL restricts unauthorized processes from stopping protected processes, acquiring process handles, or attaching debuggers. Stopping an existing protected process is significantly harder than starting one. - **Troubleshooting Complexity:** Without appropriate signing certificates in place, debugging and troubleshooting PPL processes is difficult even in legitimate administrative scenarios. - **Signing Requirements:** To execute at the `Antimalware-Light` protection level, an executable must fulfill strict, specific code-signing criteria defined by the vendor's ELAM configuration.

---

## ELAM Driver Requirements and Architecture

To run a user-mode service as a PPL `Antimalware-Light` process, an ELAM driver is mandatory: - **Driver Content:** An ELAM driver does not strictly require executable driver code to enable PPL services. While optional early launch hooks can perform signature checks during boot, the essential component is a binary resource embedded in the driver. - **Certification & Trust:** The embedded binary resource defines the rule set and specifies which signers (certificate identities) are permitted to launch protected anti-malware services. To be co-signed by Microsoft as an official ELAM driver, vendors must submit the driver to Microsoft and maintain membership in the Microsoft Virus Initiative (MVI) program. - **Registration Methods:** ELAM drivers are traditionally installed as services under the `early launch` service group (such as `WdBoot`, the default Defender AV ELAM driver installed on Windows). However, the speaker notes that this traditional service installation is not strictly required, as drivers can also be registered directly via Windows API calls.

---

## Signer Verification and TBS Hashing

ELAM drivers enforce trust by defining certificate rules using specific cryptographic representations: - **TBS Hashes vs. Thumbprints:** Unlike common certificate identification mechanisms that rely on SHA-1 thumbprints, ELAM binary resources store "To Be Signed" (TBS) hashes. The TBS hashing algorithm is determined by the algorithm specified in the certificate itself and matches the hashing format used in Windows Defender Application Control (WDAC). - **Tooling and Analysis Obstacles:** Auditing ELAM rule sets presents practical research hurdles because threat intelligence platforms like VirusTotal support searching by certificate thumbprint rather than TBS hashes. Consequently, reverse-mapping an ELAM rule's TBS hash to matching candidate executables is not directly supported by default. - **TBS Calculation Utilities:** The speaker identifies two main utilities to calculate TBS hashes: 1. `CertMgr` (included in the official Windows SDK). 2. A custom, publicly available PowerShell script developed by the speaker titled `Get-TBSHash`.