Think NTFS is clean after a wipe? Think again. In this CQURE Hacks episode, we demonstrate why deleted files often remain intact and how resident files hide inside the MFT to survive standard disk cleaning.
by Paula Januszkiewicz
When you remove a file in Windows, the operating system marks the space as available, but the data often stays behind. By using Sleuthkit’s fls tool and MFTECmd, we can bypass the GUI to read the Master File Table directly.
This allows us to see deleted entries and even track the source URL via the Zone.Identifier stream. One of the most critical findings in this demonstration is the behavior of resident files.
Small files under 700 bytes are stored entirely within the MFT record itself rather than separate disk clusters. Because the MFT is allocated space, standard free space wipes only target unallocated clusters, leaving resident data completely untouched and functional for recovery.
This demonstration highlights several critical forensic principles:
Want to go deeper?
Take your technical skills to the next level with our 4-day intensive course: Windows Security and Infrastructure Management with Windows Internals, starting on March 23rd or June 15th. This 28-hour deep dive is designed to turn IT professionals into elite security practitioners by uncovering the inner workings of the Windows OS.
The program provides a complete view of the system’s architecture – from process and thread management to the complexities of memory analysis and storage. You will gain a strategic understanding of system security mechanisms, startup and shutdown sequences, and layered network services. By mastering infrastructure security solutions and event tracing, you’ll be able to identify points of entry and manage complex enterprise environments with precision.
The masterclass is led by Amr Thabet, a malware researcher and founder of MalTrak with over 12 years of experience working with Fortune 500 companies. He is a recognized industry expert and author of Mastering Malware Analysis, dedicated to helping professionals build expertise in threat hunting and protecting organizations from targeted attacks.
TRANSCRIPT
In this demonstration, we’ll analyze a mounted VHD attached as drive X:, labeled CQ_Demo.
We’ll simulate a small forensic investigation to show that deleted does not mean destroyed — and even wiping free space may not eliminate evidence.
First, I’ll open C:\Evidence\Recovery to show it’s completely empty. This is where any recovered artifacts will be placed. Now under This PC, we can see the mounted drive: CQ_Demo (X:).
The drive is empty to begin with — no user files present. The USN Change Journal is currently not active. The USN Journal is an NTFS feature that logs file system changes — such as file creation, modification, and deletion.
Instead of asking Windows, we ask NTFS directly using Sleuthkit’s fls tool. This reads the Master File Table — the core structure of NTFS. There are no deleted user files at this stage.
I’m enabling the USN Journal; this ensures file activity will be logged going forward. The journal is successfully created, and from now on, file operations on this volume will generate USN entries. Here we have cqureAcademylogo.svg, let’s open it. This is just an image file. Nothing special — but it will represent our ‘evidence’. Let’s copy and paste it into our CQ_Demo drive. The file is present and fully visible on the volume.
Let’s remove it using the Remove-Item command. From the operating system perspective, the volume is clean again, but forensic analysis doesn’t stop at what the OS GUI shows. We extract both the Master File Table and the USN Journal using MFTECmd. The MFT contains metadata for every file on the volume — including deleted ones.
Scrolling down, we can see references to the file name and even the source URL stored in the Zone.Identifier alternate data stream. Now in the USN Journal output, at the bottom, we see a FileDelete operation for cqureAcademylogo.svg.
This gives us timeline evidence: the file was created and deleted. Now we enumerate deleted entries. Here we see the deleted file — and its alternate data stream, Zone.Identifier. That alternate stream stores metadata about downloaded files, such as their source.
The first number — 39 in this example — is the MFT record number, also called the inode. Using istat, we inspect the MFT record. Even though the file is deleted, its metadata remains in the MFT.
Now let’s recover the file. And the file is fully recovered and functional.
Deleting a file in NTFS simply marks its MFT record as free, but the data remains until it’s overwritten. Now I’ll create ten small text files and remove them. This overwrites all unallocated clusters with zeros, ones, and random data. Many believe this destroys deleted files completely. Despite wiping free space, the deleted files still appear in the MFT.
Here’s the key detail: this file is resident. Small files, typically under around 700 bytes, can be stored entirely inside the MFT record itself; they do not use separate disk clusters, and the MFT itself is allocated space.
The wipe operation only overwrites unallocated clusters, so resident data survives a free space wipe. The content is fully intact.
This demonstration highlights several critical forensic principles:
Deleting a file does not erase it.
NTFS keeps metadata in the Master File Table.
The USN Journal records change events.
Free space wiping does not affect allocated structures.
Resident files stored inside the MFT can survive wipe operations.
The operating system shows what is allocated.
Forensics shows what still exists.
Want to know more?
Learn more about our offer in terms of Consulting. Our Cybersecurity Experts perform consulting work on a daily basis, hence we are fully prepared for any challenge.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
