NtDebugContinue

Prototyp

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

Argumente

Syscall-IDs pro 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

Undokumentierte Hinweise

Das Komplement zu `NtWaitForDebugEvent` — jedes vom Wait gelieferte Event muss bestätigt werden, sonst bleibt der Debuggee-Thread auf unbestimmte Zeit eingefroren. `DBG_CONTINUE` sagt „Ich habe das behandelt, keine Exception entkommt zum SEH des Debuggee"; `DBG_EXCEPTION_NOT_HANDLED` sagt „SEH im Debuggee abwickeln lassen"; das weniger bekannte `DBG_REPLY_LATER` (Win10 1607+) verschiebt den Ack, sodass ein Debugger mehrere Events sammeln kann, ohne zwischenliegende Threads zu blockieren. Der `ClientId`-Parameter macht dies thread-granular — ein Multi-Thread-Debuggee kann einen Thread fortsetzen lassen, während andere geparkt bleiben.

Häufige Malware-Nutzung

Immer mit `NtWaitForDebugEvent` gepaart. Im Self-Debug-Anti-Attach-Muster antwortet die Schleife systematisch `DBG_CONTINUE` auf *jede* Exception, was den Debuggee gegen standardmäßige Analysten-Tricks (`int 3` im Code platziert, `__debugbreak`, `RaiseException(0x80000003)`) immun macht — diese würden normalerweise in einem angehängten externen Debugger auftauchen, werden hier aber lautlos vom Self-Debugger geschluckt. Eine raffiniertere Variante inspiziert das Event, prüft, ob die Exception eine vom Implant selbst ausgelöste ist (z. B. ein stego'd `int 3`, dessen Adresse einer bekannten Anti-Debug-Prüfung entspricht), und antwortet selektiv `DBG_CONTINUE` vs `DBG_EXCEPTION_NOT_HANDLED`, um den Debuggee glauben zu lassen, dass kein Debugger anwesend ist (der `IsDebuggerPresent`/PEB.BeingDebugged-Pfad bleibt sauber, weil der *externe* Debugger nie angehängt hat).

Erkennungs­möglichkeiten

`NtDebugContinue` allein ist laut — jeder laufende Debugger ruft ihn ständig. Der Detection-Wert liegt im Eltern-Kontext: ein Prozess mit `EPROCESS.DebugPort != NULL`, der zugleich selbst der Debugger ist (sein Thread hält das Debug-Object-Handle), wobei der Debuggee *er selbst* oder ein Kind ist. Kombiniert mit `NtCreateDebugObject` + `NtDebugActiveProcess(NtCurrentProcess())` ist das die Self-Debug-Anti-Attach-Signatur. ETW Microsoft-Windows-Kernel-Process zeigt Debug-Port-Übergänge.

Direkte Syscall-Beispiele

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