NtFlushProcessWriteBuffers

Prototyp

VOID NtFlushProcessWriteBuffers(VOID);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

NtFlushProcessWriteBuffers (Win32-Wrapper `FlushProcessWriteBuffers`) liefert keinen Status zurück und nimmt keine Parameter. Intern sendet der Kernel einen Inter-Prozessor-Interrupt (IPI) an jede CPU, auf der gerade ein Thread des aufrufenden Prozesses lauffähig ist, und zwingt jede dazu, eine vollständige Speicherbarriere auszuführen — der Asymmetric-Memory-Barrier-Trick, mit dem Lock-Free-Algorithmen im aufrufenden Thread auf dem *schnellen* Pfad ein explizites `mfence` einsparen und die volle Kosten nur auf dem seltenen *langsamen* Pfad zahlen. .NET, Java HotSpot über seine nativen Wrapper sowie hochperformante Lock-Free-Queues (Boost.Lockfree, concurrentqueue) nutzen es alle. Die Kosten sind hoch — Dutzende Mikrosekunden —, werden aber auf viele Fast-Path-Reads amortisiert.

Häufige Malware-Nutzung

Ehrlich gesagt hat dieser Syscall fast kein offensives Signal. Er allokiert, liest, schreibt oder berührt sonst keinen Prozesszustand auf eine für Angreifer nützliche Weise. Der einzige theoretische Missbrauch ist ein **CPU-gebundener Seitenkanal-Timing-Trick**: Die IPI-Kosten sind proportional zur Anzahl CPUs, auf denen gerade Threads des aufrufenden Prozesses laufen — das kann grobe Scheduling-Infos über andere Kerne leaken — ist aber akademisch und in echter Malware nicht zu beobachten. Eine Handvoll obskurer Anti-Debugger-Checks hat FlushProcessWriteBuffers zur Single-Step-Erkennung benutzt (das IPI-Timing ändert sich unter Hardware-Debugger), bleibt aber Randerscheinung. Verschwenden Sie hier keine Jagdzeit.

Erkennungs­möglichkeiten

Kein nützliches Erkennungsziel. Legitime Nutzung ist verbreitet (jeder Prozess mit .NET-Runtime, JVM oder moderner Lock-Free-Bibliothek ruft es auf). ETW-Provider exponieren diesen Syscall nicht, und es gibt keinen Kernel-Callback, dessen Hooking lohnt. Wer sich beim Schreiben einer Detection-Regel rund um NtFlushProcessWriteBuffers wiederfindet, ist wahrscheinlich zu tief — neu priorisieren.

Direkte Syscall-Beispiele

// Fast path: a regular load, no fence.
// Slow path (writer): publish, then NtFlushProcessWriteBuffers to fence every
// reader CPU at once.
#include <windows.h>

static volatile LONG g_seq;

void writer_publish(void) {
    InterlockedIncrement(&g_seq);
    FlushProcessWriteBuffers();   // ntdll!NtFlushProcessWriteBuffers
}

LONG reader_fast(void) {
    return g_seq;   // no mfence — the writer's IPI guarantees ordering.
}

NtFlushProcessWriteBuffers PROC
    mov  r10, rcx
    mov  eax, 0F3h
    syscall
    ret
NtFlushProcessWriteBuffers ENDP

MITRE ATT&CK-Mappings

• T1106Native APImitre ↗