What happens when a file is deleted (on a Windows system)

delete-file, Digital-Forensics, NTFS, Windows / By

The million dollar question of any interview for a DFIR role. What happens when a file is deleted, what changes occur and how one can still find evidence of the file’s existence after the file was deleted.
I personally heard this question in interviews for all roles that required experience in digital forensics. Next (as frequency) are “the meaning of file timestamps” and “how to detect file timestamp tampering” however, I plan to cover these in future blog posts.

[Technical assumptions]
Before we dive into the actual technical details I would like to remind our readers that this article assumes a fair level of familiarity with NTFS data structures and with the digital forensic field. If you will find in this article terms/concepts that you do not understand please check out the last section with references where I provide additional (and hopefully very useful) reading materials – books I used as reference a lot of times during my investigations. 
And since all the times the question was related to Windows OS (7 and beyond) with NTFS 3.1 as file system I will limit the scope of the article to just that.

[Deep dive]
Alright, let’s take a closer look at this and first review how a file could be removed/deleted. First scenario is where a logged-on user is deleting the file by selecting it and pressing the delete key or just right-click the file and delete it – essentially sending it to the Recycle Bin folder corresponding to that user account.
In the second scenario the file is deleted using shift & delete or cut & paste (to a different volume); this is also the way most desktop applications (e.g. web browsers) or even the Operating System will “transparently” delete files that will never show up in the user’s Recycle Bin.

The 1st scenario is more complex than the second so let’s do this one; ok so our user just deleted secret_file.txt from his Desktop.

  1. [Recycle Bin] Original file is renamed and moved to the Recycle Bin folder corresponding to the account used to delete the file.
    NOTE: at NTFS level this corresponds with a modification of the $FILE_NAME attribute to reflect the:
    – the new parent folder (now the Recycle Bin folder of the user who deleted the file)
    – new name ($R….XYZ – the renamed file retains the original extension, XYZ); this is only valid if the file was deleted directly. If the file was in a folder structure and one of the top folders was deleted it will retain its original name (secret_file.txt).

  2. [Recycle Bin] At the same time a $I (the pair of $R file above) file is created in the same Recycle Bin folder.
    NOTE: The $I file will contain metadata about the deleted file like the original location so that if the user decides to restore the file the OS still has info about the original location/folder where the file was. Recall from previous step that now the file has a new parent folder (the Recycle Bin).

    Traces of what caused the deletion will result in a number of Explorer shell-bags and registry-bags or other logs (e.g. Event Log) but we will not cover these; we simply mention this since these modifications are also part of the big picture. 

    Alright, let’s go even deeper and look into what is happening at NTFS level once the user decides to empty the Recycle Bin; from this moment the steps are valid as well for the 2nd scenario (i.e. shift & delete).

  3. [$MFT] The in-use flag (bytes 22-23 inside the $MFT entry of the deleted file) is modified to zero to indicate the MFT entry is no longer allocated.
  4. [$MFT] The MFT ID’s sequence number is incremented by 1.
  5. [$LogFile] The $LogFile will record changes to the text file; the event code for used for file deletion is “DeallocateFileRecordSegment”. 
    NOTE: more info regarding File System Control Codes.
    NOTE: Unfortunately $LogFile normally holds a relatively short time span of minutes or hours depending of how busy the system is.
  6. [$UsnJrnl:$J] The UsnJrnl is a lot more verbose than $LogFile and normally the time span of events can cover one or more days.
    NOTE: when exporting the alternate data stream $J (using tools such as icat) make sure you mention the full address including the attribute ID/s.
    NOTE: after parsing $J, to find files that were deleted use the event codes CLOSE and FILE_DELETE.

    Speaking of these two flags, using Procmon we can see that for file deletion the operation executed is CreateFile with one of the options flag set to “Delete on Close”. This flag (Delete on Close) tells the OS to prevent any new handles to the file from being created. Trying to access again the file (after the file was already accessed with this flag) will produce an “Access denied” error message.

  7. [$Bitmap] $Bitmap is modified to indicate that the volume’s data runs/clusters associated with that file are now available.
    NOTE: if the file is $MFT resident (because it has less than 1024 bytes) this file is not updated.
  8. [$I30] The $I30 index allocation / index root attribute of the folder where the file was residing before deletion might change. 
    NOTE: I said might since the list of files found inside each folder is stored as binary tree in NTFS. So depending on what changes the update of the binary tree will happen the file name might be removed from the Index Allocation/Root.

In practice most new laptops use Solid State Disks (SSD) and for these starting with Windows 7 we have the OS integration with the TRIM command. This in turn will result in a complete removal of the file from $MFT and the disk data clusters with the next SSD TRIM cycle – normally in a few seconds the original file will be gone and the its MFT ID will be reused by another file.

On a Hard Disk Drive (HDD) the file may still be present on the disk with the modifications described above (steps 3 to 8) for a longer time depending on how busy the Operating System is; this could be minutes, hours, days or longer thus allowing a forensic investigation to discover more evidence.

[Conclusion]
As you can see there are a number of implications when deleting a file in a Windows system. In the end answering a question like this is meant to show a sounds understanding of how NTFS works at a deep level.
I hope you found the article useful and if you have any questions or would like to see more content like this feel free to leave a commend below.

[References]
#Windows Forensics
Windows File System Forensics – https://www.amazon.com/Forensic-Examination-Windows-Supported-File-Systems/dp/1497358353/
Brian Carrier’s all time classic – https://www.amazon.com/System-Forensic-Analysis-Brian-Carrier/dp/0321268172

#TRIM
General presentation – https://en.wikipedia.org/wiki/Trim_(computing)
TRIM Windows API – https://docs.microsoft.com/en-us/windows/win32/w8cookbook/new-api-allows-apps-to-send–trim-and-unmap–hints-to-storage-media 
Activate / deactivate / Query status for TRIM https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior