NtFlushProcessWriteBuffers

Prototipo

VOID NtFlushProcessWriteBuffers(VOID);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Notas no documentadas

NtFlushProcessWriteBuffers (wrapper Win32 `FlushProcessWriteBuffers`) no devuelve estado y no toma parámetros. Internamente el kernel envía una interrupción inter-procesador (IPI) a cada CPU sobre la que un hilo del proceso llamante esté actualmente ejecutable, forzando a cada uno a ejecutar una barrera de memoria completa — el truco de la barrera de memoria asimétrica que permite a los algoritmos lock-free del hilo llamante saltarse un `mfence` explícito en la ruta *rápida* y pagar el coste total solo en la rara ruta *lenta*. .NET, Java HotSpot vía sus wrappers nativos y las colas lock-free de alto rendimiento (Boost.Lockfree, concurrentqueue) lo usan todos. El coste es alto — decenas de microsegundos — pero amortizado entre muchas lecturas de ruta rápida.

Uso común por malware

Honestamente, este syscall tiene casi cero señal ofensiva. No asigna, lee, escribe ni toca de otra forma el estado del proceso de modo útil para un atacante. El único abuso teórico es el **canal lateral de timing CPU-bound**: el coste de la IPI es proporcional al número de CPUs ejecutando actualmente hilos del proceso llamante, lo que puede filtrar información gruesa de planificación sobre otros núcleos — pero es académico y no visto en malware real. Un puñado de chequeos anti-debugger oscuros han usado FlushProcessWriteBuffers para detectar single-stepping (el timing IPI cambia bajo debugger hardware), pero es una técnica marginal. No malgaste tiempo de caza en este.

Oportunidades de detección

No es un objetivo útil de detección. El uso legítimo es generalizado (cualquier proceso con runtime .NET, JVM o biblioteca lock-free moderna lo llamará). Los proveedores ETW no exponen este syscall, y no hay callback de kernel que valga la pena hookear. Si se encuentra escribiendo una regla de detección en torno a NtFlushProcessWriteBuffers, probablemente ha ido demasiado lejos — re-priorice.

Ejemplos de syscalls directos

// 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

Mapeos MITRE ATT&CK

• T1106Native APImitre ↗