Module 3: File System States & Delete-Pending

Understanding the NTFS delete-pending state — the key mechanism that makes Process Ghosting possible.

1. How File Deletion Actually Works in Windows

When you call DeleteFile in Win32, the file does not immediately vanish from disk. Instead, Windows follows a multi-stage process that involves marking the file and then removing it only when all handles are closed. The NT-native view reveals the actual mechanics:

This two-stage model exists because Windows must handle the case where a file is in use when deletion is requested. Unlike Unix (where unlink immediately removes the directory entry while keeping the inode alive for existing file descriptors), Windows keeps the directory entry until all handles close.

2. Two Ways to Mark a File for Deletion

There are two mechanisms to put a file into the delete-pending state:

2.1 FILE_DELETE_ON_CLOSE (at open time)

The FILE_DELETE_ON_CLOSE flag is specified when opening or creating a file. It tells the filesystem to delete the file when the last handle with this flag is closed:

// FILE_DELETE_ON_CLOSE - set at file open time
HANDLE hFile;
IO_STATUS_BLOCK iosb;
OBJECT_ATTRIBUTES objAttr;

NtCreateFile(
    &hFile,
    DELETE | GENERIC_WRITE,   // DELETE access required
    &objAttr,
    &iosb,
    NULL,
    FILE_ATTRIBUTE_NORMAL,
    0,                         // no sharing
    FILE_SUPERSEDE,            // create or replace
    FILE_DELETE_ON_CLOSE,      // <-- delete when handle closes
    NULL, 0
);

2.2 FileDispositionInformation (after open)

The NtSetInformationFile call with FileDispositionInformation can mark an already-open file for deletion. This is the approach Process Ghosting uses:

// FileDispositionInformation - set AFTER file is open
FILE_DISPOSITION_INFORMATION dispInfo;
dispInfo.DeleteFile = TRUE;

IO_STATUS_BLOCK iosb;
NTSTATUS status = NtSetInformationFile(
    hFile,                           // existing open handle
    &iosb,
    &dispInfo,
    sizeof(dispInfo),
    FileDispositionInformation       // information class
);

3. The Delete-Pending State in Detail

Once a file is marked for deletion (by either mechanism), it enters the delete-pending state. This is a real state tracked by the filesystem driver (NTFS). While in this state:

The critical insight is the asymmetry: the handle owner can still do everything with the file (read, write, create sections), but no one else can open the file. This is exactly the property Process Ghosting exploits.

4. Interaction with Section Objects

A key question for Process Ghosting is: can you create a section from a delete-pending file? The answer is yes, as long as you use the existing open handle.

// This works: create section from delete-pending file via existing handle
HANDLE hSection = NULL;
NTSTATUS status = NtCreateSection(
    &hSection,
    SECTION_ALL_ACCESS,
    NULL,
    NULL,
    PAGE_READONLY,
    SEC_IMAGE,
    hFile           // handle to delete-pending file - WORKS
);

Once the section is created, it holds a reference to the underlying file object in the kernel. Even when the file handle is closed and the file is deleted from disk, the section persists because the kernel keeps the file object alive through the section’s CONTROL_AREA → FILE_OBJECT reference chain.

5. The Ghosting Order of Operations

The specific order in which operations are performed is critical. Here is why each step must happen in this exact sequence:

6. STATUS_DELETE_PENDING vs STATUS_FILE_DELETED

When another process (like an AV scanner) tries to open a file in these states, it receives different error codes depending on timing:

In both cases, the AV scanner cannot open or read the file. This is the fundamental evasion mechanism of Process Ghosting. The file is either locked by the delete-pending state or gone entirely.

7. NTFS Internals: The MFT Perspective

At the NTFS level, deletion involves the Master File Table (MFT) entry for the file:

The key point is that during the delete-pending phase, the MFT entry and data clusters are fully intact. The file’s data (our malicious PE) is physically present on disk and readable through the existing handle. It is only inaccessible to processes that try to open it, because NTFS rejects new opens for delete-pending files.

8. Practical Implications for Security Tools