Introduction:
What function could be more synonymous in Digital Forensics than deleting a file on a computer? The Recycle Bin is where deleted files end up. Done by either the user, or automatically by the system. If the bin is full, windows will start automatically deleting the files. The RB can be accessed either from the desktop icon, or through Windows Explorer (Explorer is where windows allows you to view the contents of your filesystem and where you access files). If you were to click on the desktop icon, you would see the file you deleted with it's original name, path, and date of deletion. It really makes no difference how you navigate to the RB folder, either through the desktop or explorer, you're brought to the same place with the file's original name, date placed, size, and time last modified. It looks normal.
Each user on a system has their own file RB directory of deleted files, each with their own SID. It is also important to know that each drive has their own $Recycle.Bin. And by drive i mean drive letter. And each partition has it's own drive letter. Example of a drive letter is C:\. C standing for the partition you're currently under. So if there's 3 users and 2 drives, each user will have their own directory on each of the 2 drives.
An SID is a security identifier that is kinda like a fingerprint paired with each user. Although there are many digital details in DFIR that can be considered a fingerprint for a user. This is one of them. An SID indicates the system a user is using and the level of access it has. In XP systems, SID is only used with the Recycle Bin. This means SID's only show their user ID when connecting deleted files, with what user deleted it. But in Vista and up, SID's are not only used in the RB, but also used with the Registry SAM hives, for all security access controls. (Access control lists). These are valuable to a forensic investigation. They usually look something like this: S-1-5-21-51003140-4199384537-3980697693-500. This naming convention looks like this for XP, Vista, and 7, and is based on the user. The numbers serve a purpose. The 500 at the end is the Relative ID RID, which means the user is a system admin. So just know the numbers indicate level of access and so on.
What happens?
When a file is "deleted" and sent to the Bin, the file doesn't really go anywhere. You're simply nullifying the files access indicators to the Master File Table MFT. Entries within the B-tree of the MFT are not completely removed when a file deletion occurs. They are marked as deleted using a corresponding $BITMAP attribute. All this really means is that a deleted file doesn't really go anywhere, the OS simply has it's own way of letting it know it's been deleted. So the RB is simply a folder that records deletions.
With this newly deleted file in the RB icon, there is more to it than meets the eye. The reason why people are commonly mistaken (or used to be) with assuming a file is gone when sent to the RB, is because the RB isn't the only thing keeping track of your deletions. How do you think you're able to "Restore" a file when it's sent to the Bin? It's because when you delete a file, there are hidden folders that keep track of these deleted files. And by hidden, i mean they aren't accessible unless you manually configure your system to view these files. I'll touch on these hidden files in a moment.
When you permanently delete a file (either through a shift+delete or through the command prompt), the file isn't sent to the RB directory, but is now labeled as unallocated. The file is now labeled as "00" which means it is unallocated and ready to be written over. File carving techniques are the only genuine manner in which to re-spawn these files.
So back to those hidden files. Why are they hidden? Well much like the registry or security access controls, if you go thumbing around in these files, you may cause configuration problems. The OS likes how it keeps things neat, and you don't know how she likes to keep it. And how many times can you remember when you deleted something, and wanted to bring it back to life?
There are differences between Windows XP and Vista with these hidden files. The differences you'll see will involve the locations of the deleted file and how the path of the file looks. In XP a deleted file is sent to the "RECYCLER" directory, and in Vista/7 a deleted file is brought to the "$Recycle.Bin" directory. Here are what these hidden files will look like:
- Example for XP: C:\Recycler\<USER SID>\INFO2.
- Example for Vista: C:\$Recycle.Bin\<USER SID>\
Keep in mind when accessing the C:\Recycler\<USER SID> file with admin rights in Windows Explorer, it will be in a B-tree format. Under Recycler is SID, and under SID is the Info2 file. There is also an accompanying file under SID with the Info2 file that will look something like DC1.txt. These are the two files that retain information of your deleted file in order to bring it back to life. The DC1.txt file is where the actual content of the deleted file is stored in readable text format. Whereas the Info2 file retains the deleted files metadata. Here's a little information of these two files:
INFO2 file:
The info2 file is basically a secondary index that stores info of deleted files and tracks a file if and when it's moved from the RB. Info2 are hidden files, that stores a files original path and original name in binary format. So if you restore a file from the RB, the system checks the Info2 file to properly restore. When a file is sent to the RB, there is a date and time stamp saved of when this occurred in the info2 file. SO say for example you were looking for a file by it's original name, this is where you would discover it. The Info2 File saves the following:
- A files full path name
- Size of file
- Date and time when deleted
- The files unique identifying number
- The drive letter where the file came from
The first letter D, will always be the first letter regardless of user or file. So whenever you look for this file in XP, there it will be with the first letter D. C on the other hand refers to the identifying drive in which the file came from. Ex: C:\. The number 1 is the unique identifying number of the deleted file. They are assigned according to what file was deleted before they other. Like the 2nd or 3rd file deleted. An ordering number. Then there is of course the extension, depending on what the original files extension was, will be the extension placed here.
Vista/7
Since the newer versions of Windows no longer uses the Info2 file or the DC1.text file, they've adopted their own method of re-spawing deleted files from the RB. Here is a second look at the new hidden location of deleted files in Vista/7: C:\$Recycle.Bin\<USER SID>\. As you can see the Recycler is renamed to the $Recycle.Bin.
Before i get into the differences, keep in mind that Vista still assigns a new $Recycle.Bin folder to every user and every user on a new partition. So as i tried explaining up top, if you have 3 drives and 2 users, each user is going to have their own $Recycle.Bin folder on each drive. Equating a total of 6 $Recycle.Bin folders. It's simply their locations, content, and how they save metadata that changes up. And also, SID's are still implemented when connecting a user to a Bin. Just remember when looking through the RB hidden directory and you see an SID, it is representing a RB icon, tied to a specific user. So if you see 2 SID numbers, there are two users with their own RB's.
And remember how XP had DC1.ext and Info2 within the hidden directories? Well instead of using these two directories to hold the wealth of information, Vista/7 has their own two hidden directories replacing those from XP. The first one you'll see will look something like this: $R<set of 6 random numbers and letters>.<original extension>. Example: $RGDRVPB.txt. This file is similar to the DC1.txt in xp, in that it holds all the textual data that you will find in a deleted file. And unlike in XP, the $R files don't seem to have a ordering convention. They're just placed randomly.
And the second file accompanying the $R, is the $I file. If you look at this hidden file, you'll see it similar in construction as the $R file. Example $I<six random numbers or letters>.<original ext>. This file is also similar to the Info2 file, but it contains a little less metada. The $I only contains 1. original file name 2. files original size 3. and date and time of when the file was deleted.And unlike the Info2 file, the $I is not in plain readable text.
Concluding pointers:
So there you have it. Windows recycle bin in all her wonders. But what happens if you are looking for files that were executed in a Permanent delete? Well this is where forensics comes into play. The techniques in which to find this data on a disk include file carving, and string searching. Both these terms generally follow the same methods of looking for a files header and footer, and then "carving" out these two blocks of information to use in comparison of finding them on a disk. Although i probably shouldn't have listed string searching, because that kinda applies to searching any type of file on a disk, not just the deleted ones. Carving of course can be more specific in definition. Meaning you can select certain sectors in a search. But if you want to a tool to find a deleted file, headers is what they look for. And then there is carving with fragmented files, when a footer isn't available. This poses an issue. And that's really as far as my brain can go. I think this would entail the body of the file, when conducting a search.
Most of these tools are presented in an easy to use GUI environment, and do the heavy lifting of searching for these headers and footers in unallocated space. And also, when using these techniques of searching for deleted files, it isn't a guarantee you'll find what you're looking for. Aside from file damage and corrupted errors, there exists the problem of anti-forensics, with things like stenography, data hiding, or file signature forging.
There is also an important area of data that should be considered when you're looking for lost files from the Recycle Bin. The Volume Shadow Copy Service VSS, is away Windows periodically creates backups from parts of your system, so in cases where it's need, can restore information from the restore points. But back to the Recycle Bin. Fortunately for an ininvestigator, the RB is no exception to the VSS backups, and could include information regarding deleted files from the past. There is an article referencing this topic entitled, "Shadow Volume Trash", by Timothy Leschke. He has a few forensic articles out there, one of which was the main reference of me writing this article.
References
"Cyber dumpster diving". Timothy R. Leschke.
"Windows Forensic Analysis". Harlan Carvey.
Dereknewton.com. Derek Newton.
Image of Info2 in hex, by Steve Hailey.
