NtAlertThreadByThreadId

Prototype

NTSTATUS NtAlertThreadByThreadId(
  HANDLE ThreadId
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Introduit dans Windows 8 et largement utilisé à partir de Windows 10 comme socle noyau de `WakeByAddressSingle` / `WakeByAddressAll`. Avec `NtWaitForAlertByThreadId`, ce couple implémente des alertes par thread qui *ne* requièrent *pas* d'objet noyau nommé (pas d'Event, pas de Mutex, pas de Sémaphore). L'état de synchronisation est simplement une adresse user-mode que le noyau hache dans une table d'attente par processus ; le noyau n'a besoin que du TID destinataire et n'effectue aucun lookup objet-manager, ce qui rend la voie de dispatch très peu coûteuse. Les Slim Reader/Writer locks, le nouveau `WaitOnAddress` et l'implémentation moderne des variables condition dans ntdll reposent tous sur cette primitive.

Usage courant par les malwares

Synchronisation à faible signal pour sleep-masks, ordonnancement de beacons et pompes de commandes. Comme aucun objet noyau n'est créé ni nommé, il n'y a pas d'artefact `\BaseNamedObjects\…` à exposer pour ProcessHacker / SystemInformer — c'est le principal attrait par rapport à `NtSetEvent` / `NtWaitForSingleObject`. Quelques variantes de sleep-mask dérivées de Cobalt Strike et les backends d'ordonnancement plus récents de Sliver utilisent `WaitOnAddress` (et donc ce syscall) pour parquer les threads workers entre cycles de beacon. À mi-2026, c'est encore un syscall à *faible signal* malveillant : le même chemin est emprunté par tout programme Win32 moderne utilisant SRWLOCK ou std::mutex sous MSVC, le volume légitime noie largement l'usage malicieux.

Opportunités de détection

Quasi indétectable isolément — `NtAlertThreadByThreadId` est appelé par la libération SRWLOCK, le réveil de variable condition et tout déverrouillage `std::mutex` C++17/20 qui trouve un waiter. Les EDR ne le hookent pas, le plancher de bruit est immense. Le seul angle utile est la *combinaison* avec la télémétrie sleep-mask : retours courts et périodiques de NtWaitForAlertByThreadId couplés à NtAlertThreadByThreadId depuis un unique thread non système, dans un processus qui beacone aussi, *plus* une région de code RX-only — là le syscall est un signal corroborant, jamais primaire.

Exemples de syscalls directs

// Replace SetEvent on a globally named event with WaitOnAddress/WakeByAddressSingle
// to avoid creating an object visible to handle-listers.
typedef NTSTATUS(NTAPI* fnNtAlertThreadByThreadId)(HANDLE);

void PokeWorker(DWORD workerTid) {
    HMODULE n = GetModuleHandleA("ntdll.dll");
    fnNtAlertThreadByThreadId p = (fnNtAlertThreadByThreadId)
        GetProcAddress(n, "NtAlertThreadByThreadId");
    p((HANDLE)(ULONG_PTR)workerTid);
}

; SSN 0x71 on win11-24h2 / winserver-2025. 0x70 on most prior 20H2+ builds.
NtAlertThreadByThreadId PROC
    mov  r10, rcx
    mov  eax, 71h
    syscall
    ret
NtAlertThreadByThreadId ENDP

// Wake a worker parked in NtWaitForAlertByThreadId without ever instantiating
// a named kernel object. Useful in implants that want to look like a normal
// Win32 program using SRWLOCK.
use windows_sys::Win32::System::LibraryLoader::{GetModuleHandleA, GetProcAddress};

type NtAlertThreadByThreadId = unsafe extern "system" fn(tid: isize) -> i32;

pub unsafe fn wake_worker(tid: u32) -> i32 {
    let n = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let addr = GetProcAddress(n, b"NtAlertThreadByThreadId\0".as_ptr()).unwrap();
    let f: NtAlertThreadByThreadId = std::mem::transmute(addr);
    f(tid as isize)
}

Mappings MITRE ATT&CK

• T1106Native APImitre ↗
• T1027Obfuscated Files or Informationmitre ↗