CVE-2026-62737: Vom Absturz zum laborgestützten SYSTEM

Ein Folgebericht zum ursprünglichen Writeup zu CVE-2026-62737 (ExecutionContext.sys beliebiger indirekter Kernel-Aufruf). Er verwandelt den Crash-PoC in eine funktionierende Token-Tausch-Kette, die cmd.exe als SYSTEM startet, aber nur in einem Labor, in dem ein Debugger Adressen liefert und die ROP-Kette in den Kernel-Speicher schreibt. Dies ist kein eigenständiger Exploit.

Was es tut

1. Öffnet das ExecutionContext-Gerät über den KLoader-Proxy als Benutzer mit niedrigen Rechten.
2. Initialisiert einen ExecutionContext (0x22EC40) und stellt eine Aufgabe (0x22AC54) in die Warteschlange, deren Callback ein Kernel-ROP-Pivot ist.
3. Ein gdb-Skript (patch_rop.py) schreibt eine Token-Tausch-ROP-Kette in ExecutionContext .data und erfasst den RSP/RBP zum Pivot-Zeitpunkt über einen Hardware-Breakpoint.
4. Ein kurzlebiger Watcher-Thread weckt den Kernel-Worker (0x226C5C-Exit-Callback), die Kette tauscht unser Token gegen das von SYSTEM, stellt den Kernel-Stack wieder her und kehrt in den Treiber-Dispatcher zurück, sodass der Worker überlebt.

Dateien

Anforderungen

• Windows 11 25H2 mit Kernel 10.0.26100.8875 (Gadget-RVAs sind buildspezifisch).
• Eine VM mit einem QEMU-gdb-Stub (gdbserver tcp::1234), einem Gast-Agenten und einem gemeinsamen Host/Gast-Ordner, der als Z: gemountet ist.
• Ein Konto mit niedrigen Rechten, das \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535} öffnen kann.
• MinGW-w64 (x86_64-w64-mingw32-gcc) und gdb auf dem Host.

Erstellen

x86_64-w64-mingw32-gcc -O2 -municode -o exploit.exe exploit.c
x86_64-w64-mingw32-gcc -O2 -o modlist.exe modlist.c

Ausführen (bei jedem Start)

1. Frische Basen holen: ./ga.py 'Z:\modlist.exe' (nach dem Kopieren von modlist.exe in den gemeinsamen Ordner)

2. Skripte aktualisieren: ./refresh_bases.sh

3. exploit.exe und modlist.exe in den gemeinsamen Ordner kopieren.

4. Den Exploit als Benutzer mit niedrigen Rechten starten: exploit.exe <nt> <ec> <ec+0x10A00>. Er schreibt seine PID nach Z:\lab_pid.txt und wartet auf Z:\go_lab.txt.

5. gdb anhängen und LAB_PID_FILE auf die Host-Kopie von lab_pid.txt zeigen lassen:

   root@kitploit:~

   LAB_PID_FILE=/path/to/shared/lab_pid.txt \
     gdb -q -ex 'target remote :1234' -ex 'set pagination off' -x patch_rop.py
   

   continue an der gdb-Eingabeaufforderung eingeben.

Offsets (Kernel 26100.8875)

Warum dies kein eigenständiger Exploit ist

• Der Callback läuft in einem Kernel-Systemthread mit System-CR3; ROP im Benutzerspeicher ist unmöglich und es existiert kein MDL-Kernel-Alias.
• Ein echter Exploit benötigt einen Kernel-Adress-Leak (nt/ec) und eine Möglichkeit, die Kette in den Kernel-Speicher zu bekommen. Beides fehlt in diesem Build.
• Der RSP zum Pivot-Zeitpunkt wird von einem gdb-Breakpoint erfasst; ein echter Exploit bräuchte eine stack-residente Kette oder ein RSP-sicherndes Gadget.

Lizenz

MIT, siehe LICENSE.