When Was the Recycle Bin Emptied?

One of the most common questions we get from clients goes something like:

"Can you tell us when our subject emptied their Recycle Bin? And whether any of the deleted items are recoverable?"

It sounds like a yes/no question. It almost never is. Windows keeps no permanent log of Recycle Bin operations. There is no "Bin Emptied at 3:42 PM" line anywhere on the disk. Answering the question means correlating several lower-level NTFS artifacts, each with its own retention behaviour and its own quirks.

What follows is how we work it on a typical Windows forensic image, and where the limits sit.

What Windows actually stores

When you press Delete in File Explorer, two things happen inside the hidden C:\$Recycle.Bin\<SID>\ folder for your user account:

1. The original file is renamed to $R<6 random chars><extension>.
2. A small companion file $I<same 6 chars><extension> is created, holding the file's original full path, original size and deletion timestamp.

So recovering something from the bin means finding the $I file, which tells you what the file used to be, then pairing it with its $R sibling, which holds the actual data. When the user clicks Empty Recycle Bin, both files are deleted from disk and the $I/$R pair vanishes.

That last part is the whole basis for this work. At the filesystem level, a Recycle Bin empty looks like a normal file delete on a batch of $I and $R files within milliseconds of each other. That is the fingerprint we hunt for.

There is usually more than one bin

Every Windows account on a machine gets its own bin folder under C:\$Recycle.Bin\, named after the user's Security Identifier. On a typical machine you will find folders for:

• The current human user (RID 1001)
• The local Administrator account (RID 500)
• The SYSTEM account (S-1-5-18)
• And sometimes leftovers from prior installs, OS resets or migrations

A SID looks like S-1-5-21-XXXXXXXX-XXXXXXXX-XXXXXXXX-RID. The three middle numbers identify the machine that originally created the account. If a bin folder's machine portion does not match the current Windows install's machine SID, that bin came from somewhere else, typically a backup, a Geek-Squad-style data transfer, or a folder dragged in off an external drive.

On one recent case we found eight distinct bin folders on a single image, spread across two parent locations. The largest held over five thousand items and sat inside a third-party data-transfer folder, and every one of its internal deletion timestamps fell inside a seven-minute window from years earlier. That is a one-time bulk migration on a prior PC, not ongoing activity on the imaged machine. Without the machine-SID check we would have reported five thousand deletions that never happened on the computer in question.

So before counting anything, work out which bin belongs to which install. The machine portion of the SID is what tells you.

"Did they empty it?" — the easy half

If items sitting in the live bin have deletion timestamps older than any suspected empty event, then no full empty has occurred since the oldest surviving item went in. A real Empty Recycle Bin operation wipes everything in one atomic pass. It cannot selectively spare older items.

So the first thing we check is the oldest surviving $I file. Whatever date that carries sets a hard floor: the bin has not been fully emptied since then. This costs nothing and it often answers the client's question on its own.

What it cannot tell us is whether anything happened before that floor. For that we go to the journals.

The USN journal, where empty events actually live

NTFS maintains a Change Journal at \$Extend\$UsnJrnl:$J. Every file create, delete, rename and security change on the volume gets logged there with a microsecond-precision timestamp. It is the single best place to spot a Recycle Bin empty.

To get it off a forensic image you can either pull it from your AXIOM (or X-Ways, FTK, etc.) File System Explorer view, making sure to grab the $J alternate data stream specifically rather than just the $UsnJrnl container, or carve it out with a low-level tool. The raw file often runs to several gigabytes on a busy disk.

We parse it with Eric Zimmerman's MFTECmd, which does parse USN despite the name, using the -f flag. The output is a CSV with one row per change record. To find an empty event we filter for:

• Name starting with $I or $R
• UpdateReasons containing FileDelete | Close
• Multiple such records sharing the same sub-second timestamp under the same parent folder

A burst of four FileDelete | Close records on $IXXX/$RXX pairs all landing at, say, 17:42:57.145 is an empty event. Or a "delete selected items from bin" operation, which brings us to the next part.

The trick you have to know about

A targeted "delete these specific items from inside the bin" looks almost identical in the USN to a full Empty Recycle Bin. Same FileDelete | Close records on $I/$R files, same sub-millisecond burst.

You tell them apart by checking what did not get deleted. If older items in the bin survived the burst, it was not a full empty, it was selective. The user opened the bin window, highlighted a few items and pressed Delete. A true Empty would have taken the older $I/$R files too.

We have had cases where this distinction mattered enormously. A targeted bin delete suggests the user was specifically getting rid of two or three particular items. A full empty suggests routine housekeeping, or active destruction. Same forensic fingerprint, very different narrative.

Recovering the original filename

Once a $I/$R pair is purged, the original filename and path are no longer obvious. But the USN journal also recorded the rename operation that moved the file into the bin in the first place. Look up the MFT entry number of the $R file in the USN, find the RenameOldName record on the same entry, and there is your original filename. Cross-reference the ParentEntryNumber against the parsed $MFT and you have the original folder path too. This still works long after the bin entry itself is gone.

What about $LogFile?

The NTFS $LogFile is the transaction log used for crash recovery. It records the same kinds of operations as the USN journal, but it is much smaller and often retains only minutes to hours of activity. On a recent image we examined, the entire $LogFile covered a 38-minute window.

It can corroborate something the USN journal already shows. It almost never adds history the USN journal does not have. We extract and parse it every time, and we do not lean on it.

When the $MFT helps, and when it doesn't

When $I and $R files are deleted on an empty event, their Master File Table records get marked free. Until those records are reused by some other file, they still carry the $I/$R filename and the timestamps recording when they were purged.

In practice, on a busy Windows install that has been running for months, freed MFT records get reused fast. On a recent case we saw more than 70,000 freed MFT records and not one of them held a recognizable $I/$R entry. Subsequent file activity had claimed all of them. The trail was gone.

On a quieter machine, especially a fresh install or a single-user workstation that has not seen much activity since the empty event, the $MFT can yield gold. It is always worth checking.

Volume Shadow Copies, when they exist

If Windows System Protection was enabled on the source machine, Windows periodically takes Volume Shadow Copies, which are frozen snapshots of the entire filesystem. Each VSC holds a copy of $Recycle.Bin as it stood at the moment of the snapshot. Comparing bin contents across VSCs brackets empty events directly:

"On the snapshot from April 12, the bin contained items A, B, C. On the snapshot from May 20, the bin was empty. Therefore an Empty Recycle Bin event happened between those dates."

Nothing else reaches back in time this cleanly.

The catch is that on most modern consumer Windows installs, System Protection is off by default. We confirm this by checking \System Volume Information\SystemRestore\ on the imaged volume. If there is nothing in there but FRStaging, you have no shadow copies. It is also worth querying the forensic suite's case database directly, via SQLite on AXIOM's Case.mfdb, to enumerate every VolumeShadowCopy-typed source the tool indexed. It is fast, and it tells you whether you are chasing something that exists.

When there are no VSCs and the USN window does not reach far enough back, the answer to "when was it emptied before [date]?" becomes: we cannot determine that from this image. That is a property of the source data rather than a failure of the examination. A good report says so explicitly, lists the four artifacts examined, and explains what each one would have shown if the data had been there.

Where recovered emails fit in

Clients often conflate the Windows Recycle Bin with their email client's Deleted Items folder. These are completely separate systems. Deleting an email in Outlook, Thunderbird or Windows Live Mail sends it to the email app's internal trash, not to C:\$Recycle.Bin\. Emptying email trash is a different operation entirely.

So when the question is "are deleted emails recoverable?", we answer for both interpretations:

• From the Windows Recycle Bin: usually not, because most users do not drag individual emails to Explorer's bin. The exception is people running file-based mail stores, since Windows Live Mail keeps each email as a separate .eml file, who might have deleted a whole mail folder.
• From the email client's Deleted Items: it depends on the client. Outlook PST/OST files retain hard-deleted items in internal free pages until the store is compacted, and AXIOM, FTK and similar tools surface these automatically. Webmail like Gmail or Outlook.com keeps deleted messages server-side, so there is nothing local to recover beyond browser cache.

A subject who appears to have no emails on their local machine often has not lost anything. They are a webmail user. Confirm whether there is a local PST/OST or a mail-folder structure before promising anyone email-recovery results.

The short version

1. Identify every bin folder on the image and check the machine portion of each SID. Do not count a backed-up bin as live activity.
2. Compare the oldest surviving item to the suspected empty date. That alone often answers the question.
3. Pull $UsnJrnl:$J and grep for FileDelete | Close on $I/$R filenames. That is where empty events live.
4. Distinguish targeted deletes from full empties by checking what survived.
5. Try $MFT for deleted $I/$R records. Works on quiet machines, fails on busy ones.
6. Check for VSCs by inspecting System Volume Information\SystemRestore\ and the case database. If they exist you can reach back months or years.
7. Be honest about the boundary. NTFS journals have finite retention. If the data is not there, say so, and explain which artifact would have told you and why it didn't.

Producing dates is not always the most valuable thing a forensic report can do. Sometimes it is credibly establishing which dates are knowable and which are not. That is what separates a report that holds up in front of a tribunal from one that gets picked apart.

---

Data Rescue Labs performs Windows, macOS and mobile forensic examinations for law firms, corporate clients and law-enforcement agencies. If you have a question about what's recoverable from a device, our Computer Forensics and Litigation Support teams handle this work. Open a case for a privileged consult.