Recycle Bin

What it is

When a user deletes a file through Explorer (or any program using the shell delete API), Windows does not erase it: it moves it into a hidden per-volume, per-user folder and records where it came from and when it was deleted. Since Windows Vista each deleted item produces a pair of files: a $R file holding the original data and a $I file holding the metadata. Windows XP used a single INFO2 index. The Recycle Bin is the first place to answer "who deleted what, and when", and deliberate emptying is a classic anti-forensics indicator.

Location

$I and $R share the same six random characters and the original extension. Each fixed volume has its own $Recycle.Bin at its root; the <SID> subfolder ties items to a user (security identifier). Removable flash drives generally have no Recycle Bin, so deletions there are immediate.

What it proves

• Deletion by a specific user: the SID folder attributes the action to an account.
• When: the deletion time stored in the $I file or INFO2 record.
• What and where: the original full path and file size, even after the $R content has been purged.
• Content: while the $R file exists, the full original data can be recovered.
• It does not record files deleted with Shift+Delete, del/Remove-Item on the command line, or most programmatic deletions, which bypass the bin.
• An empty Recycle Bin does not by itself prove anti-forensics: users empty it routinely.

Key fields

Timestamps

Retention and clearing

• Items stay until the user restores them, deletes them from the bin, empties it, or the bin exceeds its maximum size and the oldest items are purged.
• Per-volume settings live under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume\<GUID>: MaxCapacity (size) and NukeOnDelete (set to 1, files are deleted immediately without going to the bin).
• Emptying deletes both $I and $R files. Traces remain: $I/$R entries and names in the $MFT and $I30 indexes, deletion records in the USN journal, and file content in unallocated space until overwritten.
• Volume shadow copies often preserve an earlier state of $Recycle.Bin.

Collection

• KAPE target: RecycleBin (compound of RecycleBin_InfoFiles for $I*/INFO2 and RecycleBin_DataFiles for $R*/D*). Collect info files only when content volume is a concern.
• Velociraptor (Windows.Triage.Targets): RecycleBin, RecycleBin_InfoFiles or RecycleBin_DataFiles. Windows.Forensics.RecycleBin parses $I files live (Vista and later, not INFO2).
• Built-in: the folder is hidden and protected; list and copy it from an elevated prompt and map SIDs to users:

Get-ChildItem 'C:\$Recycle.Bin' -Force -Recurse | Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtc
robocopy 'C:\$Recycle.Bin' E:\case\RecycleBin_C /E /B /COPY:DAT /DCOPY:T
Get-CimInstance Win32_UserProfile | Select-Object SID, LocalPath

Repeat for every volume (D:\$Recycle.Bin, etc.).

Parsing tools

• RBCmd (Eric Zimmerman, free): RBCmd.exe -d E:\case\RecycleBin_C --csv E:\out parses $I versions 1 and 2 and XP INFO2 files.
• Rifiuti2 (open source): parses INFO2 and $I files, with tab-separated or XML output.
• Velociraptor: Windows.Forensics.RecycleBin.
• Plaso: recycle_bin ($I) and recycle_bin_info2 (INFO2) parsers for super timelines.

Investigation tips

• Sort by deletion time and look for bursts: mass deletion just before a device return, a dismissal or an incident response is a strong anti-forensics indicator.
• Deleted attacker tools and archives (.zip, .7z, .rar) often sit in the bin with their original path in Downloads, Temp or a staging folder.
• If the bin is empty, look for orphan $I/$R names in the $MFT and FILE_DELETE records for them in the USN journal to date the emptying.
• Compare the original path with LNK files and Jump Lists to show the file was opened before being deleted.
• For deleted pictures whose $R is gone, check the thumbcache.
• Check NukeOnDelete before concluding that nothing was ever recycled.