Inspecting Windows Protected Processes: Tools and Techniques

⚠️ Educational Purpose: This content is for educational and authorized security research only. Process inspection and debugging should only be performed on systems you own or have explicit permission to analyze.

Introduction

Windows operating systems implement various security mechanisms to protect critical processes from tampering and inspection. Understanding these protections and the tools available to work with them is essential for security researchers, malware analysts, and system administrators. This article explores process inspection tools, protected processes, and the techniques used to analyze even the most restricted system components.

Process Explorer: The Standard Tool

Process Explorer from Sysinternals is one of the most powerful and widely-used tools for inspecting running processes on Windows systems. Originally created by Mark Russinovich before Microsoft's acquisition of Sysinternals in 2006, it has become the de facto standard for process inspection in the Windows ecosystem. The tool provides comprehensive visibility into process hierarchies, showing parent-child relationships in a tree structure that makes it easy to trace how processes spawn and interact with each other.

Beyond simple process listings, Process Explorer reveals the internal workings of each process by displaying loaded DLL dependencies and modules, providing detailed handle information for files, registry keys, and threads, showing real-time memory usage and performance metrics, tracking network connections and TCP/IP endpoints, and exposing security context and token information that reveals the privileges each process operates with.

Basic Usage

Process Explorer displays processes in a tree structure, showing the relationship between parent and child processes. You can view detailed information by double-clicking any process, which opens a comprehensive properties dialog showing everything from command-line arguments to environment variables.

# Download Process Explorer from Sysinternals
# Don't forget to run as Administrator to have access to full functionality
procexp.exe

When running with administrative privileges, Process Explorer can access most processes and display comprehensive information about their state, memory usage, and internal operations. However, even Administrator privileges have limitations when encountering certain protected processes, revealing a fundamental security boundary that Windows enforces at the kernel level.

The Protected Process Model

Windows implements a protected process mechanism to safeguard critical system processes from tampering, even by administrators. This protection mechanism has evolved significantly since its introduction, with Microsoft continually refining the security model to address emerging threats.

Historical Evolution

The protected process model was first introduced in Windows Vista (released January 2007) as part of the Premium Content Protection requirements for digital rights management (DRM). This initial implementation, known as Protected Process (PP), was designed specifically to prevent unauthorized access to processes handling premium media content like HD-DVD and Blu-ray playback. The protection prevented even administrators from reading process memory or injecting code into these DRM-protected processes.

A significant architectural change came with Windows 8.1 (released October 2013), which introduced Protected Process Light (PPL) as a distinct protection level. Unlike the original PP designed solely for DRM scenarios, PPL provided a more flexible protection mechanism that extended to critical system services. This allowed Microsoft to protect essential operating system components like LSASS, antimalware services, and other security-critical processes without requiring the strict DRM-level protections of full PP. This was a crucial development that enabled hardening credential storage and authentication processes against the increasingly common credential theft attacks.

With Windows 10 and later versions, Microsoft expanded the PPL model with multiple protection signers and refined access rules, creating a sophisticated hierarchy that balances security requirements with operational functionality. This evolution reflected the changing threat landscape, where sophisticated attackers increasingly targeted system processes to steal credentials, maintain persistence, and evade detection.

Why Protected Processes Exist

Protected processes serve several critical security purposes that address real-world attack patterns. The anti-tampering protection prevents malware from injecting malicious code into critical system processes, a technique that advanced threats commonly use to hide their presence and elevate their privileges. By blocking code injection, memory manipulation, and unauthorized debugging at the user-mode level, protected processes significantly raise the bar for attackers, though it's important to note that PPL is not a silver bullet—kernel-mode attacks via vulnerable drivers or exploits can still potentially bypass these protections.

Digital rights management requirements drove the initial implementation for media content protection, but the security benefits extended far beyond DRM when PPL was introduced. System integrity assurances help ensure that core operating system components remain unmodified during runtime, making it substantially harder for rootkits and sophisticated malware to compromise fundamental Windows services through conventional user-mode techniques. Perhaps most critically for modern security, credential protection safeguards authentication processes and secrets stored in memory, directly addressing the epidemic of credential theft that tools like Mimikatz made trivially easy against unprotected LSASS processes.

Protection Levels and Signers

Windows defines a sophisticated hierarchy of protection levels that determines what operations can be performed on protected processes. Understanding this hierarchy is essential for security researchers and defenders because it dictates the access boundaries that user-mode code must respect. While kernel-mode code with sufficient privileges can technically bypass some protections, mechanisms like Driver Signature Enforcement and HVCI make this increasingly difficult.

Protection Types:

The PS_PROTECTED_TYPE enumeration defines three protection levels: PsProtectedTypeNone (0) represents standard unprotected processes that operate with traditional Windows security boundaries. PsProtectedTypeProtectedLight (1) provides lighter protection suitable for critical system services and antimalware solutions, balancing security with operational flexibility. PsProtectedTypeProtected (2) offers the strongest protection, originally designed for DRM scenarios but used for the most critical system components.

Protection Signers Hierarchy:

The signer hierarchy creates a chain of trust where processes with higher-level signers can access processes protected by lower-level signers, but not vice versa. Access enforcement is implemented through the kernel's RtlTestProtectedAccess function, which compares the protection type and signer of both the requesting and target processes. A process can only open another protected process if its signer level is greater than or equal to the target's signer level.

From lowest to highest signer level:

• PsProtectedSignerAuthenticode (1) - Standard Authenticode-signed processes
• PsProtectedSignerCodeGen (2) - Code generation processes
• PsProtectedSignerAntimalware (3) - Registered antimalware vendors with special Extended Key Usage (EKU) certificates from Microsoft
• PsProtectedSignerLsa (4) - Local Security Authority processes (lsass.exe) when PPL is enabled
• PsProtectedSignerWindows (5) - Standard Windows system processes
• PsProtectedSignerWinTcb (6) - Windows Trusted Computing Base components
• PsProtectedSignerWinSystem (7) - Windows system services (highest protection level)

The PS_PROTECTION structure also includes an Audit bit that determines whether failed access attempts generate audit events, providing visibility into unauthorized access attempts against protected processes.

// Protection levels from Windows kernel structures
// Inspect in WinDbg with: dt nt!_PS_PROTECTED_TYPE
typedef enum _PS_PROTECTED_TYPE {
    PsProtectedTypeNone = 0,
    PsProtectedTypeProtectedLight = 1,
    PsProtectedTypeProtected = 2,
    PsProtectedTypeMax = 3
} PS_PROTECTED_TYPE;

// Inspect in WinDbg with: dt nt!_PS_PROTECTED_SIGNER
typedef enum _PS_PROTECTED_SIGNER {
    PsProtectedSignerNone = 0,
    PsProtectedSignerAuthenticode = 1,
    PsProtectedSignerCodeGen = 2,
    PsProtectedSignerAntimalware = 3,
    PsProtectedSignerLsa = 4,
    PsProtectedSignerWindows = 5,
    PsProtectedSignerWinTcb = 6,
    PsProtectedSignerWinSystem = 7,
    PsProtectedSignerApp = 8,
    PsProtectedSignerMax = 9
} PS_PROTECTED_SIGNER;

// PS_PROTECTION structure combines Type, Audit flag, and Signer
// Inspect in WinDbg with: dt nt!_PS_PROTECTION
typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type : 3;      // PS_PROTECTED_TYPE
            UCHAR Audit : 1;     // Audit flag for access attempts
            UCHAR Signer : 4;    // PS_PROTECTED_SIGNER
        };
    };
} PS_PROTECTION;

You can inspect these structures directly in WinDbg during kernel debugging:

kd> dt nt!_PS_PROTECTED_TYPE
   PsProtectedTypeNone = 0n0
   PsProtectedTypeProtectedLight = 0n1
   PsProtectedTypeProtected = 0n2
   PsProtectedTypeMax = 0n3

kd> dt nt!_PS_PROTECTED_SIGNER
   PsProtectedSignerNone = 0n0
   PsProtectedSignerAuthenticode = 0n1
   PsProtectedSignerCodeGen = 0n2
   PsProtectedSignerAntimalware = 0n3
   PsProtectedSignerLsa = 0n4
   PsProtectedSignerWindows = 0n5
   PsProtectedSignerWinTcb = 0n6
   PsProtectedSignerWinSystem = 0n7
   PsProtectedSignerApp = 0n8
   PsProtectedSignerMax = 0n9

kd> dt nt!_PS_PROTECTION
   +0x000 Level            : UChar
   +0x000 Type             : Pos 0, 3 Bits
   +0x000 Audit            : Pos 3, 1 Bit
   +0x000 Signer           : Pos 4, 4 Bits

The combination of protection type and signer determines the effective protection level. For example, a process protected as PsProtectedTypeProtectedLight with signer PsProtectedSignerLsa would be LSASS running with PPL enabled. According to the access rules enforced by RtlTestProtectedAccess, this process can be accessed by processes with Antimalware signer (3) or higher (Lsa=4, Windows=5, WinTcb=6, WinSystem=7), but not by standard Authenticode-signed processes (1) or CodeGen processes (2).

Common Protected Processes in Windows

Understanding which processes typically run with protection helps you recognize what's normal in your environment and what might indicate tampering or misconfiguration.

Important Notes:

* smss.exe protection varies by Windows version and configuration. Public documentation on its exact protection level is limited, and it may not always run as full PP.

** LSASS PPL protection must be explicitly enabled through the RunAsPPL registry setting (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1) or Credential Guard. By default on most systems, LSASS runs unprotected, leaving credentials vulnerable to tools like Mimikatz. Windows 11 with VBS may enable this by default on some configurations.

*** Process protection levels can be verified using: Get-Process <name> | Select-Object Name, Protection in PowerShell, or by querying PROCESS_PROTECTION_LEVEL_INFORMATION via NtQueryInformationProcess, or by inspecting the PS_PROTECTION field in the EPROCESS structure via kernel debugging.

**** Important distinction: A PPL process can access another PPL process only if its signer level is greater than or equal to the target's signer. However, a PPL process cannot obtain full access to a full Protected Process (PP), regardless of signer level. PP provides stronger isolation than PPL.

***** GUI/Interactive Window Constraint: Processes with graphical user interfaces or interactive windows generally cannot use PPL protection due to kernel constraints around window management and user input. PPL is typically reserved for background services and system processes without UI components.

Case Study: CSRSS.exe

The Client Server Runtime Subsystem (csrss.exe) serves as an excellent example of a protected process in action. CSRSS is absolutely critical to Windows operation, dating back to the earliest versions of Windows NT. It manages Win32 console windows and handles the infrastructure that allows command-line programs to run. Beyond console management, CSRSS oversees process and thread creation and deletion, maintaining the kernel-mode structures that track running processes. It even retains some legacy responsibilities for 16-bit virtual DOS machine support and coordinates system shutdown procedures.

The criticality of CSRSS cannot be overstated. The Windows kernel marks CSRSS as a critical process (via RtlSetProcessIsCritical), which means if csrss.exe terminates for any reason—whether through a crash, termination attempt, or exploit—the kernel immediately triggers a bug check (STOP error/blue screen) because the operating system cannot function without it. This critical process marking, combined with PPL protection, makes CSRSS an attractive target for attackers who want to hide malicious code or manipulate system behavior, which is precisely why Microsoft protects it with multiple defensive layers.

Limitations of Process Explorer with CSRSS

Even when running Process Explorer with Administrator privileges, you'll encounter significant limitations when attempting to inspect csrss.exe. The tool cannot retrieve full process information beyond basic details like process ID and creation time. Attempts to read process memory contents fail with access denied errors. Handle information remains restricted, preventing you from seeing what files, registry keys, or other objects CSRSS has open. DLL injection operations fail completely, making it impossible to use injection-based analysis techniques. Even basic operations like viewing complete thread information or suspending threads for analysis are blocked by the kernel.

Error: Access is denied
Unable to query process information for csrss.exe (PID: 632)

This protection exists because csrss.exe is marked as a Protected Process Light (PPL) with Windows signer-level protection. The operating system kernel enforces these restrictions at a fundamental level during handle creation. When a non-protected or lower-privileged process attempts to open a handle to CSRSS, the kernel's ObOpenObjectByPointer and related functions check the PS_PROTECTION fields of both processes. If the protection comparison fails, the kernel denies access rights including:

• PROCESS_VM_READ (0x0010) - Reading process memory
• PROCESS_VM_WRITE (0x0020) - Writing to process memory
• PROCESS_VM_OPERATION (0x0008) - Memory operations like VirtualProtectEx
• PROCESS_CREATE_THREAD (0x0002) - Creating remote threads
• PROCESS_DUP_HANDLE (0x0040) - Duplicating handles
• PROCESS_SUSPEND_RESUME (0x0800) - Suspending/resuming threads

Typically, only PROCESS_QUERY_LIMITED_INFORMATION (0x1000) is granted, allowing minimal information retrieval while blocking all manipulation attempts.

Why Even Administrators Are Blocked

Windows uses a security model where protection levels are enforced at the kernel level, creating a hierarchy that transcends traditional privilege boundaries. Understanding this architecture helps explain why administrator accounts cannot bypass protected process restrictions.

The kernel refuses to grant full access handles to protected processes based on their protection level, regardless of the caller's user privileges. This is a fundamental security boundary that operates below the traditional user/administrator privilege model. When you request a handle to a protected process via OpenProcess or similar APIs, the kernel's process manager performs protection-level comparison before privilege checks.

The kernel executes roughly this logic:

// Simplified kernel protection check (actual implementation in ntoskrnl.exe)
if (TargetProcess->Protection.Level != 0) {
    if (!RtlTestProtectedAccess(CallerProcess->Protection, 
                                 TargetProcess->Protection)) {
        // Deny dangerous access rights regardless of privileges
        DesiredAccess &= PROCESS_QUERY_LIMITED_INFORMATION;
    }
}

The RtlTestProtectedAccess function compares both the protection type (None/PPL/PP) and signer level. Even if the calling process runs as SYSTEM with SeDebugPrivilege, if its PS_PROTECTION structure shows insufficient protection, the kernel strips dangerous access rights from the handle. This means being Administrator or even SYSTEM isn't enough—you need to be running as a protected process with a signer level greater than or equal to the target's signer level. Additionally, PPL processes cannot obtain full access to PP (Protected Process) targets, regardless of signer level, as PP represents a higher protection tier.

Process Hacker: Advanced Inspection Capabilities

Process Hacker is a powerful open-source alternative to Process Explorer with enhanced capabilities for inspecting protected processes. Originally developed as a community effort to create a more capable process viewer, Process Hacker has evolved into the tool of choice for security researchers and advanced users who need deeper system insight than Process Explorer provides.

Why Process Hacker Succeeds Where Process Explorer Fails

The key to Process Hacker's enhanced capabilities lies in its kernel driver (KProcessHacker.sys), which operates in kernel mode at Ring 0. This architectural difference is fundamental to understanding why Process Hacker can access information that Process Explorer cannot retrieve.

Operating at the same privilege level as the Windows kernel itself, the KProcessHacker driver can bypass user-mode security restrictions that normally block administrative tools. The driver queries kernel structures directly, accessing process information without going through the restricted Win32 APIs that respect PPL boundaries. This direct kernel access allows it to read protected process memory and query information that would normally be denied to user-mode applications.

Important Limitations and Caveats:

While kernel drivers operate at Ring 0, they don't bypass all protections. Modern Windows includes several defensive mechanisms:

• Driver Signature Enforcement (DSE) - On 64-bit Windows with Secure Boot enabled, only drivers signed with Extended Validation (EV) certificates can load. Process Hacker's KProcessHacker driver is not EV-signed for Secure Boot, requiring either Secure Boot to be disabled or test signing mode enabled (bcdedit /set testsigning on), both of which significantly weaken system security.

• PatchGuard (Kernel Patch Protection) - Monitors critical kernel structures and triggers bug checks if unauthorized modifications are detected. Drivers that attempt to disable PPL protection or modify kernel security structures risk triggering PatchGuard.

• HVCI (Hypervisor-protected Code Integrity) - On systems with VBS/HVCI enabled, the hypervisor enforces code integrity, making it extremely difficult for drivers to execute arbitrary code or modify protected memory regions.

• Antimalware/EDR Detection - Kernel drivers with memory access capabilities are commonly flagged by security software as potentially malicious. Process Hacker's driver may trigger alerts or be blocked by endpoint protection.

The driver provides enhanced token manipulation capabilities, allowing Process Hacker to view security tokens more thoroughly than standard tools. However, actually modifying protection levels or critical security structures carries significant risk of system instability or detection. Research has shown that while PPL provides strong protection, it's not unbreakable—kernel-mode attacks via vulnerable drivers (BYOVD) or kernel exploits can potentially disable or bypass PPL, though such attacks are increasingly difficult and detectable on modern systems.

Using Process Hacker

# Download Process Hacker from official repository
# Run as Administrator
ProcessHacker.exe

When you enable the kernel driver in Process Hacker through Options → Enable Kernel-mode driver, it loads KProcessHacker.sys into kernel space. This gives the application access to protected process information that would otherwise be inaccessible. You can then view complete process memory contents, including data that protected processes keep hidden from user-mode tools. Access to handle information from protected processes becomes available, showing you exactly what resources these critical processes are using. Thread inspection becomes fully functional, allowing you to view stack traces and examine the execution state of protected process threads. Memory dumping operations succeed, enabling you to capture process memory for offline analysis. Token information and integrity levels become visible, revealing the complete security context.

Important Considerations

While Process Hacker can inspect protected processes, this capability comes with significant caveats that users must understand.

Driver Signing Requirements:

Modern Windows (10/11 and Server 2016+) requires Extended Validation (EV) code-signed kernel-mode drivers for systems with Secure Boot enabled. The original KProcessHacker driver is not EV-signed for Secure Boot and therefore cannot load on a properly secured system unless:

• Secure Boot is disabled in UEFI/BIOS settings, or
• Test signing mode is enabled (bcdedit /set testsigning on)

Enabling test signing mode invalidates Secure Boot protections and allows unsigned or test-signed drivers to load, which represents a significant decrease in OS integrity enforcement. While test signing doesn't eliminate all security features, it creates a substantial weakness in the boot chain and driver loading policies.

EDR and Security Software:

Security software commonly flags or blocks kernel drivers:

• Detection and Alerts - Most EDR solutions flag kernel drivers with memory access capabilities as potentially malicious
• Policy-Based Blocking - Some EDRs prevent loading any non-approved drivers, even if properly signed, via kernel callbacks (ObRegisterCallbacks, PsSetLoadImageNotifyRoutine) or internal driver allowlisting policies
• Exception Management - Creating exceptions for Process Hacker's driver may create blind spots in security monitoring

System Stability Risks:

Kernel-mode operations can cause system instability if misused. Unlike user-mode crashes that terminate a single application, kernel-mode crashes trigger a system-wide bug check (BSOD). Additionally:

• PatchGuard limitations - Even with a kernel driver loaded, PatchGuard monitors critical kernel structures and will trigger bug checks if unauthorized modifications are detected
• PPL enforcement - While kernel drivers can technically read protected process memory, attempting to modify protection levels or disable PPL risks PatchGuard violations
• Code Integrity - On systems with HVCI enabled, the hypervisor enforces additional constraints that limit what kernel drivers can accomplish

Deep Inspection with WinDbg and Kernel Debugging

For the deepest level of process inspection, kernel debugging with WinDbg provides unparalleled access to system internals. WinDbg is Microsoft's official debugger, designed for kernel-mode debugging and low-level system analysis. When configured for kernel debugging, WinDbg connects to a target system and operates with complete visibility into kernel structures, including all protected processes.

The !process Command

The !process command in WinDbg allows you to inspect process structures directly in the kernel debugger. This command queries the kernel's internal process structures (EPROCESS blocks) that contain all the information Windows maintains about running processes.

Note: The actual WinDbg output will be shown in screenshots throughout this section rather than text output.

Advanced Process Inspection Commands

Beyond the basic !process command, WinDbg provides extensive capabilities for deep process analysis through its kernel debugging extensions:

# Display detailed process information
kd> !process <process_address> 7

# Display all processes
kd> !process 0 0

# Display process with specific PID
kd> !process <address> 0

# Display process token information
kd> !token <token_address>

# Display process protection level
kd> dt nt!_EPROCESS <address> Protection

The !process command with flag 7 displays the most detailed view, including all threads, loaded modules, and handle information. Using address 0 with flag 0 lists all processes in the system, providing an overview of everything running. The !token command examines security tokens in detail, showing privileges, groups, and integrity levels. The dt (display type) command shows the raw EPROCESS structure, including the Protection field that contains the PPL information.

Kernel Debugging Setup

Kernel debugging requires a two-machine setup where the debugger runs on one system and the target system being debugged runs on another. This separation is necessary because kernel debugging freezes the entire target system when breakpoints are hit or when you're examining system state. Virtual machines work excellently for this purpose, as you can configure the VM to expose a debugging interface.

Setting up kernel debugging on the target machine requires enabling debug mode through the Boot Configuration Data (BCD):

bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200

For virtual machine debugging, you'll typically configure a named pipe or network connection instead of serial. VMware and Hyper-V both support kernel debugging through their virtual hardware. Once configured, WinDbg connects to the target and provides complete kernel-level access.

The debugger must be configured with symbol paths for Windows symbols, which allow WinDbg to resolve function names, structure layouts, and variable names. Microsoft provides public symbols through their symbol server:

.sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols
.reload

Kernel debugging provides unrestricted access because the debugger operates at kernel level, effectively becoming part of the operating system itself. This bypasses all user-mode protections and even most kernel-mode security checks because the debugger has frozen the system and can examine memory directly. From this perspective, even the most protected processes are completely visible.

Important Note: When kernel debugging is enabled, PatchGuard (Kernel Patch Protection) is automatically disabled or neutralized, allowing the debugger to inspect and modify kernel structures without triggering bug checks. This is why kernel debugging provides more freedom than loading a kernel driver on a running system, where PatchGuard remains active and will detect unauthorized kernel modifications.

Real-World Scenarios

Scenario 1: Incident Response - Blocked Memory Dump

During an incident response engagement, you identify suspicious network connections originating from what appears to be svchost.exe. Standard memory forensics tools fail when attempting to dump the process memory for analysis. Process Explorer shows "Access Denied" when trying to create a memory dump, even though you're running as Administrator.

This scenario reveals an important consideration: if a process is showing protection that seems unusual for its type, this could indicate either legitimate system hardening or potentially a rootkit masquerading as a protected process. Sophisticated malware has been known to manipulate process protection levels through kernel exploits to shield itself from analysis. The solution requires either kernel-mode memory acquisition tools or live kernel debugging to capture the suspicious process memory.

Scenario 2: Malware Analysis - Protection Level Checks

Modern malware increasingly includes protection level checks before attempting credential theft. Sophisticated samples will query the LSASS process protection status before deciding which technique to employ:

// Malware pseudo-code for adaptive credential theft
if (IsLsassProtected()) {
    // PPL is enabled - need kernel exploit or BYOVD
    AttemptKernelExploit();
    if (KernelAccessAcquired) {
        DumpLsassFromKernelMode();
    } else {
        // Fall back to alternative credential sources
        ExtractFromSAM();
        HarvestBrowserCredentials();
    }
} else {
    // Easy mode - direct memory access
    RunMimikatz();
}

This adaptive behavior means that simply enabling LSASS PPL can force attackers to reveal themselves through more detectable techniques like driver loading or SAM database access.

Scenario 3: EDR Evasion Through Process Injection

Red teams often need to inject into processes to evade EDR detection. When attempting to inject into winlogon.exe or other protected processes for token theft or credential access, the injection fails with STATUS_ACCESS_DENIED. This forces red teams to either target unprotected processes (which may be more heavily monitored) or invest in kernel-level access capabilities.

The protection mechanisms effectively create a "hard target" list that defenders can monitor more lightly, knowing that successful access to these processes requires sophisticated capabilities that generate other detectable artifacts like driver loads or kernel exploits.

Protected Processes: Technical Deep Dive

Protection Mechanisms

Protected processes implement multiple layers of security that work together to create a comprehensive defense against tampering and unauthorized access. Understanding these mechanisms reveals why protected processes are so resistant to traditional analysis and manipulation techniques.

1. Handle Access Restrictions

The kernel restricts handle operations based on protection levels through a comparison mechanism that evaluates both the target process's protection and the requesting process's protection. When a process attempts to open a handle to another process, the kernel's process manager examines the protection level of both processes.

// Highly simplified kernel logic for handle access
// Actual implementation evaluates multiple fields: protection type, signer level,
// requested access rights, and various flags through RtlTestProtectedAccess
if (TargetProcess->Protection.Level != 0) {
    if (!RtlTestProtectedAccess(CallerProcess->Protection, 
                                 TargetProcess->Protection)) {
        if (DesiredAccess includes PROCESS_VM_READ ||
            DesiredAccess includes PROCESS_VM_WRITE ||
            DesiredAccess includes PROCESS_CREATE_THREAD) {
            return STATUS_ACCESS_DENIED;
        }
    }
}

This check occurs before any user-mode code receives a handle, making it impossible for user-mode tools to bypass. The kernel examines the requested access rights, looking specifically for dangerous operations like reading memory (PROCESS_VM_READ), writing memory (PROCESS_VM_WRITE), creating threads (PROCESS_CREATE_THREAD), and several other operations that could be used for code injection or process manipulation. If the requesting process doesn't have a high enough protection level, these operations are denied regardless of administrative privileges.

Even basic query operations may be restricted—often only PROCESS_QUERY_LIMITED_INFORMATION is allowed for lower-privileged processes attempting to access protected processes. This limited access right permits only minimal information retrieval such as process ID and exit status, while blocking access to more sensitive details like memory contents, handles, or full token information.

2. Code Signing Requirements and Code Integrity

Protected processes can only load binaries that meet strict code signing requirements enforced through Windows Code Integrity (CI). This prevents attackers from injecting unsigned or incorrectly-signed DLLs into protected processes, even if they manage to bypass other protections.

Code Integrity Enforcement:

When a protected process attempts to load a DLL, the kernel's Code Integrity subsystem verifies the signature before allowing the load operation. The verification checks include:

• Signature validation - The DLL must be properly signed with a valid digital signature
• Signer level verification - The signer must meet or exceed the protection requirements of the target process
• Certificate chain validation - The entire certificate chain must be trusted and valid
• Hash verification - The file's hash must match the signed digest to prevent tampering

Signing Requirements by Protection Level:

Microsoft signatures are required for system PPL processes with Windows, WinTcb, and WinSystem signers, ensuring that only Microsoft-signed code can run in the most critical system components. Antimalware signatures use special Extended Key Usage (EKU) certificates issued to registered antimalware vendors through Microsoft's security partner program (formerly MAPP). These vendors must meet specific security requirements and maintain their certification status to retain their signing privileges. Store signatures cover Windows Store applications, allowing them to run with appropriate protection for the app model while preventing tampering.

If a process attempts to load a DLL that doesn't have the appropriate signature for its protection level, the load operation fails with STATUS_INVALID_IMAGE_HASH or similar error codes. This creates a complete trusted execution environment where only properly signed code meeting the protection requirements can execute within the process's address space. On systems with HVCI (Hypervisor-protected Code Integrity) enabled, these checks are further reinforced by the hypervisor, making bypass attempts even more difficult.

3. Thread and Memory Protections

Protected processes enforce comprehensive restrictions on thread and memory operations that prevent the most common attack techniques. External thread injection using APIs like CreateRemoteThread is completely blocked, preventing attackers from executing arbitrary code in the target process's context. Memory manipulation through WriteProcessMemory and related APIs fails with access denied, stopping attempts to patch code or modify data structures. Debugging operations that would allow attaching debuggers to inspect or manipulate the process are denied unless the debugger itself runs with sufficient protection. DLL signature verification ensures that only signed DLLs meeting the process's protection requirements can be loaded, creating an end-to-end trust chain.

These protections combine to create a hardened execution environment where even kernel-mode code must respect protection boundaries. While kernel drivers can technically access protected process memory, Windows Driver Signature Enforcement and HVCI (Hypervisor-protected Code Integrity) in modern Windows versions make it increasingly difficult to load malicious drivers that could exploit this access.

LSASS and Mimikatz: The Exception

Local Security Authority Subsystem Service (lsass.exe) represents one of the most targeted processes in Windows environments. As the process responsible for managing security policy, user authentication, and credential storage, LSASS contains the plaintext and hashed credentials that tools like Mimikatz seek to extract. Despite being a critical security process, Mimikatz can often successfully access LSASS memory and dump credentials, which seems contradictory to everything we've discussed about protected processes.

LSASS Protection Evolution

The history of LSASS protection reveals how Microsoft has gradually hardened this critical component in response to credential theft attacks. In Windows 7 and 8.0, LSASS ran as a standard SYSTEM process without any PPL protection. During this era, Mimikatz could trivially access LSASS memory and extract credentials, making post-exploitation credential harvesting almost automatic for attackers.

With Windows 8.1 in 2013, Microsoft introduced both Credential Guard and PPL protection for LSASS. Credential Guard uses virtualization-based security to isolate credentials in a separate secure environment. When Credential Guard is enabled, sensitive credential material is stored in a virtualization-based security (VBS) protected process called LSAIso.exe (LSA Isolated), which runs in a separate Virtual Trust Level (VTL) that even kernel-mode code cannot access without compromising the hypervisor itself. Meanwhile, PPL marks the standard LSASS process as protected, preventing normal processes from accessing it. However, there's a critical caveat: these protections are not enabled by default on most systems. Organizations must explicitly configure them through registry settings or Group Policy.

# Check if LSASS is running as PPL
Get-Process lsass | Select-Object -Property ProcessName, Protection

# Enable LSASS PPL protection (requires registry edit + reboot)
# HKLM\SYSTEM\CurrentControlSet\Control\Lsa
# RunAsPPL = dword:1

Important Note on Secure Boot: On systems with Secure Boot enabled, the RunAsPPL setting may be stored in UEFI firmware variables, making it significantly more difficult to disable even with administrator access to the registry. This UEFI-backed protection prevents attackers from simply changing the registry value to disable PPL, adding an additional layer of defense.

Compatibility Considerations: Enabling LSASS PPL can cause compatibility issues with some third-party authentication providers, password filters, or security tools that attempt to load custom modules into the LSASS process. Only properly signed modules with appropriate certificates are allowed in a PPL-protected LSASS. Organizations should test LSASS PPL in their environment before broad deployment to identify any compatibility problems.

Why Mimikatz Works

Mimikatz succeeds against unprotected LSASS because of how Windows security boundaries work by default. Most Windows systems, especially those upgraded from older versions or deployed without hardened security baselines, don't enable LSASS PPL protection. This leaves LSASS running as a standard SYSTEM process that can be accessed by other SYSTEM-level processes or users with appropriate privileges.

When Mimikatz runs with SYSTEM privileges (often achieved through tools like PsExec or by exploiting vulnerabilities), it has sufficient access to open handles to the unprotected LSASS process. The SeDebugPrivilege, which administrators and SYSTEM possess, explicitly allows reading memory from processes at the same or lower privilege levels. Mimikatz exploits this by using known memory patterns and structures to locate credential material within LSASS's address space, parsing the data structures that store password hashes, Kerberos tickets, and sometimes even plaintext credentials.

When Mimikatz Fails

When LSASS runs as PPL (Protected Process Light), Mimikatz encounters the same kernel-enforced barriers we've discussed throughout this article:

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # sekurlsa::logonpasswords
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)

Error code 0x00000005 corresponds to ACCESS_DENIED. Despite successfully acquiring SeDebugPrivilege (shown by "Privilege '20' OK"), the kernel refuses to grant a handle with memory-read permissions to the protected LSASS process. This demonstrates that PPL protection operates at a level below traditional Windows privileges—the kernel's process manager evaluates the protection level comparison before checking administrative privileges.

Bypassing LSASS Protection

While PPL significantly raises the bar for credential theft, determined attackers have several options for bypassing these protections, though each requires substantially more sophistication than running Mimikatz. Loading kernel drivers remains the most direct approach, where attackers either exploit vulnerabilities to load unsigned drivers or abuse legitimate signed drivers through Bring Your Own Vulnerable Driver (BYOVD) attacks. This technique requires kernel-level code execution, which is significantly harder to achieve than user-mode exploitation.

Bring Your Own Vulnerable Driver (BYOVD) Attacks

BYOVD attacks have become increasingly prevalent in ransomware and advanced persistent threat campaigns. The technique exploits legitimately signed drivers that contain vulnerabilities, allowing attackers to execute arbitrary code in kernel mode without needing a zero-day exploit. Once attackers achieve ring 0 (kernel mode) execution through a vulnerable driver, they can disable or circumvent protections like PPL, directly read protected process memory, or manipulate kernel security structures.

Common vulnerable drivers abused in the wild include:

RTCore64.sys (MSI Afterburner) - Contains a critical vulnerability (CVE-2019-16098) that allows arbitrary memory read/write primitives, enabling direct physical memory access. Security researchers at Sophos documented multiple ransomware families including RobbinHood and BlackByte exploiting this driver to terminate security software, disable PPL protections, and access protected processes like LSASS.

DBUtil_2_3.sys (Dell BIOS utility) - Provides memory read/write capabilities and IOCTL misuse vulnerabilities that attackers leverage to disable PPL, bypass security callbacks, and access LSASS. Exploited by advanced persistent threat actors including Lazarus Group and the CUBA ransomware group to escalate privileges and evade detection.

gdrv.sys (Gigabyte driver) - Offers memory mapping capabilities allowing kernel-mode code execution. Widely abused across multiple attack campaigns due to its prevalence on gaming systems and motherboard utilities.

Academic security research has identified hundreds of legitimately signed drivers with memory corruption vulnerabilities, IOCTL handling flaws, or insufficient input validation that remain exploitable for BYOVD attacks, creating a persistent challenge for defenders.

Defensive Mitigations:

Microsoft maintains a Vulnerable Driver Blocklist that Windows uses to prevent loading of known vulnerable drivers. This blocklist is updated through Windows security updates and is enforced more strongly when HVCI (Hypervisor-protected Code Integrity) is enabled. With HVCI active, the hypervisor validates driver integrity before loading, making it significantly harder for attackers to load blocklisted drivers even with administrative privileges.

However, blocklist effectiveness depends on systems receiving regular Windows updates, and many organizations lag behind in applying these updates. According to CISA (Cybersecurity and Infrastructure Security Agency) guidance, defenders should implement multiple layers of protection:

• Monitor driver load events - Kernel-mode drivers being loaded that are not part of a trusted baseline represent a critical detection opportunity. Sysmon Event ID 6 and Windows Event ID 7045 provide visibility into driver installations.
• Enable HVCI - Hypervisor-protected Code Integrity significantly strengthens blocklist enforcement and prevents many driver-based attacks
• Maintain driver allowlists - Organizations should maintain inventories of legitimate drivers in their environment and alert on any deviations
• Keep systems updated - Regular Windows updates ensure the vulnerable driver blocklist includes the latest known malicious drivers
• Implement EDR with driver monitoring - Modern EDR solutions can detect and block suspicious driver load attempts in real-time

Credential Guard bypass techniques target vulnerabilities in virtualization-based security itself, attempting to compromise the hypervisor or exploit weaknesses in how Credential Guard communicates with LSASS. These attacks are complex and often require multiple chained vulnerabilities. Alternative credential extraction targets include the Security Account Manager (SAM) database, NTDS.dit on domain controllers, credential managers, and cached domain credentials—each requiring different attack techniques but potentially yielding valuable credentials without touching protected LSASS.

Bootkit and UEFI malware represent the most sophisticated bypass, compromising the system before Windows even loads its protection mechanisms. By operating at the firmware level, these attacks can disable or circumvent PPL before LSASS starts. However, developing and deploying such malware requires significant resources and expertise, typically placing it in the realm of nation-state actors rather than common criminals.

Comparison of Inspection Tools

*Requires kernel driver to be loaded and signed

Security Implications

Understanding protected processes has profound implications for how we approach system security, both from defensive and offensive perspectives. The existence of these protections fundamentally changes the attack surface and the techniques required for successful system compromise.

For Defenders

Defensive security teams must actively enable and validate protected process configurations rather than assuming they're in place. Ensuring LSASS PPL and Credential Guard are enabled across enterprise systems should be a baseline security requirement, verified through automated configuration management and regular audits. These protections don't enable themselves, and many organizations run vulnerable configurations simply because they haven't explicitly hardened their systems.

Monitoring kernel driver loads represents a critical detection opportunity because bypassing PPL almost always requires kernel-mode access. Security teams should implement alerting on driver load events, especially for drivers that aren't part of the standard system image or signed by well-known vendors. Investigating unsigned drivers or those signed with suspicious certificates can reveal advanced attacks in progress. Process access auditing can detect reconnaissance activities where attackers probe for protection levels before launching attacks, and application whitelisting controls what processes can execute in the first place, reducing the attack surface available to adversaries.

For Attackers (Red Teams)

Red teams conducting authorized assessments must understand protection levels before planning their attacks. Modern penetration testing requires reconnaissance of which processes are protected, as this determines what techniques will work and what will trigger detections. Checking protection levels early in an engagement prevents wasted effort on techniques that are doomed to fail against hardened systems.

Identifying alternative credential storage locations becomes essential when LSASS is protected. Red teams should understand how to extract credentials from registry hives, memory of less-protected processes, network authentication traffic, and cached data structures. Kernel exploits may be necessary to bypass modern protections in fully hardened environments, though this significantly increases the sophistication required and the risk of system instability. Bring Your Own Vulnerable Driver (BYOVD) attacks leverage legitimate signed drivers with vulnerabilities, allowing kernel-level access without requiring zero-day exploits.

For Security Researchers

Researchers analyzing protected processes must establish proper isolated environments to avoid accidentally triggering security alerts or violating usage agreements. Using dedicated VMs with snapshots allows safe experimentation without risking production systems. Test signing mode enables loading custom drivers for research purposes, though it weakens overall system security and should only be used in isolated research environments.

Kernel debugging setups provide the deepest level of analysis for understanding protection mechanisms and potential vulnerabilities. Researchers should invest time in properly configuring kernel debugging environments with symbol support, as this enables detailed investigation of how protection mechanisms work at the code level. Responsible disclosure of vulnerabilities discovered in protection mechanisms ensures that Microsoft and the security community can address issues before they're exploited maliciously.

Detection and Monitoring

Detecting attempts to access or bypass protected processes provides early warning of sophisticated attacks. Modern security monitoring should include specific detection rules for protected process tampering.

Key Event IDs to Monitor

Windows Security Event Log:

• Event ID 4656: Handle to an object was requested - Monitor for handle requests to LSASS or other protected processes (shows the request attempt)
• Event ID 4663: An attempt was made to access an object - Tracks actual access operations, but requires SACL (System Access Control List) to be configured on the target object
• Event ID 4672: Special privileges assigned to new logon - Detects when SeDebugPrivilege and other sensitive privileges are assigned at logon
• Event ID 4673: A privileged service was called - Monitors use of privileged API/service calls (not specific to SeDebugPrivilege)

System Event Log:

• Event ID 7045: A service was installed in the system - New driver installations that could indicate BYOVD attacks
• Sysmon Event ID 6: Driver loaded - Use Sysmon for reliable driver load telemetry (not Windows Event ID 219, which indicates driver load failures)

Sysmon Configuration

Sysmon provides detailed telemetry for protected process monitoring. Key events to configure:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <!-- Driver Load Detection (Event ID 6) -->
    <!-- Exclude Microsoft-signed drivers, capture everything else -->
    <DriverLoad onmatch="exclude">
      <Signature condition="is">Microsoft Windows</Signature>
      <Signature condition="is">Microsoft Corporation</Signature>
    </DriverLoad>
    
    <!-- Drivers from suspicious paths -->
    <DriverLoad onmatch="include">
      <ImageLoaded condition="begin with">C:\Users</ImageLoaded>
      <ImageLoaded condition="begin with">C:\Temp</ImageLoaded>
      <ImageLoaded condition="begin with">C:\ProgramData</ImageLoaded>
      <ImageLoaded condition="contains">\AppData\</ImageLoaded>
    </DriverLoad>
    
    <!-- Process Access to LSASS (Event ID 10) -->
    <ProcessAccess onmatch="include">
      <TargetImage condition="end with">lsass.exe</TargetImage>
      <!-- PROCESS_VM_READ (0x0010) -->
      <GrantedAccess condition="contains">10</GrantedAccess>
      <!-- PROCESS_VM_WRITE (0x0020) -->
      <GrantedAccess condition="contains">20</GrantedAccess>
      <!-- PROCESS_VM_OPERATION (0x0008) -->
      <GrantedAccess condition="contains">08</GrantedAccess>
    </ProcessAccess>
    
    <!-- Process Access to other critical protected processes -->
    <ProcessAccess onmatch="include">
      <TargetImage condition="end with">winlogon.exe</TargetImage>
      <TargetImage condition="end with">lsaiso.exe</TargetImage>
      <GrantedAccess condition="contains">10</GrantedAccess>
      <GrantedAccess condition="contains">20</GrantedAccess>
    </ProcessAccess>
  </EventFiltering>
</Sysmon>

Note on LSASS monitoring: LSASS is frequently accessed by legitimate processes. Filter on suspicious source processes or correlate with other indicators. Monitoring csrss.exe access generates excessive noise and is not recommended unless you have a specific use case.

EDR Telemetry Indicators

Modern EDR solutions should alert on:

Suspicious Process Handle Operations - Repeated failed attempts to open handles to protected processes, especially with PROCESS_VM_READ or PROCESS_VM_WRITE access rights.

Unusual Driver Load Patterns - Drivers loaded from user-writable directories, drivers not part of the standard system image, or drivers with unusual signing certificates.

Protection Level Modification Attempts - Though rare and requiring kernel access, attempts to modify the protection level of running processes indicate advanced attack techniques.

SeDebugPrivilege Escalation - Processes acquiring debug privileges that don't typically need them, especially when followed by process access attempts.

PowerShell Monitoring Script

# Audit all running processes for their protection levels
function Get-ProcessProtectionStatus {
    Get-Process | Select-Object Name, Id, @{
        Name='Protection'
        Expression={
            try {
                $_.Protection
            } catch {
                "Unable to query"
            }
        }
    } | Where-Object {$_.Protection -ne "None" -and $_.Protection -ne "Unable to query"} |
    Sort-Object Protection | 
    Format-Table -AutoSize
}

# Monitor for new driver loads
function Watch-DriverLoads {
    $query = @"
    <QueryList>
      <Query Id="0" Path="System">
        <Select Path="System">*[System[Provider[@Name='Service Control Manager'] and (EventID=7045)]]
        </Select>
      </Query>
    </QueryList>
"@
    
    Register-WmiEvent -Query "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_SystemDriver'" -Action {
        $driver = $Event.SourceEventArgs.NewEvent.TargetInstance
        Write-Host "New driver loaded: $($driver.Name) from $($driver.PathName)" -ForegroundColor Yellow
    }
}

# Check LSASS protection status across domain
function Test-LsassProtection {
    param([string[]]$ComputerName)
    
    Invoke-Command -ComputerName $ComputerName -ScriptBlock {
        $protection = Get-Process lsass | Select-Object -ExpandProperty Protection
        $regValue = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -ErrorAction SilentlyContinue
        
        [PSCustomObject]@{
            Computer = $env:COMPUTERNAME
            ProcessProtection = $protection
            RegistryEnabled = $regValue.RunAsPPL -eq 1
            Vulnerable = ($protection -eq "None" -or $null -eq $protection)
        }
    } | Format-Table -AutoSize
}

Practical Exercises

Exercise 1: Compare Tool Capabilities

This exercise helps you understand the practical differences between user-mode and kernel-mode inspection tools. Start by running Process Explorer as Administrator and attempting to view detailed information about csrss.exe and lsass.exe. Document which information you can successfully retrieve and which operations are denied with access errors. Pay particular attention to memory views, handle information, and thread details.

Next, install Process Hacker from its official repository and enable the kernel driver through the options menu. Important: The KProcessHacker driver may not load on systems with Secure Boot enabled or strict driver signature enforcement unless you disable Secure Boot or enable test signing mode (bcdedit /set testsigning on). Both options reduce system security and may trigger alerts in enterprise environments with EDR deployed. Only proceed on isolated test systems where security policy violations are acceptable. Attempt the same inspections you tried with Process Explorer. Compare the level of detail you can now access, noting specifically what the kernel driver enables that was previously blocked. This hands-on comparison demonstrates the fundamental difference between user-mode and kernel-mode access to protected processes, while also illustrating the real-world constraints that driver signature enforcement imposes.

Exercise 2: Check LSASS Protection Status

Understanding whether LSASS is running with PPL protection is essential for assessing your system's security posture. Use PowerShell to query the LSASS process and examine its protection level. The Protection property will reveal whether PPL is active or if LSASS is running unprotected.

# Check current LSASS protection status
Get-Process lsass | Select-Object Name, Id, Path, @{
    Name='Protection'
    Expression={$_.Protection}
}

# Check registry setting
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -ErrorAction SilentlyContinue

# Query protection level programmatically via WMI
Get-CimInstance -ClassName Win32_Process -Filter "Name='lsass.exe'" | 
    Select-Object ProcessId, @{Name='ProtectionLevel';Expression={
        (Get-Process -Id $_.ProcessId).Protection
    }}

If the registry value RunAsPPL is absent or set to 0, LSASS may be vulnerable to credential theft tools like Mimikatz, though absence of the registry setting doesn't guarantee LSASS is unprotected—some systems use firmware/UEFI variables or Group Policy to enable PPL. Compare the protection status across different Windows versions and deployment methods if you have access to multiple test systems. Important: Protection status varies significantly based on OS version (Windows 10 vs 11), installation method (clean install vs upgrade), hardware capabilities (TPM 2.0, UEFI), licensing (Enterprise vs Pro), and organizational security policies. Don't assume PPL is enabled just because the system is running Windows 10 or 11—explicit verification is essential.

Exercise 3: Kernel Debugging Setup

Setting up a kernel debugging environment provides the most complete view of protected processes available. Prerequisites: You need two separate machines or VMs—one as the debug target and one as the debugger host. The target system must support your chosen debug transport (serial/COM port, network debugging, USB, or 1394). Both systems need compatible Windows versions and WinDbg installed on the debugger machine.

Begin by creating a Windows VM that will serve as your debug target. Configure a second VM or use your host system as the debugger machine with WinDbg installed. Connect the two systems using the appropriate debug transport—serial over named pipe for VMware, or network debugging for Hyper-V and physical machines.

On the target VM, enable kernel debugging through bcdedit and configure the debug settings to match your transport method:

# For network debugging (Hyper-V, physical machines)
bcdedit /debug on
bcdedit /dbgsettings net hostip:<debugger_ip> port:50000

# For serial debugging (VMware with named pipe)
bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200

Critical Warning: When kernel debugging is active, the target system will freeze completely whenever WinDbg hits a breakpoint or when you manually break into the debugger. The entire OS halts—no UI updates, no network traffic, no disk I/O. This is normal behavior for kernel debugging but can be confusing if you're not expecting it. Additionally, kernel debugging disables PatchGuard, weakens security protections, and may cause performance degradation. Never enable kernel debugging on production systems.

Reboot the target and connect from WinDbg on the debugger machine. Once connected, configure symbol paths to Microsoft's symbol server so WinDbg can resolve Windows functions and structures:

.sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols
.reload

Symbol downloads can take significant time on first connection (several minutes to hours depending on your internet connection), so be patient. Use the !process command to inspect protected processes like csrss.exe and lsass.exe, comparing the kernel-level view with what user-mode tools showed you. This exercise demonstrates the ultimate level of system visibility that kernel debugging provides, while also revealing why it's reserved for advanced analysis scenarios rather than everyday troubleshooting.

Best Practices for Process Inspection

When conducting process inspection and analysis, selecting the appropriate tool for your access level and objectives is fundamental. Process Explorer works excellently for general process management and basic analysis tasks that don't require bypassing protection mechanisms. For deeper inspection of protected processes, Process Hacker with its kernel driver provides enhanced capabilities while remaining more accessible than full kernel debugging—though be aware that its kernel driver may not load on systems with Secure Boot enabled or strict driver signature enforcement, and its use may trigger security alerts in enterprise environments with EDR deployed. WinDbg kernel debugging should be reserved for the most detailed analysis where you need complete visibility into kernel structures and protected process internals.

Understanding each tool's limitations prevents frustration and helps you choose the right approach for your investigation. Process Explorer's inability to access certain protected process details isn't a bug—it's the Windows security model working as designed. Recognizing when you need kernel-mode access helps you escalate to appropriate tools rather than attempting impossible operations with inadequate tools.

Documentation becomes increasingly important as you work with complex system internals. Detailed notes about process protection levels, handle access patterns, and tool capabilities create a knowledge base for future investigations. Screenshotting error messages, protection status indicators, and successful inspection results provides visual documentation that's easier to reference than trying to remember specific behaviors.

Respecting protection mechanisms and authorization boundaries is both a legal and ethical requirement. Bypassing protected process restrictions without proper authorization can violate computer fraud laws, even on systems you own if those systems are subject to regulatory requirements. Organizational policies, penetration testing rules of engagement, and responsible disclosure guidelines all provide frameworks for when and how to conduct protected process analysis.

Staying updated on protection mechanism evolution ensures your understanding remains current. Microsoft continually refines PPL, Credential Guard, and related protections with each Windows version and major update. New signer types, changes to the protection hierarchy, and additional kernel enforcement mechanisms can change what's possible with existing tools. Following Windows Internals researchers, security blogs, and Microsoft documentation helps you maintain accurate knowledge of the current protection landscape.

System Hardening Checklist

For defenders implementing protected process security across their environment:

Critical Protections

• Enable LSASS PPL - Set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL to 1 (requires compatible hardware and OS; test for compatibility with third-party authentication providers before enterprise deployment)
• Enable Credential Guard - Configure via Group Policy or UEFI settings on compatible hardware (Windows 11 22H2+ with VBS-capable hardware may enable by default on fresh installs)
• Enable Hypervisor-Protected Code Integrity (HVCI) - Prevents unsigned code execution in kernel (enabled by default on Windows 11 fresh installs with compatible hardware)
• Configure Vulnerable Driver Blocklist - Ensure Windows updates include latest driver blocks and HVCI is enabled for stronger enforcement
• Enable Memory Integrity - Additional VBS protection layer (default on Windows 11 fresh installs)

Monitoring and Detection

• Deploy Sysmon - Configure with protected process and driver load monitoring rules
• Configure Security Event Collection - Forward Event IDs 4656, 4663, 4673 to SIEM
• Enable Process Access Auditing - Track handle requests to sensitive processes
• Monitor Driver Loads - Alert on drivers from non-standard locations
• Implement EDR - Deploy endpoint detection with kernel visibility

Policy Enforcement

• Configure Driver Signature Enforcement - Prevent unsigned driver loading
• Enable Secure Boot - Prevent bootkit attacks on compatible hardware
• Disable Test Signing Mode - Ensure production systems reject test-signed drivers
• Application Control - Implement Windows Defender Application Control (WDAC)
• Least Privilege - Limit accounts with SeDebugPrivilege

Validation and Testing

• Audit Current Protection Levels - Verify which processes are actually protected
• Test Credential Theft Tools - Validate Mimikatz fails against LSASS
• Review Driver Inventory - Document all legitimate drivers in environment
• Penetration Test - Include protected process bypass in scope
• Regular Compliance Checks - Automated scanning for protection configuration

Windows 11 and Modern Security Defaults

Windows 11 represents a significant shift in default security postures, with Microsoft making virtualization-based security features enabled by default on fresh installations with compatible hardware. The actual protection status varies significantly based on installation method, hardware capabilities, licensing, and organizational policies.

Virtualization-Based Security (VBS) runs by default on new Windows 11 clean installations on systems with compatible hardware (TPM 2.0, UEFI with Secure Boot, virtualization extensions). This creates a hypervisor-isolated environment for security-critical operations. This fundamentally changes the threat model because even kernel-mode code cannot access VBS-protected memory without exploiting the hypervisor itself. Critical caveat: Upgrades from Windows 10 to Windows 11 do not automatically enable VBS—organizations must explicitly enable it post-upgrade.

Memory Integrity (HVCI) is enabled by default on clean installs of Windows 11 with compatible hardware, preventing unsigned or improperly signed code from executing in kernel mode. Microsoft documentation states: "Memory integrity is turned on by default on clean installs of Windows 11." This directly counters BYOVD attacks by blocking vulnerable drivers from loading, even if attackers have administrative privileges. The impact on legacy driver compatibility means some older software may require compatibility testing. Upgrades from Windows 10 may not enable HVCI automatically, requiring manual configuration validation.

Credential Guard availability depends on multiple factors. According to Microsoft, "All devices running Windows 11, version 22H2 or later will have Credential Guard enabled by default...if they meet the hardware, licensing, and software requirements." The requirements include VBS-capable hardware, Windows 11 Enterprise or Education editions (not Pro), TPM 2.0, and UEFI with Secure Boot. Even when these conditions are met, organizations should validate that Credential Guard is actually active rather than assuming it's enabled. When active, Credential Guard moves credential storage into a VBS-protected virtual trust level (VTL) that even kernel code cannot access.

Secured-core PC requirements in enterprise environments mandate these protections remain enabled and tamper-resistant. Systems certified as Secured-core PCs include additional firmware protections that prevent disabling security features even with physical access. These represent the highest security tier but are typically deployed only in high-security environments.

Real-world protection status varies significantly: Windows 11 systems deployed via fresh installation on modern hardware (2020+) with TPM 2.0 and Enterprise/Education licensing will have the strongest default protections. Systems upgraded from Windows 10, using Pro licensing, or running on older hardware will likely require explicit configuration to achieve the same protection levels. Organizations should audit their Windows 11 deployments to verify actual protection status rather than assuming defaults are in place, using the PowerShell scripts provided in the Detection and Monitoring section to validate VBS, HVCI, Credential Guard, and LSASS PPL status across their environment.

Conclusion

Windows protected processes represent a critical security boundary that even administrators cannot easily cross. While tools like Process Explorer provide excellent visibility into most processes, protected processes require specialized approaches—either kernel drivers like those used by Process Hacker, or full kernel debugging with WinDbg. This architectural decision by Microsoft fundamentally changed the Windows security model, moving certain protections below the traditional privilege hierarchy where even administrative access cannot override them.

Understanding these protections proves essential across multiple security roles. Security researchers analyzing malware behavior need to understand when and why their analysis tools fail against protected processes, and what techniques malware might use to bypass these protections. System administrators troubleshooting system issues must recognize the difference between legitimate access restrictions and actual problems, avoiding wasted time attempting operations that the kernel will never allow. Red teams assessing organizational security posture require knowledge of protection levels to plan realistic attacks and understand what techniques modern defenses can detect or prevent. Blue teams implementing and validating security controls must verify that protections are actually enabled rather than assuming they're active by default.

The evolution from completely unprotected processes in early Windows versions to the sophisticated PPL and Credential Guard implementations in modern Windows demonstrates Microsoft's ongoing commitment to raising the security bar. Each enhancement forces attackers to invest in more sophisticated techniques—moving from simple user-mode memory reading to kernel exploits, signed driver abuse, and even firmware-level compromises. This arms race continues as defenders harden systems and attackers develop new bypass techniques, making the continuous study of protected processes relevant for anyone involved in Windows security.

References and Further Reading

• Windows Internals, Part 1 (7th Edition) - Pavel Yosifovich, Mark Russinovich, David Solomon, Alex Ionescu
• Sysinternals Process Explorer - Official documentation
• Process Hacker - Open-source advanced process viewer
• Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1 - Alex Ionescu
• Credential Guard Documentation - Microsoft
• WinDbg Documentation - Microsoft

Remember: These techniques should only be used for authorized security research, legitimate penetration testing, or educational purposes. Unauthorized access to computer systems is illegal.