NtPrivilegeCheck

Prototyp

NTSTATUS NtPrivilegeCheck(
  HANDLE         ClientToken,
  PPRIVILEGE_SET RequiredPrivileges,
  PBOOLEAN       Result
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

NtPrivilegeCheck ist das kernelseitige Gegenstück zu AccessCheck: sie fragt „hat dieses Impersonation-Token diese Privilegien aktuell *aktiviert*?". Das übergebene PRIVILEGE_SET trägt ein Control-Feld — PRIVILEGE_SET_ALL_NECESSARY verlangt alle aufgeführten Privilegien, sonst gibt der Kernel TRUE zurück, sobald eines passt. Beim Rückkehren ist in jedem LUID_AND_ATTRIBUTES SE_PRIVILEGE_USED_FOR_ACCESS für die Privilegien gesetzt, die den Check erfüllt haben — das speist die Privilege-Use-Auditierung. Strikt ein *aktiviert*-Check: vorhandene, aber deaktivierte Privilegien gelten als fehlend.

Häufige Malware-Nutzung

Angreifer rufen NtPrivilegeCheck nicht wirklich offensiv auf — sie gewährt nichts, sondern berichtet nur. In Malware taucht sie auf, wenn detektionsbewusste Payloads ihr eigenes Token prüfen, bevor sie eine privilegierte Operation versuchen (z. B. SeDebugPrivilege wirklich aktiv ist, bevor LSASS geöffnet wird), um sonst leise zurückzuziehen. Ehrliche Einschätzung: ein Syscall für legitime Dienste und Verteidiger; als offensives Signal mit geringer Aussagekraft zu behandeln.

Erkennungs­möglichkeiten

NtPrivilegeCheck emittiert selbst keine Privilege-Use-Audit-Events (4674) — diese feuern, wenn eine privilegierte Operation tatsächlich ausgeführt wird. Der nützlichste Blickwinkel liegt im EDR: ntdll!NtPrivilegeCheck hooken und korrelieren „Prozess X hat wiederholt SeDebugPrivilege geprüft, ohne es zu besitzen" (Aufklärung / Capability-Discovery) oder „Prozess X hat SeImpersonatePrivilege geprüft, unmittelbar bevor er ein Token gefälscht hat". Auf einem Domain Controller sind wiederholte Prüfungen auf SeBackupPrivilege/SeRestorePrivilege durch Nicht-Backup-Software auffällig. Allein schwaches Signal; in Ketten brauchbar.

Direkte Syscall-Beispiele

; Direct syscall stub for NtPrivilegeCheck (SSN 0x142 on Win11 24H2 / Server 2025)
NtPrivilegeCheck PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 142h         ; SSN for win11-24h2
    syscall
    ret
NtPrivilegeCheck ENDP

// Defensive *or* offensive recon: only proceed if the token already has SeDebug enabled.
HANDLE hThreadToken = NULL;
NtOpenThreadToken(NtCurrentThread(), TOKEN_QUERY, TRUE, &hThreadToken);
if (!hThreadToken) {
    NtOpenProcessToken(NtCurrentProcess(), TOKEN_QUERY, &hThreadToken);
    // primary token — must duplicate to impersonation before NtPrivilegeCheck
}

LUID seDebug;
LookupPrivilegeValueW(NULL, L"SeDebugPrivilege", &seDebug);

struct {
    DWORD             PrivilegeCount;
    DWORD             Control;
    LUID_AND_ATTRIBUTES Privilege[1];
} req = {
    1,
    PRIVILEGE_SET_ALL_NECESSARY,
    {{ seDebug, SE_PRIVILEGE_ENABLED }}
};

BOOLEAN granted = FALSE;
NtPrivilegeCheck(hThreadToken, (PPRIVILEGE_SET)&req, &granted);
if (granted) {
    // SeDebugPrivilege is enabled — safe to attempt PROCESS_VM_READ on LSASS
}

// Cargo: windows-sys = "0.59"  (Win32_Security)
use std::arch::asm;

#[unsafe(naked)]
unsafe extern "system" fn nt_privilege_check_stub() {
    asm!(
        "mov r10, rcx",
        "mov eax, 0x142",   // Win11 24H2; resolve dynamically for other builds
        "syscall",
        "ret",
        options(noreturn),
    );
}

MITRE ATT&CK-Mappings

• T1106Native APImitre ↗
• T1033System Owner/User Discoverymitre ↗