NtDeleteFile

Prototyp

NTSTATUS NtDeleteFile(
  POBJECT_ATTRIBUTES  ObjectAttributes
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

NtDeleteFile ist die seltene pfadbasierte Lösch-Primitive: Statt eine Datei mit `DELETE`-Zugriff zu öffnen und dann `NtSetInformationFile` mit `FileDispositionInformation` zu setzen, erledigt sie beides atomar aus einem einzigen Pfad-Argument. Kein Win32-Wrapper nutzt sie direkt — `DeleteFileW` läuft stets über `NtOpenFile` + `FileDispositionInformation`, und `SHFileOperation` (im Shell-Kontext) fügt weitere Schichten inkl. Papierkorb-Handling ein. Ein Aufruf von NtDeleteFile ist daher *für sich genommen eine Signatur*: legitime Software nutzt sie kaum je.

Häufige Malware-Nutzung

NtDeleteFile wird in **Indicator-Removal**-Ketten bevorzugt, weil sie sowohl `kernel32!DeleteFileW` (häufig von User-Mode-EDRs gehookt) als auch die Papierkorb-Umleitung der Shell überspringt. Ransomware-Familien, die eigene Dropper und Staging-Logs wischen (LockBit 3.0, Conti, BlackCat/ALPHV), und Loader, die sich nach Übergabe an eine persistierte Kopie selbst löschen, wählen diese Primitive gelegentlich gezielt wegen der Bypass-Eigenschaft. Hinweis: `NtDeleteFile` schlägt noch immer fehl bei Dateien mit offenen Handles anderer Prozesse, sofern diese nicht mit `FILE_SHARE_DELETE` geöffnet wurden — dafür ist die `Posix-Delete`-Variante von `FileDispositionInformationEx` vorzuziehen.

Erkennungs­möglichkeiten

Da legitime Nutzung extrem selten ist, ist *jeder* Aufruf von NtDeleteFile hochaussagekräftig. Kernel-Mini-Filter sehen Löschungen über `IRP_MJ_SET_INFORMATION` mit `FileDispositionInformation`, unabhängig davon, ob der ursprüngliche Syscall NtDeleteFile oder NtSetInformationFile war — die IRP-Ebene normalisiert. ETW `Microsoft-Windows-Kernel-File` liefert ein Delete-Event, das am FILE_OBJECT hängt. Sysmon Event 23 (FileDelete mit Archivierung) und Event 26 (FileDeleteDetected, ohne Archiv) sind die primären Host-Indikatoren; das Archiv-Capture ist essenziell, weil der Datei-Inhalt unmittelbar danach weg ist.

Direkte Syscall-Beispiele

; Direct syscall stub for NtDeleteFile (SSN 0xDB on Win11 24H2 — drifts per build)
NtDeleteFile PROC
    mov  r10, rcx          ; ObjectAttributes
    mov  eax, 0DBh         ; SSN
    syscall
    ret
NtDeleteFile ENDP

// Loader self-deletes its on-disk copy after persisting a clone elsewhere.
// Skips kernel32!DeleteFileW and shell Recycle Bin path.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtDeleteFile)(POBJECT_ATTRIBUTES);

NTSTATUS Vanish(LPCWSTR ntpath) {
    UNICODE_STRING us; RtlInitUnicodeString(&us, ntpath);
    OBJECT_ATTRIBUTES oa;
    InitializeObjectAttributes(&oa, &us, OBJ_CASE_INSENSITIVE, NULL, NULL);
    pNtDeleteFile fn = (pNtDeleteFile)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtDeleteFile");
    return fn(&oa);
}

// Caller: Vanish(L"\\??\\C:\\ProgramData\\loader.bin");

// Cargo: windows-sys = { version = "0.59", features = [
//   "Wdk_Foundation", "Wdk_Storage_FileSystem",
// ] }
use windows_sys::Wdk::Storage::FileSystem::NtDeleteFile;
use windows_sys::Wdk::Foundation::OBJECT_ATTRIBUTES;

unsafe fn vanish(oa: *mut OBJECT_ATTRIBUTES) -> i32 {
    NtDeleteFile(oa)
}

MITRE ATT&CK-Mappings

• T1070.004Indicator Removal: File Deletionmitre ↗
• T1106Native APImitre ↗