NtQueryVolumeInformationFile

Prototipo

NTSTATUS NtQueryVolumeInformationFile(
  HANDLE                 FileHandle,
  PIO_STATUS_BLOCK       IoStatusBlock,
  PVOID                  FsInformation,
  ULONG                  Length,
  FS_INFORMATION_CLASS   FsInformationClass
);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Sustenta toda la familia Win32 `GetVolumeInformationW` / `GetDiskFreeSpaceExW` / `GetDriveTypeW`. El kernel enruta el IRP vía `IopXxxControlFile` → `IRP_MJ_QUERY_VOLUME_INFORMATION` al driver de filesystem montado en el device object subyacente al `FileHandle` (NTFS, FAT32, exFAT, ReFS, redirectores de red). La SSN `0x49` es uno de los números más estables de toda la tabla NT — sin cambios desde Windows 10 1507 hasta Win11 24H2 y Server 2025 — porque `Query` y `Set` volume info están bloqueados a nivel ABI desde NT 3.51. Las cinco clases más usadas son: `FileFsVolumeInformation` (etiqueta + serial + fecha de creación), `FileFsLabelInformation` (gemelo write-only), `FileFsSizeInformation` (sectores/clusters/libres), `FileFsDeviceInformation` (`FILE_DEVICE_DISK` vs `FILE_DEVICE_CD_ROM` vs `FILE_DEVICE_NETWORK_FILE_SYSTEM`), y `FileFsAttributeInformation` (nombre del filesystem + flags como `FILE_READ_ONLY_VOLUME`).

Uso común por malware

**Es uno de los syscalls más usados en el ransomware moderno.** LockBit (todas las generaciones 1.0 → 4.0 / Black), BlackCat / ALPHV, Royal, Conti, Hive, Akira y BlackSuit recorren las letras de unidad `A:` a `Z:`, abren cada raíz y emiten `NtQueryVolumeInformationFile(FileFsDeviceInformation)` para saber el tipo de dispositivo — así deciden que `D:` es USB extraíble (cifrar con prioridad y usar plantilla de nota distinta), `Z:` es `FILE_DEVICE_NETWORK_FILE_SYSTEM` (cifrar por SMB — alto impacto, propagación lateral rápida), y `X:` es CD-ROM (saltar). También leen `FileFsAttributeInformation` para detectar `FILE_READ_ONLY_VOLUME` y saltar medios de recuperación / boot de Windows que solo desperdiciarían IO y dispararían SmartScreen. Algunas familias (filtración Conti) fingerprint además `FileFsVolumeInformation::SerialNumber` para deduplicar montajes lógicos que apuntan al mismo volumen físico — evitando doble cifrado de un LUN iSCSI.

Oportunidades de detección

Sysmon no tiene evento para esto; es un syscall Tier-1 usado por Explorer, Defender, APIs de backup y básicamente toda UI de almacenamiento. La detección debe mirar *patrones*: un único proceso emitiendo `NtQueryVolumeInformationFile(FileFsDeviceInformation)` contra más de ~5 handles raíz distintos en segundos, sobre todo seguido de enumeraciones `NtOpenFile` de esas raíces, es la huella canónica de drive-discovery ransomware. Microsoft Defender for Endpoint lo detecta vía el esquema `BehaviorEntities`: un único PID tocando handles raíz marcados `FsRtl` a través de múltiples valores `DeviceType` en 60 s puntúa alto en la regla `Ransomware:Behavior:DriveEnumeration`. El provider ETW `Microsoft-Windows-Kernel-File` evento 12/14 con `IrpFlags & IRP_MJ_QUERY_VOLUME_INFORMATION` da visibilidad a nivel kernel sin depender de hooks user-mode (que el ransomware evade vía syscall directo).

Ejemplos de syscalls directos

; Direct syscall stub for NtQueryVolumeInformationFile (SSN 0x49 across all builds)
NtQueryVolumeInformationFile PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 49h          ; SSN — historically stable, but resolve dynamically anyway
    syscall
    ret
NtQueryVolumeInformationFile ENDP

// Classic LockBit/Conti pattern: probe A: through Z:, classify by DeviceType,
// pick encryption order accordingly. FILE_READ_ATTRIBUTES is enough access.
typedef struct _FILE_FS_DEVICE_INFORMATION {
    ULONG DeviceType;       // FILE_DEVICE_DISK=0x07, _CD_ROM=0x02, _NETWORK_FILE_SYSTEM=0x14
    ULONG Characteristics;  // FILE_REMOVABLE_MEDIA=0x01, FILE_READ_ONLY_DEVICE=0x02, ...
} FILE_FS_DEVICE_INFORMATION;

for (WCHAR d = L'A'; d <= L'Z'; ++d) {
    WCHAR path[] = L"\\??\\X:\\"; path[4] = d;
    UNICODE_STRING us; RtlInitUnicodeString(&us, path);
    OBJECT_ATTRIBUTES oa; InitializeObjectAttributes(&oa, &us, OBJ_CASE_INSENSITIVE, NULL, NULL);
    HANDLE h; IO_STATUS_BLOCK iosb;
    if (!NT_SUCCESS(NtOpenFile(&h, FILE_READ_ATTRIBUTES, &oa, &iosb,
                               FILE_SHARE_READ | FILE_SHARE_WRITE,
                               FILE_DIRECTORY_FILE))) continue;
    FILE_FS_DEVICE_INFORMATION info = { 0 };
    NtQueryVolumeInformationFile(h, &iosb, &info, sizeof(info),
                                 4 /* FileFsDeviceInformation */);
    // info.DeviceType / info.Characteristics now drive encryption strategy.
    NtClose(h);
}

// Cargo: ntapi = "0.4", winapi = { version = "0.3", features = ["ntstatus", "winnt"] }
use ntapi::ntioapi::{NtQueryVolumeInformationFile, IO_STATUS_BLOCK, FileFsAttributeInformation};
use std::mem::MaybeUninit;

#[repr(C)]
struct FileFsAttributeInfo {
    file_system_attributes: u32,      // FILE_READ_ONLY_VOLUME = 0x00080000
    maximum_component_name_length: i32,
    file_system_name_length: u32,
    file_system_name: [u16; 32],
}

unsafe fn is_read_only(h: *mut core::ffi::c_void) -> bool {
    let mut iosb: MaybeUninit<IO_STATUS_BLOCK> = MaybeUninit::uninit();
    let mut info: MaybeUninit<FileFsAttributeInfo> = MaybeUninit::uninit();
    let st = NtQueryVolumeInformationFile(
        h, iosb.as_mut_ptr(), info.as_mut_ptr().cast(),
        core::mem::size_of::<FileFsAttributeInfo>() as u32,
        FileFsAttributeInformation,
    );
    st >= 0 && (info.assume_init().file_system_attributes & 0x0008_0000) != 0
}

Mapeos MITRE ATT&CK

• T1083File and Directory Discoverymitre ↗
• T1486Data Encrypted for Impactmitre ↗
• T1106Native APImitre ↗