NtUnlockFile

Prototype

NTSTATUS NtUnlockFile(
  HANDLE           FileHandle,
  PIO_STATUS_BLOCK IoStatusBlock,
  PLARGE_INTEGER   ByteOffset,
  PLARGE_INTEGER   Length,
  ULONG            Key
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

Miroir de NtLockFile. La plage à débloquer doit *exactement* correspondre à une plage précédemment acquise — pas de déblocage de chevauchement partiel, pas de raccourci « tout débloquer ». Un appel avec une plage non-correspondante renvoie STATUS_RANGE_NOT_LOCKED. Les verrous sont aussi libérés implicitement à la fermeture du FileHandle (NtClose), c'est ainsi que se passe presque toute libération légitime — NtUnlockFile explicite est surtout utilisé par les moteurs de base de données long-running et Office qui libèrent des verrous par enregistrement en gardant le fichier ouvert.

Usage courant par les malwares

Seul, NtUnlockFile est peu intéressant — c'est juste la moitié nettoyage d'un abus de NtLockFile. En pratique il apparaît comme étape finale de deux motifs : (a) le stub anti-analyse auto-verrouillé déverrouille avant de sortir pour qu'un désinstalleur / updater puisse réécrire le binaire proprement, et (b) un rançongiciel qui a verrouillé sa note pendant le chiffrement déverrouille une fois la phase de chiffrement terminée pour que la victime puisse la lire. Signal honnête : il n'existe quasiment aucun rapport public faisant de NtUnlockFile un IOC discriminant par lui-même, et la plupart des rançongiciels sautent le déverrouillage explicite et se contentent de fermer le handle.

Opportunités de détection

Profil de volume et histoire de détection identiques à NtLockFile — même fournisseur ETW, même point de hook minifilter FltMgr (IRP_MJ_LOCK_CONTROL couvre lock et unlock). La valeur blue-team d'alertes NtUnlockFile est faible ; la valeur est dans la *corrélation* avec un NtLockFile précédent sur une cible sensible. Les EDR qui alertent déjà sur l'événement lock ne gagnent pas grand-chose à alerter aussi sur l'unlock. À suivre lors d'investigations post-incident rançongiciel : une rafale soudaine de NtUnlockFile contre de nombreux handles de documents utilisateur corrèle avec la fin de la passe de chiffrement.

Exemples de syscalls directs

// Pair-of-pair: matches the NtLockFile call that took the whole-file lock.
IO_STATUS_BLOCK iosb;
LARGE_INTEGER off = { .QuadPart = 0 };
LARGE_INTEGER len = { .QuadPart = 0x7FFFFFFFFFFFFFFFLL };

NTSTATUS st = NtUnlockFile(hSelf, &iosb, &off, &len, 0);
if (st == STATUS_RANGE_NOT_LOCKED) {
    // Some other code already unlocked it (or the offsets don't match).
}

NtUnlockFile PROC
    mov  r10, rcx
    mov  eax, 1DDh
    syscall
    ret
NtUnlockFile ENDP

// Cargo: ntapi = "0.4"
unsafe {
    let off: i64 = 0;
    let len: i64 = i64::MAX;
    let mut iosb = zeroed();
    let st = NtUnlockFile(h_note,
        &mut iosb,
        &off as *const _ as _,
        &len as *const _ as _,
        0);
    // STATUS_RANGE_NOT_LOCKED is benign here — handle close would have done it anyway.
    let _ = st;
}

Mappings MITRE ATT&CK

• T1497Virtualization/Sandbox Evasionmitre ↗
• T1486Data Encrypted for Impactmitre ↗
• T1106Native APImitre ↗