After my last post on BleachBit I received additional questions about wiped data. Since many of our investigations involve deleted data, the question often turns to proving or disproving spoliation, the destruction of evidence.
On a Windows system, when a file is deleted with the delete button, it is placed in the Recycle Bin where it is renamed. The time the file is renamed tells us when it was deleted. Metadata stored with this file in the Recycle Bin includes the original path of the file. Knowing where the file was before it was deleted can be critical.
Instead of relying on the built-in Windows functionality, more sophisticated users may use special applications to thoroughly delete their files. These “wiping” programs bypass the Recycle Bin, and so the typical forensic exam may not identify these files. These wiping programs are very good at what they do. Unless it has been stored elsewhere, or copied or backed up to another drive or system (all of which are possible and shouldn’t be discounted), a file deleted by these wiping programs will be permanently deleted and unrecoverable.
But that doesn’t mean all information about the file is lost. There are a couple databases* on the computer that may still hold valuable information. Most forensics software does not dive deeply into these databases. However, using special software tools to analyze these databases, we can often see the names of the deleted files, the date and time of deletion, the original location of the deleted file, and some indication of the program used to delete the files. Coupled with other data collected during the investigation, we may even be able to identify the specific user who was sitting behind the keyboard when data was deleted.
I studied five different file wipers – CCleaner, BleachBit, McAfee, Eraser and SDelete – and discovered characteristics unique to each one.
Before we get started, it’s important to know that when a file is created on a hard drive, it is assigned a Unique Number that will stay with the file until the file is deleted. Tracking this number through each database is how we identify its original name and location. It’s also important to know that a file’s name is stored separately from its data, in a database called the Master File Table (MFT). When a file is deleted, the file’s data is overwritten. However, because its name is in the separate MFT database, we can analyze the MFT to identify where it came from and when it was deleted. The system also logs information about a file anytime it is moved or renamed – additional information that can also be useful.
Armed with this basic knowledge, we can now examine how a file is deleted using a wiping program.
Let’s get started with CCleaner.
When a user identifies a file to be wiped by CCleaner, the program overwrites all of the file’s data on the disk and renames each character of the original file’s name to a capital Z. For example, cat.jpg would be renamed ZZZ.ZZZ and Secret.xlsx would be renamed ZZZZZZ.ZZZZ. You can see this below in the Rename_Moves database as the file MFTtest-26.JPG is renamed ZZZZZZZZZZ.ZZZ.
Below you can see the file is marked as “unallocated” in the MFT, which means it will no longer be displayed to the user and is not easily recoverable without special software. Unallocated space on the drive can used for new files.
Then there is an entry in the Deletions database.
The unique number assigned to this file was 69. By examining the log entries, we can use this number to trace the renamed file back to its original name. While we’re not showing it here, this number may also be used to identify when the file was created**.
Each of these data wipers follows the same basic procedures with a few minor differences. For example, BleachBit renames the file twice: first, it renames the original file to a random string of characters then renames that file again to a single character. Here in the Rename_Moves database, MFTtest-01.docx is renamed to a file beginning with mjRa2 and then renamed C.
The file, now named C, is marked unallocated.
And the Deletions database logs it as deleted.
The next examples follow the same three steps: the file is Renamed, marked as Unallocated, and entered as Deleted. In the interest of brevity, I’ll skip the last part for each and just show Renames. We use the unique characteristics of each wiping program’s renaming process to identify which program was used.
McAfee renames the file 4 times to random characters.
Eraser renames each file 7 times to a random string of data and is distinctive as it clears out the time associated with the Renames_Moves and MFT databases. However, the time remains in the Deletions database.
SDelete is run using the command prompt. It’s not commonly used except by network administrators and other sophisticated users. SDelete renames the file 26 times, multiple As through Zs as seen below. SDelete’s first rename is to a file with a prefix of SDeleAAAAAAAAAAAAAAAAA.AAAA then runs through the entire alphabet from A to Z:
As you can see, each program does its job differently but follows the same basic process – renaming before deleting. By having knowledge of different program’s characteristics, a forensic examiner can identify which program was used to delete specific files, when they were deleted, and the file’s original path.
Simply because a file wiping program was used doesn’t mean all artifacts are gone. By analyzing the finer details of artifacts on a computer, your forensic examiner may be able to uncover critical information in your case.
*I’m using the $MFT and $Logfile. These files are not readily accessible by a regular user but your forensics examiner knows how to get them.
**It may also be possible to identify when the file was created – that is, when the file first appeared on the volume being examined. A new file can be created by the user or copied from another source. This date and time is stored in databases listed above.
Pete James, Managing Director of Computer Forensics
Pete James (@petejames77) is the Managing Director of Computer Forensics for Precision Discovery. A Navy veteran, retired Sheriff’s Lieutenant, and certified forensics examiner, Pete provides unique investigative skills and perspective to our clients. He’s passionate about how computer forensics can tell a story – often stories that weren’t meant to be told!
Visit Pete on LinkedIn.