NtWaitForAlertByThreadId

Prototyp

NTSTATUS NtWaitForAlertByThreadId(
  PVOID          Address,
  PLARGE_INTEGER Timeout
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Gegenstück zu `NtAlertThreadByThreadId`. Das `Address`-Argument wird vom Kernel *nicht* dereferenziert — es ist nur ein Hash-Schlüssel, der in die Wait-Table des EPROCESS (KiWaitChainList / RtlpHashAddress) gehasht wird. Wenn `NtAlertThreadByThreadId` mit der passenden TID aufgerufen wird, durchsucht der Kernel den Bucket, findet den passenden Thread und signalisiert ihn. Das adress-basierte Hashing ermöglicht die billige, objektlose Semantik von `WaitOnAddress`. Der SSN-Bereich (0x1B3 → 0x1E3) gehört zu den volatilsten in ntoskrnl — er verschiebt sich fast bei jedem Feature-Update, weil er am Ende der SST sitzt und die Tabelle dahinter wächst.

Häufige Malware-Nutzung

Genutzt von modernen Sleep-Mask-Implementierungen (Ekko-artig und Nachfolger), die eine Wait-Primitive *ohne* Event-/Mutex-Objekt-Backing möchten. Den schlafenden Beacon-Thread mit langem Timeout in diesem Syscall parken; mit `NtAlertThreadByThreadId` wecken, wenn Arbeit kommt. Kein `\BaseNamedObjects\…`-Eintrag, kein Handle in der Handle-View von System Informer, kein `Microsoft-Windows-Kernel-Object`-ETW-Event für Erzeugung. Kombiniert mit `WaitOnAddress`-artigem Polling auf ein Status-Wort kann sich der Implant als jeder moderne Win32-Prozess mit SRWLOCK oder den neuen std::mutex-Internals tarnen. Die legitime Last macht es zum schlechten Primärziel — und damit für Autoren attraktiv.

Erkennungs­möglichkeiten

Microsoft-Windows-Threat-Intelligence emittiert kein Per-Call-Event. Die einzig realistische Anomalie ist *Frequenz × Kontext*: ein Thread, der die meiste Zeit in `NtWaitForAlertByThreadId` mit nicht-NULL relativem Timeout verbringt, in einem Prozess mit Netzwerk-Egress, RX-only-Mapping, gestartet von einem Child von explorer.exe oder einer Office-App. Memory-Scanner (Moneta, Hunt-Sleeping-Beacons) finden die umliegende RX-Region; der Syscall ist nur Kolorit. EDRs flaggen mitunter ungewöhnliche Call-Site-Muster (Alert/Wait aus Nicht-System-DLL), aber False-Positive-Raten sind hoch, weil moderne C++-Runtimes denselben Pfad nehmen.

Direkte Syscall-Beispiele

// Park a worker thread until a partner calls NtAlertThreadByThreadId
// with our TID. No event handle ever exists.
typedef NTSTATUS(NTAPI* fnWait)(PVOID, PLARGE_INTEGER);

void ParkWorker(volatile LONG* statusWord, ULONGLONG ns100) {
    HMODULE n = GetModuleHandleA("ntdll.dll");
    fnWait p = (fnWait)GetProcAddress(n, "NtWaitForAlertByThreadId");
    LARGE_INTEGER t;
    t.QuadPart = -(LONGLONG)ns100; // relative timeout
    p((PVOID)statusWord, &t);
}

; SSN 0x1E3 on win11-24h2 / winserver-2025. Moves on nearly every feature update.
NtWaitForAlertByThreadId PROC
    mov  r10, rcx
    mov  eax, 1E3h
    syscall
    ret
NtWaitForAlertByThreadId ENDP

// Park between beacon cycles using the address of a status word as hash key.
use windows_sys::Win32::System::LibraryLoader::{GetModuleHandleA, GetProcAddress};

type NtWaitForAlertByThreadId = unsafe extern "system" fn(addr: *mut u8, to: *mut i64) -> i32;

pub unsafe fn park(status: *mut u32, hundred_ns: i64) -> i32 {
    let n = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let addr = GetProcAddress(n, b"NtWaitForAlertByThreadId\0".as_ptr()).unwrap();
    let f: NtWaitForAlertByThreadId = std::mem::transmute(addr);
    let mut t: i64 = -hundred_ns;
    f(status as *mut u8, &mut t)
}

MITRE ATT&CK-Mappings

• T1106Native APImitre ↗
• T1027Obfuscated Files or Informationmitre ↗