NtDebugContinue

Prototype

NTSTATUS NtDebugContinue(
  HANDLE     DebugObjectHandle,
  PCLIENT_ID DebuggeeId,
  NTSTATUS   ContinueStatus
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

4C 8B D1            mov r10, rcx
B8 D7 00 00 00      mov eax, 0xD7      ; 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

Le complément de `NtWaitForDebugEvent` — chaque événement renvoyé par l'attente doit être acquitté ou le thread débogué reste gelé indéfiniment. `DBG_CONTINUE` dit « j'ai géré ceci, aucune exception ne s'échappe vers le SEH du débogué » ; `DBG_EXCEPTION_NOT_HANDLED` dit « laissez SEH dérouler dans le débogué » ; le moins connu `DBG_REPLY_LATER` (Win10 1607+) diffère l'ack pour qu'un débogueur puisse collecter plusieurs événements sans geler les threads intermédiaires. Le paramètre `ClientId` est ce qui rend cela à granularité thread — un débogué multi-thread peut avoir un thread repris pendant que d'autres restent à l'arrêt.

Usage courant par les malwares

Toujours apparié à `NtWaitForDebugEvent`. Dans le pattern anti-attach par auto-débogage, la boucle répond systématiquement `DBG_CONTINUE` à *chaque* exception, rendant le débogué imperméable aux astuces standards d'analyste (`int 3` planté dans le code, `__debugbreak`, `RaiseException(0x80000003)`) — celles-ci remonteraient normalement dans un débogueur externe attaché mais sont ici avalées silencieusement par l'auto-débogueur. Une variante plus sophistiquée inspecte l'événement, vérifie si l'exception est l'une que l'implant lui-même a levée (ex. un `int 3` stégano dont l'adresse correspond à un anti-debug connu) et répond sélectivement `DBG_CONTINUE` vs `DBG_EXCEPTION_NOT_HANDLED` pour faire croire au débogué qu'aucun débogueur n'est présent (le chemin `IsDebuggerPresent`/PEB.BeingDebugged reste propre car le débogueur *externe* ne s'est jamais attaché).

Opportunités de détection

`NtDebugContinue` seul est bruyant — tout débogueur en cours d'exécution l'appelle constamment. La valeur de détection est dans le contexte parent : un processus qui a à la fois `EPROCESS.DebugPort != NULL` et est lui-même le débogueur (son thread détenant le handle du debug object), où le débogué est *lui-même* ou un enfant. Combiné à `NtCreateDebugObject` + `NtDebugActiveProcess(NtCurrentProcess())` c'est la signature anti-attach par auto-débogage. ETW Microsoft-Windows-Kernel-Process fait remonter les transitions de debug port.

Exemples de syscalls directs

// Inside the self-debug loop, after NtWaitForDebugEvent returned `sc`.
NTSTATUS status = (sc.NewState == DbgExceptionStateChange)
    ? DBG_CONTINUE                  // swallow ALL exceptions silently
    : DBG_CONTINUE;                 // and pass non-exception events through

NtDebugContinue(hDbg, &sc.AppClientId, status);

// Only swallow our own planted int3s; let other exceptions surface to the debuggee.
if (sc.NewState == DbgExceptionStateChange) {
    PVOID pc = (PVOID)sc.StateInfo.Exception.ExceptionRecord.ExceptionAddress;
    NTSTATUS code = sc.StateInfo.Exception.ExceptionRecord.ExceptionCode;

    NTSTATUS reply;
    if (code == STATUS_BREAKPOINT && IsOurAntiDebugProbe(pc)) {
        reply = DBG_CONTINUE;                  // hide it from any SEH check
    } else {
        reply = DBG_EXCEPTION_NOT_HANDLED;     // let the debuggee see/handle it
    }
    NtDebugContinue(hDbg, &sc.AppClientId, reply);
} else {
    NtDebugContinue(hDbg, &sc.AppClientId, DBG_CONTINUE);
}

; NtDebugContinue direct syscall (Win11 24H2 SSN 0xD7)
NtDebugContinue PROC
    mov  r10, rcx
    mov  eax, 0D7h
    syscall
    ret
NtDebugContinue ENDP

Mappings MITRE ATT&CK

• T1622Debugger Evasionmitre ↗
• T1106Native APImitre ↗