NtDebugContinue

Prototipo

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

Argumentos

IDs de syscalls por versión de Windows

Stub del 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

Notas no documentadas

El complemento de `NtWaitForDebugEvent` — cada evento devuelto por la espera debe ser acusado o el hilo depurado queda congelado indefinidamente. `DBG_CONTINUE` dice «manejé esto, ninguna excepción escapa al SEH del depurado»; `DBG_EXCEPTION_NOT_HANDLED` dice «deje que SEH desenrolle en el depurado»; el menos conocido `DBG_REPLY_LATER` (Win10 1607+) difiere el acuse para que un depurador pueda recolectar múltiples eventos sin congelar hilos intermedios. El parámetro `ClientId` es lo que da granularidad de hilo — un depurado multi-hilo puede tener un hilo reanudado mientras otros siguen parados.

Uso común por malware

Siempre emparejado con `NtWaitForDebugEvent`. En el patrón anti-attach por auto-depuración el bucle responde sistemáticamente `DBG_CONTINUE` a *cada* excepción, lo que hace al depurado inmune a trucos estándar de analista (`int 3` plantado en código, `__debugbreak`, `RaiseException(0x80000003)`) — estos normalmente aparecerían en un depurador externo adjunto pero aquí son tragados silenciosamente por el auto-depurador. Una variante más sofisticada inspecciona el evento, verifica si la excepción es una que el propio implante lanzó (p. ej. un `int 3` con estego cuya dirección coincide con un anti-debug conocido) y responde selectivamente `DBG_CONTINUE` vs `DBG_EXCEPTION_NOT_HANDLED` para hacer creer al depurado que no hay depurador (la ruta `IsDebuggerPresent`/PEB.BeingDebugged se mantiene limpia porque el depurador *externo* nunca se adjuntó).

Oportunidades de detección

`NtDebugContinue` por sí solo es ruidoso — todo depurador en ejecución lo llama constantemente. El valor de detección está en el contexto padre: un proceso que tiene tanto `EPROCESS.DebugPort != NULL` como es él mismo el depurador (su hilo posee el handle del debug object), donde el depurado es *él mismo* o un hijo. Combinado con `NtCreateDebugObject` + `NtDebugActiveProcess(NtCurrentProcess())` es la firma de anti-attach por auto-depuración. ETW Microsoft-Windows-Kernel-Process eleva las transiciones de debug port.

Ejemplos de syscalls directos

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

Mapeos MITRE ATT&CK

• T1622Debugger Evasionmitre ↗
• T1106Native APImitre ↗