NtFlushVirtualMemory

Prototype

NTSTATUS NtFlushVirtualMemory(
  HANDLE           ProcessHandle,
  PVOID           *BaseAddress,
  PSIZE_T          RegionSize,
  PIO_STATUS_BLOCK IoStatus
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 F4 00 00 00      mov eax, 0xF4      ; Win11 24H2 SSN
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

Undocumented notes

Counterpart to `FlushViewOfFile` for sections backed by a real on-disk file. The kernel walks the PTEs over the requested range, gathers any dirty pages, and issues paging-IO to the underlying file system — for a memory-mapped file this is equivalent to an `fsync` of just the dirty subset. For pagefile-backed or PAGE_NOACCESS regions the call is effectively a no-op. The `IoStatus.Information` field reports the number of bytes actually written.

Common malware usage

Used in persistence and ransomware chains that modify on-disk artifacts via a memory-mapped view rather than `WriteFile`: the attacker maps an executable, INI, scheduled-task XML or LSA Notification Package list with `PAGE_READWRITE`, patches the bytes, and calls `NtFlushVirtualMemory` to force the modification to disk *now* instead of waiting for the lazy writer — important when the next stage (a reboot, a service restart, or an immediate exec) must observe the on-disk change. Also seen in `MiniDumpWriteDump`-style credential-theft chains that map and edit the dump file in place. Some ransomware families touch this call to ensure the encrypted bytes hit the platters before they delete shadow copies and trigger a forced reboot.

Detection opportunities

Sysmon Event 11 (FileCreate) does not fire on a flush — the file already exists. The most reliable telemetry is the ETW `Microsoft-Windows-Kernel-FileIO` `FileIo/OperationEnd` event for `WRITE` operations whose `IrpFlags` indicate paging-IO, correlated to a process that recently obtained a writable section over a sensitive file (executable in `\System32`, scheduled-task XML, `\Registry\Machine\System\CurrentControlSet\Services\*\ImagePath`-backed binary). EDRs that hook `NtCreateSection` against high-value paths and then track subsequent `NtFlushVirtualMemory` against those views catch the in-place patch pattern.

Direct syscall examples

// Persistence helper: patch C:\Windows\System32\target.exe in place.
HANDLE hFile = CreateFileW(L"C:\\Windows\\System32\\target.exe",
    GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ,
    NULL, OPEN_EXISTING, 0, NULL);

HANDLE hMap = CreateFileMappingW(hFile, NULL, PAGE_READWRITE, 0, 0, NULL);
PVOID  view = MapViewOfFile(hMap, FILE_MAP_WRITE, 0, 0, 0);

PatchEntryPoint(view);  // overwrite a few bytes

SIZE_T regionSize = /* SizeOfImage rounded up */ 0;
IO_STATUS_BLOCK iosb;
NTSTATUS s = NtFlushVirtualMemory(
    NtCurrentProcess(),
    &view,
    &regionSize,
    &iosb);
// iosb.Information now holds the number of bytes written back.

; NtFlushVirtualMemory direct stub — SSN 0xF4 on Win11 24H2
NtFlushVirtualMemory PROC
    mov  r10, rcx
    mov  eax, 0F4h
    syscall
    ret
NtFlushVirtualMemory ENDP

use ntapi::ntmmapi::NtFlushVirtualMemory;
use winapi::shared::ntdef::HANDLE;
use winapi::shared::ntdef::PVOID;
use winapi::um::winnt::IO_STATUS_BLOCK;
use std::{mem, ptr::null_mut};

unsafe fn flush(view: PVOID, mut size: usize) -> usize {
    let mut base = view;
    let mut iosb: IO_STATUS_BLOCK = mem::zeroed();
    let s = NtFlushVirtualMemory(
        -1isize as HANDLE,
        &mut base,
        &mut size,
        &mut iosb,
    );
    assert!(s >= 0);
    *iosb.Information() as usize
}

MITRE ATT&CK mappings

• T1547Boot or Logon Autostart Executionmitre ↗
• T1027Obfuscated Files or Informationmitre ↗
• T1106Native APImitre ↗