NtRemoveProcessDebug

Prototyp

NTSTATUS NtRemoveProcessDebug(
  HANDLE ProcessHandle,
  HANDLE DebugObjectHandle
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

4C 8B D1            mov r10, rcx
B8 80 01 00 00      mov eax, 0x180
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

Ruft DbgkpRemoveProcessDebugObject auf: EPROCESS.DebugPort wird geleert, die Pending-Event-Liste des DebugObjects entleert und eingefrorene Threads weiter ausgeführt. Nach Rückkehr ist der Prozess wieder durch einen externen Debugger anhängbar — relevant, wenn Malware den Debug-Port nur *vorübergehend* belegen will und ihn nach Verlassen einer sensiblen Code-Region freigibt. Liefert STATUS_PORT_NOT_SET (0xC000033C), wenn der Prozess nicht durch das angegebene DebugObject debuggt wurde. Im Gegensatz zu NtCreateDebugObject liegt diese SSN im hohen 0x150-0x180-Bereich und wandert mit *jedem* Feature-Update — dynamische Auflösung Pflicht.

Häufige Malware-Nutzung

Zwei Muster. (1) Zeitfenster-Anti-Attach: Den Debug-Port während des Unpackings halten und freigeben, sobald die langlebige C2-Schleife erreicht ist — minimiert die Angriffsfläche für Analysten, solange das Implant ruht. (2) Aufräumen vor Fork-and-Run oder Migration: Der neue Prozess erbt EPROCESS.DebugPort, wenn er unter DEBUG_ONLY_THIS_PROCESS geforkt wurde — der Loader detacht daher explizit, bevor er an das Kind übergibt. Vorwiegend in Runtimes kommerzieller Protectoren (Themida, VMProtect) zu sehen, kaum in Commodity-Cryptern.

Erkennungs­möglichkeiten

Gleicher Provider wie NtDebugActiveProcess: Microsoft-Windows-Threat-Intelligence emittiert ein Event beim Debug-Detach. In legitimer Telemetrie weit seltener als Attach: Detaches durch andere als windbg.exe / vsjitdebugger.exe / devenv.exe / cdb.exe / einen Kernel-Debugger-Relay sind auffällig. Stets mit dem zugehörigen Attach korrelieren — verwaiste Detach-Events ohne vorangehenden Attach können auf Handle-Reuse oder einen Debugger hindeuten, der per NtCreateDebugObject ohne DebugActiveProcess injiziert wurde.

Direkte Syscall-Beispiele

// Once the loader has decrypted and resolved imports, release the debug
// port so long-running operations don't have the burden of servicing the
// DebugObject's event loop. Analysts attaching later will succeed — but by
// then the interesting work has already happened.
typedef NTSTATUS(NTAPI* fnNtRemoveProcessDebug)(HANDLE, HANDLE);

void ReleaseSelfDebug(HANDLE hDebugObject) {
    HMODULE n = GetModuleHandleA("ntdll.dll");
    fnNtRemoveProcessDebug pRemove = (fnNtRemoveProcessDebug)
        GetProcAddress(n, "NtRemoveProcessDebug");
    pRemove((HANDLE)-1 /* self */, hDebugObject);
    CloseHandle(hDebugObject);
}

; SSN 0x180 on win11-24h2 / winserver-2025. Moves on every channel update.
NtRemoveProcessDebug PROC
    mov  r10, rcx
    mov  eax, 180h
    syscall
    ret
NtRemoveProcessDebug ENDP

// Detach our DebugObject before doing a fork-and-run so that the child
// process inherits a clean EPROCESS.DebugPort.
use windows_sys::Win32::System::LibraryLoader::{GetModuleHandleA, GetProcAddress};

type NtRemoveProcessDebug = unsafe extern "system" fn(p: isize, d: isize) -> i32;

pub unsafe fn detach(process: isize, debug_object: isize) -> i32 {
    let n = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let addr = GetProcAddress(n, b"NtRemoveProcessDebug\0".as_ptr()).unwrap();
    let f: NtRemoveProcessDebug = std::mem::transmute(addr);
    f(process, debug_object)
}

MITRE ATT&CK-Mappings

• T1622Debugger Evasionmitre ↗
• T1106Native APImitre ↗