Bypassing Windows PPL: How TOCTOU Vulnerabilities Defeat LSASS Protection

TLDR: Windows Protected Process Light (PPL) is intended to prevent unauthorized access to sensitive processes like LSASS, but it relies on flawed assumptions about kernel-level trust. By exploiting Time-of-Check, Time-of-Use (TOCTOU) vulnerabilities in the Windows paging and code integrity mechanisms, researchers can force the kernel to load malicious code into protected processes. This research introduces PPLFault, a tool that automates these bypasses, demonstrating that PPL is not a security boundary against a local administrator.

Security researchers have long treated Windows Protected Process Light (PPL) as a significant hurdle during post-exploitation. When you land on a box as a local administrator, your first instinct is often to dump LSASS to harvest credentials. PPL was designed specifically to stop this, hardening processes against memory dumping and tampering by restricting handle access. However, the assumption that the kernel can perfectly mediate these requests is fundamentally flawed. Recent research presented at Black Hat 2023 exposes how the very mechanisms the kernel uses to maintain performance—specifically paging and code integrity—can be weaponized to bypass these protections entirely.

The Mechanics of the PPL Bypass

The core of the issue lies in how the Windows kernel handles file loading and memory management for protected processes. When a PPL-protected process needs to load a DLL, the kernel’s Code Integrity (CI) subsystem verifies the file's signature. If the signature is valid, the kernel maps the file into the process's memory space. The vulnerability arises because this verification process is decoupled from the actual execution of the code.

This is a classic TOCTOU race condition. The kernel performs a check on the file on disk, confirms it is signed by a trusted authority, and then proceeds to map it. If an attacker can manipulate the file or the underlying I/O operations between the time the kernel verifies the file and the time it actually reads the data into memory, they can swap the legitimate code for a malicious payload.

The research highlights that the kernel often performs multiple reads of the same file. By using opportunistic locks (oplocks), an attacker can suspend the process's I/O operations. This creates a window of time to manipulate the file system or the network redirector, ensuring that the second read—the one that actually populates the memory—pulls the attacker's payload instead of the verified, signed code.

Weaponizing the Paging Mechanism

The most elegant part of this research is the use of the Windows paging mechanism to deliver the payload. When a process accesses a memory page that isn't currently in physical RAM, a page fault occurs, and the kernel fetches the data from disk.

By forcing a page fault for a DLL loaded by a PPL process, an attacker can trigger a read operation. If the attacker has redirected the file access to a malicious SMB share or a local file controlled via a symbolic link, they can serve the legitimate DLL during the initial CI check and then swap it for a malicious version when the page fault occurs. This technique, which the researcher dubbed PPLFault, effectively turns the kernel's own memory management against itself.

The following snippet illustrates the logic used to identify potential targets for this type of manipulation:

# Checking for processes that might be susceptible to paging manipulation
Get-Process | Where-Object {$_.Path -like "*System32*"} | ForEach-Object {
    # Logic to monitor file access patterns via ProcMon
    # Look for paging I/O operations that are not backed by local disk
}

Real-World Applicability for Red Teams

For a pentester, this research changes the calculus on how to handle hardened Windows environments. Previously, if you encountered a system where LSASS was protected by PPL, you might have moved on to other post-exploitation tasks. Now, you have a viable path to credential access even in these environments.

The impact is severe. Once you achieve arbitrary code execution within a PPL-protected process, you are effectively running with the same privileges as the protected service. You can bypass the restrictions that prevent you from reading LSASS memory, allowing you to extract cleartext passwords, NTLM hashes, or Kerberos tickets. This is not just a theoretical bypass; it is a practical, repeatable technique that works on fully patched versions of Windows 11.

Defensive Considerations

Defenders should focus on monitoring for unusual file access patterns, particularly those involving the network redirector or symbolic links targeting sensitive system directories. While Microsoft has implemented mitigations like NoRemoteImages, these are often insufficient if an attacker has local administrative access.

The most effective defense is to assume that any local administrator can eventually compromise the kernel. Hardening the environment through strict application control, minimizing the number of users with administrative privileges, and implementing robust EDR telemetry to detect the specific I/O patterns associated with TOCTOU attacks are essential.

Ultimately, PPL is a defense-in-depth measure, not a silver bullet. It forces an attacker to jump through more hoops, but it does not stop a determined adversary. If you are conducting an engagement and find yourself blocked by PPL, look for the gaps in the kernel's I/O mediation. The path to the credentials you need is likely hidden in the way the system handles its own memory.