← ./resources / blog

Ghost Files: File Names, Handles, and Section Lifetime

A Windows file is more than a pathname. Open handles, file objects, cached data, and section objects can outlive directory visibility. “Ghost file” discussions become much clearer when defenders separate those lifetimes and build a timeline from kernel-observed events.

Defensive scope

This article explains object lifetime and forensic evidence. It does not provide a recipe for creating hidden executable artifacts.

The object-lifetime model

Applications open a path and receive a handle associated with a kernel file object. A file can be marked for deletion while handles still exist; directory queries may stop presenting the name even though the underlying object remains usable in constrained ways. Separately, an image or data section can reference file content. Deletion, handle closure, and section lifetime therefore need not occur at the same moment.

Names disappear before every reference doesPath createdfile writtenHandle openobject referencedDeletependingSection mayremainFinalcleanupEvidence: create/write/delete events · file ID · handles · image load · process creation · USN journal
Correlating by file identity and time is stronger than assuming a missing path means the content never existed.

What to collect

  • File create, write, rename, disposition, and delete events with process identity.
  • Volume, file ID, original path, zone information, hash, and signer when available.
  • Handle and section creation telemetry plus image-load and process-start records.
  • NTFS USN journal and $MFT evidence collected with forensic discipline.
  • Memory-resident image details when the backing path is missing or inaccessible.

Detection logic

Prioritize short sequences where an uncommon process writes executable content, marks it for deletion, creates or retains a section, and is followed by image mapping or process creation. Exclude legitimate browser updates, installers, antivirus quarantine, and transactional applications only after baselining their signers and expected paths. Keep raw events long enough to correlate actions that span telemetry sources.

Safe tools and lab

Use Velociraptor for endpoint collection, MFTECmd for NTFS metadata, Volatility 3 for memory, and Sysmon for controlled event capture. A safe exercise can observe a normal application deleting an open temporary text file and compare directory visibility, handle lifetime, and journal entries. Do not attach executable content.

ATT&CK and CVE context

Ghost-file behaviors may support T1070.004 File Deletion, T1027, or T1055 depending on the complete chain. The Windows delete-pending model is expected operating-system behavior, not itself a CVE. Record a CVE only if a separate vulnerability enabled access or execution. Mitigate through application control, endpoint file and image telemetry, restricted write locations, least privilege, and preservation of NTFS and volatile evidence.

← Previous: Reflective DLL InjectionNext: Process Ghosting →