NtDebugContinue

Prototype

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

Arguments

Syscall IDs by Windows version

Syscall stub

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

Undocumented notes

The complement of `NtWaitForDebugEvent` — every event returned by the wait must be ack'd or the debuggee thread stays frozen indefinitely. `DBG_CONTINUE` says "I handled this, no exception escapes to the debuggee's SEH"; `DBG_EXCEPTION_NOT_HANDLED` says "let SEH unwind in the debuggee"; the less-known `DBG_REPLY_LATER` (Win10 1607+) defers the ack so a debugger can collect multiple events without freezing intervening threads. The `ClientId` parameter is what makes this thread-granular — a multi-threaded debuggee can have one thread resumed while others stay parked.

Common malware usage

Always paired with `NtWaitForDebugEvent`. In the self-debug anti-attach pattern the loop systematically replies `DBG_CONTINUE` to *every* exception, which makes the debuggee impervious to bog-standard analyst tricks (`int 3` planted in code, `__debugbreak`, `RaiseException(0x80000003)`) — those would normally surface in an attached external debugger but here are swallowed silently by the self-debugger. A more sophisticated variant inspects the event, checks if the exception is one the implant itself raised (e.g. a stego'd `int 3` whose address matches a known anti-debug check) and selectively replies `DBG_CONTINUE` vs `DBG_EXCEPTION_NOT_HANDLED` to make the debuggee believe no debugger is present (the `IsDebuggerPresent`/PEB.BeingDebugged path stays clean because the *external* debugger never attached).

Detection opportunities

`NtDebugContinue` alone is noisy — every running debugger calls it constantly. The detection value is in the parent context: a process that has both `EPROCESS.DebugPort != NULL` and is itself the debugger (its thread holding the debug object handle), where the debuggee is *itself* or a child. Combined with `NtCreateDebugObject` + `NtDebugActiveProcess(NtCurrentProcess())` this is the self-debug anti-attach signature. ETW Microsoft-Windows-Kernel-Process surfaces the debug-port transitions.

Direct syscall examples

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

MITRE ATT&CK mappings

• T1622Debugger Evasionmitre ↗
• T1106Native APImitre ↗