NtFlushKey

Prototyp

NTSTATUS NtFlushKey(
  HANDLE  KeyHandle
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

NtFlushKey committet alle In-Memory-Änderungen für die *Hive*, die den übergebenen Schlüssel enthält, in deren Backing-Datei. Trotz der Pro-Schlüssel-Signatur flusht der Kernel die gesamte Hive — der Configuration Manager hält keine Dirty-Bits pro Schlüssel auf Flush-Granularität. Unterschied zu `NtFlushBuffersFile`: Letzteres adressiert eine Datei via FILE_OBJECT, NtFlushKey adressiert eine Hive via Key-Handle. Win32-Wrapper ist `RegFlushKey`. Der Lazy-Flusher schreibt dirty hives normalerweise alle fünf Sekunden (`CmpLazyFlushIntervalInSeconds`); NtFlushKey erzwingt das sofortige Zurückschreiben.

Häufige Malware-Nutzung

Das Hauptmissbrauchsmuster ist **Anti-Forensik rund um Persistenz**: Nach dem Schreiben einer Run-Key, Scheduled-Task-Konfiguration, eines Service-Eintrags oder COM-Hijack-Werts ruft Malware NtFlushKey auf, um die Änderung *vor* dem nächsten unsauberen Reboot auf die Platte zu garantieren — wichtig, wenn das Lazy-Flush-Fenster breiter ist als das erwartete Gelegenheitsfenster (BSOD-auslösender Exploit, geplanter Hardreset, host-tötende Ransomware). Sekundäres Muster: Manche Dropper flushen einen frisch geschriebenen Autorun-Eintrag und löschen unmittelbar danach die referenzierte Binary auf der Platte, sodass Run-Key-Metadaten auf Inhalte zeigen, die beim Boot möglicherweise nicht mehr existieren — eine kleine Anti-Analyse-Lästigkeit.

Erkennungs­möglichkeiten

Für sich ist NtFlushKey uninteressant — explorer.exe und viele Treiber rufen ihn routinemäßig auf. Das nützliche Signal ist die *Sequenz*: Sysmon Event 13 (Registry-Value-Set) auf einem bekannten Persistenz-Schlüssel, unmittelbar gefolgt von einem Flush aus derselben PID, besonders wenn diese PID unsigniert oder frisch erzeugt ist. ETW `Microsoft-Windows-Kernel-Registry` liefert Flush-Events mit Key-Pfad und PID. Mit Sysmon Event 11 (File Create / Delete) für die referenzierte Persistenz-Binary korrelieren.

Direkte Syscall-Beispiele

; Direct syscall stub for NtFlushKey (SSN 0xF2 on Win11 24H2 — drifts per build)
NtFlushKey PROC
    mov  r10, rcx          ; KeyHandle
    mov  eax, 0F2h         ; SSN
    syscall
    ret
NtFlushKey ENDP

// Write a Run key and immediately flush — defeats lazy-flush race on hard reboot.
#include <windows.h>

LONG PersistAndFlush(LPCWSTR name, LPCWSTR cmd) {
    HKEY hRun = NULL;
    LONG s = RegCreateKeyExW(HKEY_CURRENT_USER,
        L"Software\\Microsoft\\Windows\\CurrentVersion\\Run",
        0, NULL, 0, KEY_SET_VALUE, NULL, &hRun, NULL);
    if (s != ERROR_SUCCESS) return s;
    s = RegSetValueExW(hRun, name, 0, REG_SZ,
                       (const BYTE*)cmd,
                       (DWORD)((wcslen(cmd) + 1) * sizeof(WCHAR)));
    if (s == ERROR_SUCCESS) RegFlushKey(hRun);   // ← NtFlushKey under the hood
    RegCloseKey(hRun);
    return s;
}

// Cargo: ntapi = "0.4"
use ntapi::ntregapi::NtFlushKey;
use winapi::shared::ntdef::{HANDLE, NTSTATUS};

unsafe fn flush(key: HANDLE) -> NTSTATUS {
    NtFlushKey(key)
}

MITRE ATT&CK-Mappings

• T1547.001Registry Run Keys / Startup Foldermitre ↗
• T1112Modify Registrymitre ↗
• T1106Native APImitre ↗