NtQueryVolumeInformationFile

Prototyp

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

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Undokumentierte Hinweise

Untermauert die gesamte Win32-Familie `GetVolumeInformationW` / `GetDiskFreeSpaceExW` / `GetDriveTypeW`. Der Kernel leitet das IRP über `IopXxxControlFile` → `IRP_MJ_QUERY_VOLUME_INFORMATION` an den Filesystem-Treiber, der auf dem Device-Object hinter `FileHandle` gemountet ist (NTFS, FAT32, exFAT, ReFS, Network-Redirectoren). Die SSN `0x49` ist eine der langzeitstabilsten Nummern der gesamten NT-Tabelle — unverändert von Windows 10 1507 bis Win11 24H2 und Server 2025 — weil `Query`- und `Set`-Volume-Info seit NT 3.51 ABI-fixiert sind. Die fünf meistgenutzten Klassen sind: `FileFsVolumeInformation` (Label + Seriennummer + Erstellungszeit), `FileFsLabelInformation` (Write-only-Pendant), `FileFsSizeInformation` (Sektoren/Cluster/frei), `FileFsDeviceInformation` (`FILE_DEVICE_DISK` vs. `FILE_DEVICE_CD_ROM` vs. `FILE_DEVICE_NETWORK_FILE_SYSTEM`) und `FileFsAttributeInformation` (Filesystem-Name + Flags wie `FILE_READ_ONLY_VOLUME`).

Häufige Malware-Nutzung

**Dies ist einer der meistgenutzten Syscalls moderner Ransomware.** LockBit (alle Generationen 1.0 → 4.0 / Black), BlackCat / ALPHV, Royal, Conti, Hive, Akira und BlackSuit laufen die Laufwerksbuchstaben `A:` bis `Z:` ab, öffnen jeden Root und rufen `NtQueryVolumeInformationFile(FileFsDeviceInformation)` auf, um den Gerätetyp zu lernen — so entscheiden sie, dass `D:` ein Wechsel-USB ist (mit hoher Priorität verschlüsseln und andere Ransom-Note-Vorlage), `Z:` ein `FILE_DEVICE_NETWORK_FILE_SYSTEM` (via SMB verschlüsseln — hoher Impact, schnelle laterale Verbreitung) und `X:` ein CD-ROM (überspringen). Sie holen außerdem `FileFsAttributeInformation` ab, um `FILE_READ_ONLY_VOLUME` zu erkennen und Windows-Recovery- / Boot-Medien zu überspringen, die nur IO verschwenden und SmartScreen auslösen würden. Einige Familien (Conti-Leak) fingerprinten zusätzlich `FileFsVolumeInformation::SerialNumber`, um logische Mounts auf denselben physischen Volume zu deduplizieren — verhindert die Doppelverschlüsselung eines iSCSI-LUN.

Erkennungs­möglichkeiten

Sysmon hat kein Event hierfür; es ist ein Tier-1-Syscall, den Explorer, Defender, Backup-APIs und im Grunde jedes Storage-UI nutzt. Erkennung muss auf *Muster* schauen: ein einziger Prozess, der `NtQueryVolumeInformationFile(FileFsDeviceInformation)` gegen mehr als ~5 verschiedene Root-Handles innerhalb von Sekunden absetzt, insbesondere gefolgt von `NtOpenFile`-Enumerationen dieser Roots, ist der kanonische Drive-Discovery-Fußabdruck von Ransomware. Microsoft Defender for Endpoint erkennt das über das `BehaviorEntities`-Schema: ein einzelner PID, der `FsRtl`-markierte Root-Handles über mehrere `DeviceType`-Werte in 60 s berührt, scort hoch auf der Regel `Ransomware:Behavior:DriveEnumeration`. ETW-Provider `Microsoft-Windows-Kernel-File` Event 12/14 mit `IrpFlags & IRP_MJ_QUERY_VOLUME_INFORMATION` liefert Kernel-Sicht ohne Abhängigkeit von User-Mode-Hooks (die Ransomware per Direct-Syscall umgeht).

Direkte Syscall-Beispiele

; 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
}

MITRE ATT&CK-Mappings

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