NtWaitForDebugEvent
Attend le prochain événement de débogage délivré à un debug object et retourne un DBGUI_WAIT_STATE_CHANGE.
Prototype
NTSTATUS NtWaitForDebugEvent( HANDLE DebugObjectHandle, BOOLEAN Alertable, PLARGE_INTEGER Timeout, PDBGUI_WAIT_STATE_CHANGE StateChange );
Arguments
| Name | Type | Dir | Description |
|---|---|---|---|
| DebugObjectHandle | HANDLE | in | Handle vers un debug object obtenu via NtCreateDebugObject (ou DebugActiveProcess). |
| Alertable | BOOLEAN | in | Si TRUE, l'attente peut être interrompue par des APC user-mode (retourne STATUS_USER_APC). |
| Timeout | PLARGE_INTEGER | in | Timeout optionnel (unités de 100 ns, négatif = relatif). NULL attend indéfiniment. |
| StateChange | PDBGUI_WAIT_STATE_CHANGE | out | Reçoit l'événement : NewState (CREATE_PROCESS/EXCEPTION/etc.), AppClientId et union payload par événement. |
IDs de syscalls par version de Windows
| Version de Windows | ID de syscall | Build |
|---|---|---|
| Win10 1507 | 0x1B4 | win10-1507 |
| Win10 1607 | 0x1BD | win10-1607 |
| Win10 1703 | 0x1C3 | win10-1703 |
| Win10 1709 | 0x1C7 | win10-1709 |
| Win10 1803 | 0x1C9 | win10-1803 |
| Win10 1809 | 0x1CA | win10-1809 |
| Win10 1903 | 0x1CB | win10-1903 |
| Win10 1909 | 0x1CB | win10-1909 |
| Win10 2004 | 0x1D1 | win10-2004 |
| Win10 20H2 | 0x1D1 | win10-20h2 |
| Win10 21H1 | 0x1D1 | win10-21h1 |
| Win10 21H2 | 0x1D3 | win10-21h2 |
| Win10 22H2 | 0x1D3 | win10-22h2 |
| Win11 21H2 | 0x1DD | win11-21h2 |
| Win11 22H2 | 0x1E1 | win11-22h2 |
| Win11 23H2 | 0x1E1 | win11-23h2 |
| Win11 24H2 | 0x1E4 | win11-24h2 |
| Server 2016 | 0x1BD | winserver-2016 |
| Server 2019 | 0x1CA | winserver-2019 |
| Server 2022 | 0x1D9 | winserver-2022 |
| Server 2025 | 0x1E4 | winserver-2025 |
Module noyau
APIs liées
Stub du syscall
4C 8B D1 mov r10, rcx B8 E4 01 00 00 mov eax, 0x1E4 ; Win11 24H2 SSN F6 04 25 08 03 FE 7F 01 test byte ptr [0x7FFE0308], 1 75 03 jne short +3 0F 05 syscall C3 ret CD 2E int 2Eh C3 ret
Notes non documentées
La primitive côté noyau située sous `WaitForDebugEventEx`. Un débogueur s'attache en créant (ou ouvrant) un debug object avec `NtCreateDebugObject` et en le liant à un processus cible via `NtDebugActiveProcess`, puis boucle sur `NtWaitForDebugEvent` pour recevoir les changements d'état canoniques : `DbgCreateProcessStateChange`, `DbgCreateThreadStateChange`, `DbgLoadDllStateChange`, `DbgExceptionStateChange` (le plus important — breakpoint, single-step, access violation), `DbgExitThreadStateChange`, `DbgExitProcessStateChange`, `DbgUnloadDllStateChange`. Chaque événement doit être acquitté par `NtDebugContinue`. L'union `DBGUI_WAIT_STATE_CHANGE` transporte des données spécifiques à l'événement — un CONTEXT pour les exceptions, base d'image/nom pour les chargements de module, codes de sortie, etc.
Usage courant par les malwares
Deux formes offensives distinctes. (1) **Anti-attach par auto-débogage** : le processus crée un debug object, l'attache à lui-même (ou à un enfant qu'il lance), et boucle sur `NtWaitForDebugEvent` depuis un thread worker dédié. Comme Windows n'autorise qu'un seul débogueur par processus, un `windbg`/`x64dbg` externe ne peut plus s'attacher — son `DebugActiveProcess` échoue avec `STATUS_PORT_ALREADY_SET`. Des packers comme Themida et quelques crypters livrent des variantes de ceci. (2) **Débogueur headless** pour instrumenter un enfant sans lancer d'UI visible — utile pour un malware qui doit stepper du code déballé ou réagir à des exceptions spécifiques dans un autre binaire. À l'inverse, les outils anti-anti-debug (TitanHide, ScyllaHide) utilisent les mêmes primitives pour maintenir la boucle de debug vivante tout en filtrant les événements visibles à l'analyste.
Opportunités de détection
`NtCreateDebugObject` suivi rapidement de `NtDebugActiveProcess(soi_ou_enfant)` et d'un thread garé dans `NtWaitForDebugEvent` est l'empreinte canonique. ETW Microsoft-Windows-Kernel-Process émet des événements de set de debug port. Le champ `EPROCESS.DebugPort` devenant non-NULL sur un processus qui n'est pas un outil de développeur est très signalisant — les callbacks noyau via `PsSetCreateProcessNotifyRoutineEx2` et les protections process-protégé des EDR capturent ça. Depuis user mode, `NtQueryInformationProcess` avec `ProcessDebugPort`/`ProcessDebugObjectHandle` révèle l'attachement, raison pour laquelle les packers gèlent ce chemin par détournements de hook.
Exemples de syscalls directs
cSelf-debug anti-attach worker thread
// Run in a dedicated thread spawned at startup. After this returns,
// no external debugger can attach until the debug object handle is closed.
DWORD WINAPI SelfDebugLoop(LPVOID arg) {
HANDLE hDbg = NULL;
OBJECT_ATTRIBUTES oa = { sizeof(oa) };
NTSTATUS st = NtCreateDebugObject(&hDbg, DEBUG_ALL_ACCESS, &oa, 0);
if (!NT_SUCCESS(st)) return st;
// Attach to ourselves — blocks future DebugActiveProcess() from any other tool.
st = NtDebugActiveProcess(NtCurrentProcess(), hDbg);
if (!NT_SUCCESS(st)) return st;
DBGUI_WAIT_STATE_CHANGE sc;
for (;;) {
st = NtWaitForDebugEvent(hDbg, FALSE, NULL, &sc);
if (!NT_SUCCESS(st)) break;
// Pass everything through so the debuggee keeps running.
NtDebugContinue(hDbg, &sc.AppClientId, DBG_CONTINUE);
}
return 0;
}asmx64 direct stub
; NtWaitForDebugEvent direct syscall (Win11 24H2 SSN 0x1E4)
NtWaitForDebugEvent PROC
mov r10, rcx
mov eax, 1E4h
syscall
ret
NtWaitForDebugEvent ENDPrustMinimal headless debug loop
// Cargo: windows-sys = "0.59"
use windows_sys::Win32::Foundation::HANDLE;
use windows_sys::Win32::System::LibraryLoader::*;
type WaitFn = unsafe extern "system" fn(HANDLE, u8, *const i64, *mut [u8; 0xD8]) -> i32;
type ContFn = unsafe extern "system" fn(HANDLE, *const [usize; 2], i32) -> i32;
unsafe fn drain(dbg: HANDLE) {
let nt = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
let wait: WaitFn = std::mem::transmute(
GetProcAddress(nt, b"NtWaitForDebugEvent\0".as_ptr()).unwrap());
let cont: ContFn = std::mem::transmute(
GetProcAddress(nt, b"NtDebugContinue\0".as_ptr()).unwrap());
let mut sc = [0u8; 0xD8];
loop {
if wait(dbg, 0, std::ptr::null(), &mut sc) < 0 { break; }
let cid_ptr = sc.as_ptr().add(8) as *const [usize; 2]; // AppClientId
// 0x00010002 = DBG_CONTINUE
cont(dbg, cid_ptr, 0x00010002);
}
}Mappings MITRE ATT&CK
Last verified: 2026-05-20