NtLockFile

Prototyp

NTSTATUS NtLockFile(
  HANDLE           FileHandle,
  HANDLE           Event,
  PIO_APC_ROUTINE  ApcRoutine,
  PVOID            ApcContext,
  PIO_STATUS_BLOCK IoStatusBlock,
  PLARGE_INTEGER   ByteOffset,
  PLARGE_INTEGER   Length,
  ULONG            Key,
  BOOLEAN          FailImmediately,
  BOOLEAN          ExclusiveLock
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Byte-Range-Locks sind unter Windows *mandatorisch* (anders als die advisorischen Locks der meisten Unixe): ein fremder Prozess, der einen überlappenden Read/Write versucht, bekommt STATUS_FILE_LOCK_CONFLICT (ERROR_LOCK_VIOLATION 33), selbst wenn er nie zu locken versuchte. Locks werden beim Schließen des Handles freigegeben, aber ein Prozess mit offenem Handle plus exklusivem Lock 0…INT64_MAX verbietet anderen Prozessen effektiv das Lesen. Der Key-Parameter erlaubt einem Owner, viele überlappende Locks zu stacken und per Cookie wieder freizugeben.

Häufige Malware-Nutzung

Zwei klar getrennte Missbräuche. (1) **Anti-Analysis-Selbst-Lock**: der Implant öffnet seine eigene Datei mit entferntem FILE_SHARE_READ und setzt einen exklusiven Lock über den gesamten Bereich. AV-Scanner, die die Datei für statischen Signaturabgleich lesen wollen, treffen ERROR_LOCK_VIOLATION; viele naive Scanner loggen und überspringen. In Kombination mit der Lock-on-Execute-Eigenschaft von FILE_EXECUTE-Handles macht das in-place-Delete unmöglich, bis der Prozess endet. (2) **Ransomware-UX-Manipulation**: Encryptor setzen exklusive Locks auf die Ransom-Note während der Verschlüsselungsphase, sodass das Opfer die Note nicht beiseiteschieben kann; nach Abschluss der Verschlüsselung wird der Lock freigegeben und die Note wird sichtbar/änderbar. Manche Wiper sperren auch die MFT-äquivalente Metadaten-Datei, um Recovery-Tools auszubremsen.

Erkennungs­möglichkeiten

NtLockFile ist *hochvolumig* — jedes Office-Dokument, jede SQLite-DB, jedes Outlook-PST und jedes Git-Pack nutzt es permanent. Sinnvolle Filter: Locks auf ausführbaren Dateien (.exe/.dll/.scr) durch den *selben* Prozess, der die Datei geöffnet hat, sind außerhalb von Debuggern ungewöhnlich. ETW Microsoft-Windows-Kernel-FileIO liefert FileIo/OperationEnd mit Lock/Unlock-Subtypes, ist aber laut. Die am besten umsetzbare Telemetrie ist die *Fehlerseite*: ein Anstieg von ERROR_LOCK_VIOLATION (33) bei legitimen Scannern ist ein indirektes Signal, dass sich etwas selbst sperrt. EDR-Minifilter können IRP_MJ_LOCK_CONTROL direkt beobachten und mit dem sperrenden Prozess-Image korrelieren.

Direkte Syscall-Beispiele

// Re-open our own image without FILE_SHARE_READ, then take a whole-file
// exclusive lock. AV scanners that try to read it for static signature
// matching hit STATUS_FILE_LOCK_CONFLICT and move on.
HANDLE hSelf = CreateFileW(g_selfPath,
    GENERIC_READ, 0 /* no share */, NULL,
    OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

IO_STATUS_BLOCK iosb;
LARGE_INTEGER off = { .QuadPart = 0 };
LARGE_INTEGER len = { .QuadPart = 0x7FFFFFFFFFFFFFFFLL };

NtLockFile(hSelf, NULL, NULL, NULL, &iosb,
           &off, &len, 0,
           TRUE,    // FailImmediately
           TRUE);   // ExclusiveLock

NtLockFile PROC
    mov  r10, rcx
    mov  eax, 114h
    syscall
    ret
NtLockFile ENDP

// Cargo: ntapi = "0.4", windows-sys = "0.59"
// Hold an exclusive lock on the note while we burn through the file tree.
unsafe {
    let off: i64 = 0;
    let len: i64 = i64::MAX;
    let mut iosb = zeroed();
    let st = NtLockFile(h_note,
        null_mut(), None, null_mut(),
        &mut iosb,
        &off as *const _ as _, &len as *const _ as _,
        0,
        1,  // FailImmediately
        1); // ExclusiveLock
    assert!(st == 0);
}
// ...encrypt files...
unsafe { NtUnlockFile(h_note, &mut iosb, &off as *const _ as _, &len as *const _ as _, 0); }

MITRE ATT&CK-Mappings

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