NtRemoveProcessDebug

Prototype

NTSTATUS NtRemoveProcessDebug(
  HANDLE ProcessHandle,
  HANDLE DebugObjectHandle
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

Appelle DbgkpRemoveProcessDebugObject, qui efface EPROCESS.DebugPort, vide la liste d'événements en attente du DebugObject et reprend les threads gelés. Au retour, le processus redevient attaquable par un débogueur externe — utile quand un malware veut *temporairement* occuper le port de debug puis le libérer une fois la région sensible exécutée. Renvoie STATUS_PORT_NOT_SET (0xC000033C) si le processus n'était pas débogué par le DebugObject fourni. Contrairement à NtCreateDebugObject, ce SSN se trouve dans la plage haute 0x150-0x180 et bouge à *chaque* mise à jour majeure — résolution dynamique obligatoire.

Usage courant par les malwares

Deux patterns. (1) Anti-attach fenêtré : occuper le port de debug pendant l'unpacking, puis libérer une fois la boucle C2 longue-durée atteinte — minimise la surface offerte aux analystes quand l'implant est en sommeil. (2) Nettoyage avant fork-and-run ou migration : le nouveau processus hérite d'EPROCESS.DebugPort si fork sous DEBUG_ONLY_THIS_PROCESS, donc le loader détache explicitement avant de céder la main à l'enfant. Surtout dans les runtimes de protecteurs commerciaux (Themida, VMProtect), peu chez les crypters grand public.

Opportunités de détection

Même provider que NtDebugActiveProcess : Microsoft-Windows-Threat-Intelligence lève un événement pour le detach debug. Beaucoup plus rare en télémétrie légitime que l'attach : les détachements émis par autre chose que windbg.exe / vsjitdebugger.exe / devenv.exe / cdb.exe / un relais kernel-debugger sont notables. Toujours corréler avec l'attach correspondant — des détachements orphelins sans attach préalable peuvent indiquer de la réutilisation de handle ou un débogueur qui s'est injecté via NtCreateDebugObject directement, sans DebugActiveProcess.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1622Debugger Evasionmitre ↗
• T1106Native APImitre ↗