Back to Blog
    forensics
    windows-11
    incident-response

    How To Prove What Was Deleted On Windows 11 After An Incident

    Dustin CollettMarch 2, 2026

    When a security or fraud incident involves a Windows 11 workstation, one of the first questions a customer asks is simple: did anything get deleted after we discovered the problem, but before we captured the forensic image?

    The good news is that even when the file contents are gone, Windows and NTFS often leave enough metadata to reconstruct what changed. The trick is doing it in a way that preserves evidence and produces a timeline you can defend.

    This post walks through a practical, repeatable workflow using free or open-source tooling.

    1. Preserve Evidence And Define The Time Window

    Before you start parsing, lock down the boundaries of your analysis.

    • Record the “discovery” timestamp (when suspicious activity was identified) and the imaging timestamp (when the forensic image was acquired).
    • Document time zone handling up front (local time vs UTC). Pick one and stick with it across exports and screenshots.
    • Work from a copy of the image whenever possible. Keep the original evidence image protected and unchanged.

    Also note a key limitation for expectations-setting:

    • If the original system used an SSD with TRIM enabled, you may be able to prove that deletions occurred (metadata), even if you cannot recover the deleted file content later.

    2. Mount The Image Read-Only (Windows VHDX)

    If you have a VHDX restored from your forensic image, treat it like evidence media.

    1. Mount the VHDX read-only from an elevated PowerShell prompt:
    Mount-DiskImage -ImagePath "D:\Case\evidence.vhdx" -ReadOnly
    Get-DiskImage -ImagePath "D:\Case\evidence.vhdx" | Get-Disk
    
    1. Assign a drive letter to the correct partition:
    # Example: disk is #5, assign E:
    Get-Partition -DiskNumber 5 | Where-Object DriveLetter -EQ $null | Select-Object -First 1 | Set-Partition -NewDriveLetter E
    
    1. Confirm the disk is read-only:
    Get-Disk -Number 5 | Select Number,IsReadOnly
    

    Tip: Avoid actions that could modify the mounted volume (no “fix” prompts, no chkdsk, no antivirus scans against the mounted disk).

    3. Collect High-Value Artifacts (Fast, Repeatable)

    For “what was deleted in a window,” you want a small set of high-signal artifacts:

    • NTFS metadata
      • $MFT (Master File Table)
      • $Extend\$UsnJrnl:$J (USN Change Journal)
      • $LogFile (NTFS transaction log)
    • User-facing deletion trails
      • $Recycle.Bin ($I files hold original path + deletion time)
    • “Was the system used?” execution and access trails
      • Prefetch
      • LNK files and Jump Lists
      • Windows Event Logs (logons, RDP, shutdown/startup, and any enhanced auditing you have)

    A simple way to collect these consistently is KAPE (free) with targets for FileSystem, EventLogs, RecycleBin, Prefetch, LNKs, and Jump Lists. Point KAPE at the mounted drive letter (for example, E:) and output to a case folder.

    If you prefer an open-source-first approach, you can still do this with a combination of The Sleuth Kit / Autopsy and targeted extraction from the mounted volume, but KAPE tends to be the quickest “get everything you need” option on Windows.

    4. Prove Deletions With NTFS Metadata (USN + MFT + $LogFile)

    This is where most cases are won.

    USN Change Journal: Your Best “What Changed When”

    The USN Change Journal records file and folder changes. When it’s present and hasn’t rolled over, it’s usually the fastest path to an answer.

    Filter the parsed USN output to your time window and look for:

    • File deletes (delete reasons)
    • Renames / moves (common for hiding files without deleting)
    • Data truncation (files “emptied” without being removed)
    • Directory deletes (whole folder removals)

    Export your filtered rows as a separate CSV for the case file.

    MFT: Confirms Existence Even When Content Is Gone

    MFT parsing helps you enumerate deleted items that:

    • bypassed the Recycle Bin (Shift+Delete)
    • were deleted by scripts or tools
    • no longer exist on disk but still have lingering records

    From the MFT output:

    • Filter for records marked not in use (deleted).
    • Filter timestamps to your discovery→imaging window.
    • Capture full paths, sizes, and timestamp sets for correlation.

    $LogFile: Extra Corroboration

    $LogFile can provide supporting evidence of filesystem operations, especially when you need to show that changes occurred on-disk during the gap. It is finite and can roll quickly, so treat it as supporting evidence—not the only source of truth.

    5. Corroborate Intent And Activity (What Ran, Who Logged In)

    Metadata tells you what changed. These artifacts help you explain how and by whom.

    • Prefetch: Confirms program execution around your window (Explorer, PowerShell, archivers, secure delete utilities, etc.).
    • LNK files and Jump Lists: Often preserve references to documents and paths that are now missing.
    • Event Logs: Validate logon sessions, RDP activity, shutdown/startup events, and (if enabled) process creation or object access auditing.

    A reliable narrative usually looks like this:

    • USN shows FILE_DELETE for a path at 10:32
    • Recycle Bin $I shows a deletion timestamp at 10:33 (if it went through the bin)
    • Prefetch shows PowerShell or Explorer activity around the same time
    • Event logs show an interactive logon session during the window

    That cross-correlation is hard to explain away.

    6. Validate With Shadow Copies (If Present) And Backups

    If the volume contains Volume Shadow Copies (VSS), you may be able to recover “before” versions of folders or individual files, even if the current view is missing them.

    When shadow copies exist:

    • Compare the same directory paths across snapshots to identify what disappeared.
    • If a file existed in a snapshot and is missing from the current view, you have strong support for “it was present before and was removed later.”

    If the customer has backups (endpoint backup, OneDrive/SharePoint versioning, server-side file shares), those can also corroborate existence and timing, but keep those findings clearly separated from what the forensic image alone proves.

    7. Conclusion And Next Steps

    If you can only do three things, do these:

    • Mount read-only and preserve your original evidence image.
    • Build a deletion list from USN + MFT + Recycle Bin, filtered to the discovery→imaging window.
    • Corroborate with logons, Prefetch, and LNK/Jump Lists to show the system was used and how the changes happened.

    If you want a second set of eyes on your workflow—or you need a defensible report your customer can hand to counsel—reach out at (/contact).