Windows Recycle Bin Forensics on Windows 10 and 11

In a surprising number of investigations, the Recycle Bin is the difference between we think something was removed and we can show what was removed, from where, and roughly when. It’s also an artefact that’s easy to misunderstand or misinterpret. The Recycle Bin records a particular class of deletion behaviour: deletions on a given volume, under a given user context, within the limits of configuration and capacity, usually using the Windows shell (but not always).

This post examines how the Recycle Bin works on Windows 10 and 11 from a forensic perspective, what its artefacts actually represent, and how to integrate them into defensible investigative reasoning. It focuses on interpretation rather than tooling, and on limits as much as signal. The goal is not to prove intent, but to understand what the evidence can reliably support.

What the Recycle Bin Does Under the Hood

On modern Windows systems, the Recycle Bin isn’t a central system store. It’s per-volume, per-user storage that lives in the filesystem as NTFS objects. On each NTFS volume that participates in Recycle Bin behaviour, you’ll find a hidden directory at the root called $Recycle.Bin:

Inside that $Recycle.Bin directory, Windows creates one subdirectory per user, named by SID. The SID directory is the key unit of attribution. If you’re looking at a multi-user workstation, a shared jump box, or anything that’s had multiple interactive logons, treat each SID directory as a separate evidence container.

A common mistake is to look at a user’s profile, not see anything obvious, and decide the Recycle Bin is empty. That’s an interpretation, not a finding. Your finding is: this user’s Recycle Bin directory on this volume contains no current entries. Those aren’t the same thing.

Per-Volume Recycle Bin

The per-volume design is operationally important. If a user deletes a file from C:\Users\..., it lands in C:\$Recycle.Bin\<SID>\.... If they delete a file from D:\Projects\..., it lands in D:\$Recycle.Bin\<SID>\.... If you only take an image of the system volume, or you only mount the system volume during analysis, you can end up telling yourself a story that the evidence doesn’t support.

If you open the Recycle Bin on a live system, you’ll see files put into that structure by the currently logged in user, deleted but not permanently deleted. That listing will include files and folders from any drives on that machine. However, if you were to forensically image that system, then open that image in a tool like X-Ways or FTK Imager, you’d only see entries for that specific drive. You’d have to navigate to the Recycle Bin directory on all imaged drives individually to get the full picture of what exists within the $Recycle.Bin structure for a machine with multiple drives.

In practice, this comes up in two places. First, developer workstations and analyst workstations commonly have secondary volumes. The Recycle Bin can be active on those volumes even when the system volume looks clean.

Second, removable media behaves inconsistently depending on how the device is presented to the OS. Some external drives are treated as fixed disks and participate in Recycle Bin behaviour. Many USB thumb drives do not. The absence of $Recycle.Bin on a removable device isn’t particularly informative by itself. It might just reflect that Windows never used the bin for that device type or filesystem.

“Deletion” is Often a Move and Rename

The Recycle Bin is primarily a shell feature (i.e. the Windows GUI). When the shell sends a file to the Recycle Bin, the file content isn’t destroyed. The file is moved into the $Recycle.Bin\<SID> directory and renamed to an internal name. At the same time, Windows creates a small metadata companion that records what the file used to be. For each deleted item you typically see a pair:

• A $R file (the content)
• A $I file (the metadata)

The $R file holds the bytes of the deleted item, the actual data. The $I file holds information that allows Windows to display original location, date deleted, and size in the UI.

From a forensic perspective, you can treat the $I file as the evidence of the deletion event, and the $R file as the evidence of the deleted content. They answer different questions, and you should avoid forcing one artefact to do the job of the other.

What $I and $R Artefacts Mean

The $R file is the recovered payload, in the simplest sense. If the deleted item was a single file, $R... is a renamed copy of that file, living in the $Recycle.Bin directory. If the deleted item was a folder, you’ll usually see the folder structure preserved under a corresponding $R... directory.

In the screenshot, $R5ZF742.old and $RJAN435.old are two directories I moved to the Recycle Bin on my test machine. Interestingly, they retain the .old I appended to them even though it’s not a file extension, it’s part of the directory name. $I5ZF742.old and $IJAN435.old are their respective $I files.

The important point is that the $R name isn’t meaningful. You can’t infer anything from the randomised portion of the filename beyond pairing. The extension is often preserved, which makes it tempting to treat $R*.docx as “a docx that was deleted.” That part is broadly fine. The trap is moving from that to “this docx was created when it entered the Recycle Bin.” It typically wasn’t.

Because the operation is a move-and-rename within the same NTFS volume, the standard file timestamps on the $R file tend to retain the original file’s metadata, as seen in the screenshot above. That’s expected, but it’s also a source of repeated analyst error.

If you find a $R file with a creation time of last month, and a $I record indicating deletion yesterday, that’s not a contradiction that needs to be resolved, that’s the expected behaviour for a move operation. That’s exactly the behaviour we see in the screenshot above; $R5ZF742.old has a modified date inside $Recycle.Bin of June 30th, 2025, while it’s corresponding $I5ZF742.old shows the actual date I deleted the folder, December 24th, 2025.

This is explained well in the SANS Windows Forensic Analysis Poster:

When a file is moved or renamed (or ‘deleted’ and put in the Recycle Bin), only the metadata change timestamp is updated, meaning the MFT record.

The $I file is a small structured record. Its job is to preserve the context that Windows would otherwise lose when it renames the original item to $R.... The $I file is how Windows knows where to restore the file if the user chooses to put it back.

On Windows 10 and 11 you should expect a $I file to provide, at a minimum:

• The original full path of the deleted item, including filename
• The original file size
• The deletion timestamp, stored as a Windows FILETIME (a 64-bit integer)

The deletion timestamp stored in the $I record is usually the closest thing you’ll get to “time of delete-to-Recycle-Bin” from this artefact. It’s stored as FILETIME, which is UTC in representation even when Windows displays it in local time. That matters when you correlate it with other data sources that are local-time displayed, local-time stored, or UTC stored but local-time rendered by your tools.

Time handling errors are a quiet way to break an otherwise good analysis. If you’ve worked in DFIR for any length of time you’ve probably been burned by time skew before.

Pairing $I and $R: What “Correct” Looks Like

The pairing mechanism is simple. As we saw, the $I and $R filenames share the same random base token (e.g. $R 5ZF742 .old/$I 5ZF742 .old. You match them by that token, not by extension or sorting order.

Once paired, a coherent entry should look like this:

• $I says: original path = C:\Users\Alice\Documents\Budget.xlsx, deletion time = 2025-12-20 02:13:45Z, size = 104,448 bytes
• $R exists and its content is recognisably a spreadsheet of roughly that size

If you see a mismatch, pause before you “fix” it.

A missing $R with a present $I can be the result of partial deletion, quota eviction, or later activity that overwrote the content. A missing $I with a present $R can happen as well, but it’s less common. Both scenarios are more useful as investigative signals than as parsing problems.

In the screenshot, you can see those entries that are permanently deleted (e.g. $RHXIKTJ.zip, $RQLVJEY.wav), meaning cleared from the Recycle Bin after being deleted by the user (or cleared another way, like automatically by Windows 10 Storage Sense), are displayed by FTK, but their companion $I files aren’t available:

If a user restores an item from the Recycle Bin, Windows moves the $R back to its original location and then deletes the $I and $R from the bin. Forensically, a restoration means the Recycle Bin loses that entry. However, the restored file’s MFT record might still reflect its history (e.g., creation time might be older, and there could be USN journal entries showing it being moved out of $Recycle.Bin). If you suspect a user undeleted something, look for inconsistencies across other artefacts; LNK files, Jump Lists, ShellBags, etc.

When you find either a $I or $R without the other, your question should shift from how do I reconstruct the pair to what behaviour could produce this partial state, and how can I corroborate it.

Parsing Recycle Bin Artefacts

First of all, you need to parse the contents of the Recycle Bin. One of the simplest ways to do that is capture them with KAPE (or another tool of your choice):

PS C:\> .\kape.exe --tsource C --target 'RecycleBin_InfoFiles,RecycleBin_DataFiles' --tdest 'D:\KAPE_out'

You can additionally parse in the same KAPE command line, or alternatively parse the resulting output with RBCmd.exe or similar:

PS C:\> .\RBCmd.exe -d 'D:\KAPE_out\C' --csv .\

The resulting CSV will look something like this for all the data it was able to parse:

The important part here is the structure of the data, not the tool used to extract it.

What You Can Conclude from Recycle Bin Artefacts

Recycle Bin artefacts are most valuable when you keep the conclusions narrow and defensible.

What They Support Well

Recycle Bin artefacts can usually support conclusions along these lines:

A specific user context sent a specific item to the Recycle Bin from a specific original path, at approximately a specific time, on a specific volume.

That sounds basic, but it’s a lot of signal in one sentence. It ties together identity (via SID), location (original path and volume), action (moved into bin), and time (deletion timestamp).

Recycle Bin artefacts also support content recovery in a very direct way. If the $R exists and is intact, you have the file as it existed at deletion time, subject to later modification edge cases discussed below.

What Recycle Bin Artefacts Do Not Prove on Their Own

They do not, on their own, prove intent.

The same artefacts can result from routine housekeeping, accidental deletion, or purposeful destruction. This is where analysts often overreach. The presence of C:\Users\Bob\Downloads\setup.exe in the bin rarely matters. The presence of C:\ProgramData\SomeTool\payload.dll might. The difference isn’t the artefact, it’s the investigative context you build around it.

Recycle Bin artefacts also don’t prove that a user permanently deleted something. The Recycle Bin is a staging area. In a lot of environments, it’s treated like temporary storage. “In the bin” isn’t “gone.” It’s better to treat Recycle Bin contents as evidence that a deletion action occurred, not as evidence that destruction was successful.

Finally, Recycle Bin artefacts don’t prove that a file was deleted via the shell in all cases, even though most of the time that’s the correct inference. There are APIs that allow software to send content to the Recycle Bin as well. If you’re investigating a host with extensive automation, or a system where third-party tooling is used to clean directories, you should at least allow for programmatic shell usage as a possibility.

Where Analysts Commonly Go Wrong

Analysts usually fall victim to the same challenges.

Treating $R Timestamps as Deletion Time

This comes up so often because it feels intuitive. You see a file in $Recycle.Bin, you look at its created time, and you assume that’s when it was created in the bin. With move semantics, that’s usually wrong.

A more reliable pattern is:

• Use the $I embedded timestamp as your primary sent to bin time
• Treat the $I file system timestamps as a secondary check, not the source of truth
• Treat $R timestamps as describing the file’s lifecycle before deletion, not the deletion event

Only Looking at One Volume, User, or Time Slice

In real cases, the relevant artefacts are often on a secondary volume, under a different SID, or preserved in a snapshot rather than the live view of a system.

One approach is to think in containers:

• Containers by volume ($Recycle.Bin per volume)
• Containers by user (SID folders under each volume)
• Containers by time (live state versus VSS snapshots, backups, and unallocated remnants)

Overstating What “Empty” Means

An empty Recycle Bin can mean:

• It was emptied manually
• It was emptied automatically
• The bin is configured to bypass storage
• The drive is not participating in bin behaviour
• The relevant evidence rolled out because of size limits
• You’re looking at the wrong user, wrong volume, or wrong time slice

Recycle Bin Behaviour That Changes Your Interpretation

Capacity, Eviction, and Large File Behaviour

Recycle Bin storage isn’t unlimited. Each volume has a quota. When it fills, Windows evicts older items to make room for newer ones. That eviction can happen without a user explicitly emptying the bin, and you can end up with a bin that contains only recent items even when deletion has been ongoing for months.

This creates an evidentiary bias: the bin favours recency, not completeness.

Large files add another challenge. If a file is larger than the configured quota, Windows might prompt the user indicating it’ll be permanently deleted instead of moved:

In those cases you might have no $I/$R at all for that deletion, even when the user deleted from Explorer. This is one of the more painful edge cases because it looks like they bypassed the bin when it might just be size-driven behaviour.

If the case hinges on a missing large file, check the file’s likely size and the volume’s quota configuration. It’s not always recoverable after the fact, but it can stop you drawing the wrong conclusion.

On the live system, quota information is available by reviewing the Recycle Bin Properties:

Alternatively, you can determine Recycle Bin quotas entirely offline from a forensic image. The quotas are stored per-volume and per-user, and almost all the authoritative data lives in the user’s registry hive at C:\Users\<username>\NTUSER.DAT. Relevant keys are stored in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume\{Volume-GUID}. Each {Volume-GUID} corresponds to one volume (C:, D:, removable media, etc.). Values include:

1. MaxCapacity: Recycle Bin quota for that volume
2. NukeOnDelete: 1 = bypass Recycle Bin (Shift+Delete behaviour default)
3. Percent (older versions): Percentage-based quota (XP-era behaviour)

Shift+Delete and Non-Shell Deletion Paths

Not all deletions hit the bin. Shift+Delete is the obvious one. Besides that there are:

• Command-line
• Many programmatic methods
• Network share
• Some removable media

The common thread is that the Recycle Bin only records the subset of deletions that Windows chooses to stage rather than immediately deallocate. Your reasoning should reflect that.

Multi-User and Administrative Context

On a multi-user system, it’s common for an administrator to delete files from another user’s profile during troubleshooting. Those deletions often land in the administrator’s bin, not the target user’s, because the action occurs under the administrator’s user context. This matters when you’re attributing behaviour.

If you find sensitive documents in the administrator’s Recycle Bin, with original paths under another user’s profile, don’t assume the other user deleted them. The Recycle Bin is telling you who performed the delete-to-bin action, not who owned the file.

That’s also a place where SID-to-username mapping becomes important. It’s simple enough to translate users to SIDs on a live system using something like PowerShell:

When you’re analysing a forensic image, run RECmd against the SAM hive (SAM\Domains\Accounts\Users) or review in the Registry Explorer GUI:

Integrating Recycle Bin Evidence into Timeline Analysis

Recycle Bin artefacts are rarely the whole story. They’re a good anchor point.

The $I timestamp gives you a deletion moment to build around. The original path gives you a location to pivot on. The $R content gives you a payload to interpret.

From there, you want corroboration that answers two questions:

1. Does the deletion time make sense in the broader activity timeline?
2. Does the file’s lifecycle before deletion line up with other artefacts?

There are a few ways to find the answers.

NTFS Context: $MFT and the Nature of the Move

Because delete-to-bin is usually a move-and-rename, it generates NTFS metadata we can use.

On many systems, you’ll see evidence in the MFT that the file’s parent directory changed to $Recycle.Bin\<SID>, and that the filename changed to $R.... Depending on how you extract and interpret MFT data, you might see file name attribute changes or directory index changes (those $I30 indexes we mentioned earlier) that align with the $I deletion time:

The practical value is less about proving the move and more about adding structure.

If your $I record shows C:\Users\Alice\Documents\Plan.docx was sent to the bin at 10:12, and you also see MFT activity around 10:12 involving that file reference, you can sometimes treat that as corroboration. If the MFT activity is missing but the $I is present, don’t treat that as disproof; it might be retention, roll-over, or tooling differences.

What you want is consistency across sources where available, not perfect coverage.

$UsnJrnl: Rename and Delete Traces When You Can Get Them

When the USN Journal is present and has retained the relevant window, it can be a strong companion to Recycle Bin analysis.

The USN Journal is stored as an Alternate Data Stream in \$Extend\$UsnJrnl:$J. The send-to-bin operation typically generates rename or move entries in the journal:

In the screenshot, you can see the testing process I followed:

1. Create New Folder: FileCreate|Close
2. Rename the folder to USNJrnl Testing: RenameOld → RenameNew|Close
3. Create New Text Document.txt on the user’s Desktop: FileCreate|Close
4. Rename New Text Document.txt to Text document to delete.txt: RenameOld → RenameNew|Close
5. Delete Text document to delete.txt (i.e. move to Recycle Bin):
   1. $IGPGCEJ.txt is created: FileCreate|Close
   2. Text document to delete.txt is renamed to $RGPGCEJ.txt: RenameOld → RenameNew|Close
6. Finally, $J recorded PowerShell_ISE.EXE execution when I ran KAPE and MFTECmd to parse the USN Journal and produce this CSV

Here are the contents of the Recycle Bin after the file deletion, showing the $I/$R for the document:

Note that I’ve removed a lot of the noise from the Timeline Explorer view above; the USN Journal is a noisy artefact and it won’t be this clean without some analytical effort.

This is useful in two ways.

First, it can confirm the time window and sequencing. If you see a burst of USN rename events moving many files into $Recycle.Bin within seconds, that suggests a bulk delete action.

Second, it can help in partial artefact scenarios. If the $I is present but $R is gone, and you still have a USN entry showing the $R creation/rename into the bin, you can report that the content existed and was staged, even if it’s no longer recoverable.

USN data is in no way guaranteed. It can be disabled. It can be cleared. Its relatively small. USN data is a record of every file and folder operation on a modern Windows system. You can check the journal size with fsutil:

PS C:\> fsutil usn queryjournal C:
Usn Journal ID   : 0x01d5d783cc72f597
First Usn        : 0x000000cbfd000000
Next Usn         : 0x000000cbff70df50
Lowest Valid Usn : 0x0000000000000000
Max Usn          : 0x00000fffffff0000
Maximum Size     : 0x0000000002000000 (32.0 MB)
Allocation Delta : 0x0000000000800000 ( 8.0 MB)
Minimum record version supported : 2
Maximum record version supported : 4
Write range tracking: Disabled

As you can see, the journal on my test machine is 32 MB. That means it’ll roll over very quickly; the more operations, the more quickly they get overwritten. If you can, extend the size to something more reasonable, like 1 - 4GB:

PS C:\> fsutil usn createjournal m=2147483648 a=67108864 C:

Treat USN Journal data as opportunistic corroboration rather than a prerequisite.

Shadow Copies and Backups

One of the more useful ways to use the Recycle Bin defensibly is to treat it as a stateful dataset that changes over time. If Volume Shadow Copy snapshots exist, you can often observe the $Recycle.Bin directory (among other things) at different points in time. This can answer questions that the live view can’t.

If the bin is currently empty, but a volume shadow from last week shows the relevant $I/$R pair intact, that tells you the file was in the bin at that time. It narrows the emptying window. It also allows content recovery even if the live $R is now overwritten.

Shadow copies also help in cases where you suspect anti-forensic behaviour. People often empty the Recycle Bin as a “cleanup” step without thinking about shadow copies. If the adversary hasn’t cleared VSS, it’s common to find the evidence preserved there. If they have cleared VSS, that in itself is a meaningful event to include in your narrative, because it changes what you can reasonably infer about intent.

Backups can play a similar role. A backup set that includes the file in its original location, combined with a Recycle Bin record showing it was deleted later, can be a straightforward way to prove existence and deletion timing.

Linking Deletion to Usage

Recycle Bin entries tell you that something was deleted, they don’t tell you whether it was used, viewed, or staged. This is where you pivot to user activity artefacts, without turning the analysis into a general survey. A few examples are consistently useful:

• If you have LNK files or Jump List entries referencing the original path, they support the idea that the file was opened or accessed by the user before deletion. That changes the interpretation of it was deleted into it was used and then deleted, which is a different statement.
• If you have ShellBag evidence showing navigation into the original folder or related directories, it supports interaction around that location. It will not prove the delete event; it helps you decide whether a deletion was likely deliberate and context-aware, or more like bulk cleanup.

What a Recycle Bin Finding Can Look Like

A defensible Recycle Bin finding usually looks like a small chain of facts, not a single data point. For example:

You have a $I record under a specific SID on volume D: indicating that D:\Eng\Reports\IncidentSummary.docx was sent to the bin at 2025-12-18 03:42Z, and that the original size was ~180 KB. You have the paired $R file present and the content matches that document. You have a Jump List entry showing the user opened IncidentSummary.docx around 20 minutes earlier. You have a burst of USN activity moving several files from D:\Eng\Reports\ into $Recycle.Bin\ in the same minute.

The conclusion you can support is not the user attempted to destroy evidence. The conclusion is:

This user context accessed and then deleted a set of files from a specific directory at a specific time, and the content of at least one file was recoverable from the Recycle Bin. The deletion was consistent with a bulk delete operation using shell behaviour on volume D:.

That leaves space for alternative explanations, while still being operationally useful. If you need to argue intent, you build it elsewhere and keep the Recycle Bin contribution specific.

How to Handle Partial and Unreliable States

Recycle Bin evidence isn’t binary. You will see partial and messy states. It helps to have a mental model of what each state can imply.

$I present, $R missing

This can mean:

• The bin was partially emptied (targeted deletion)
• The bin quota evicted content
• The $R content was overwritten after emptying
• You’re looking at a shadow copy or carved $I where the $R was not recoverable

In this situation, the $I still has value. It can still anchor a timeline and show original location. If the investigation hinges on content, you pivot to VSS, backups, or unallocated recovery. If it hinges on proving deletion occurred, the $I may be enough, especially when combined with corroboration like USN activity.

$R present, $I missing

This is less common, but it does happen. It can mean:

• Metadata was removed but content remained (selective anti-forensics or corruption)
• The $I was overwritten or not recovered, but $R survived
• Analysis tooling missed $I due to parsing issues or filtering

When you see this, validate your tooling assumptions first. A surprising number of “missing $I” cases are parsing or filtering problems, particularly when scripts assume an older record structure.

If the $I is truly absent, the $R still gives you content. You lose original path and deletion time, which makes attribution harder. You then pivot to NTFS metadata and context artefacts to reconstruct what you can. You may be able to infer original location from the file content itself, from embedded document metadata, or from references in LNKs and Jump Lists.

Empty Bin, but Strong Suspicion of Deletion

This is where people often stop too early. If you’re investigating likely deletion, “empty” should push you toward:

• VSS snapshots of $Recycle.Bin
• Unallocated recovery of $I remnants (paths and timestamps can survive even when content doesn’t)
• USN journal windows around the suspected time
• Evidence of bin configuration changes or cleanup tooling

This is also where you should be careful about claiming anti-forensics. Users empty bins for benign reasons. Attackers empty bins for benign reasons too, because it’s “cleanup.” Your job is to describe what happened and what you can show, not to label intent based on a single pattern.

A Note on Anti-Forensics and “Cleaning” Behaviour

Recycle Bin cleaning is common, and not always sophisticated.

A user emptying their bin after being asked for documents can be suspicious, but it can also be routine. An adversary using a secure deletion tool to wipe the bin is more suggestive, but it’s still not definitive without context.

The more reliable way to treat this is:

• Recycle Bin artefacts support delete-to-bin happened
• The absence of artefacts supports delete-to-bin may not have happened, or may have been removed
• Evidence of deliberate removal of shadow copies, cleaning tool execution artefacts, or systematic wiping increases the plausibility that deletion was intended to reduce recoverability

Each of those is a separate evidentiary step. Keep them separate in your write-up.

Using the Recycle Bin Without Over-Trusting It

Recycle Bin artefacts are valuable precisely because they’re narrow. They can tell you that a deletion occurred, under a specific user context, on a specific volume, at a specific point in time, and sometimes allow you to recover the deleted content itself. They become misleading when treated as a complete record of deletion activity, or when absence is interpreted as proof.

Used carefully, the Recycle Bin works best as an anchor point in a broader narrative: a moment in time you can pivot around, corroborate, and challenge with other artefacts. Used carelessly, it encourages overconfidence.

In the next post, we’ll look at ShellBags, which address a complementary question the Recycle Bin can’t answer: not what was deleted, but what locations a user interacted with. Together, these artefacts often provide a more coherent picture of user behaviour than either does in isolation.

References

1. Digital Forensics: Discovering Threat Actor’s traces using Recycle Bin - Conscia
2. Windows Recycle Bin Forensics: Dumpster Diving for Evidence - MCSI Library
3. Digital Forensics: Artifact Profile - Windows Recycle Bin - Magnet Forensics - Magnet Forensics
4. Windows Recycle Bin Forensics. The Recycle Bin - Medium
5. Recycle.Bin Timestamp – General (Technical, Procedural, Software, Hardware etc.) - Forensic Focus Forums
6. Where’s the Recycle Bin on My USB Drive? - Ask Leo!
7. $Recycle.Bin Forensics for Windows 7 and Windows Vista Shadow Volumes - Timothy R. Leschke