← All docs

Recycle Bin SID subfolders explained

2 min read

Open C:\$Recycle.Bin on a workstation image and you see a handful of folders with long, structured names:

S-1-5-21-3623811015-3361044348-30300820-1013
S-1-5-21-3623811015-3361044348-30300820-500
S-1-5-18

Each one is a Windows Security Identifier. Windows partitions the bin per user so that no account can see another's deleted files (and so the shell can compute per-user quotas). For an investigator, that partitioning is the cleanest possible attribution.

Reading a SID

S-1-5-21-3623811015-3361044348-30300820-1013
| | |  |                                  |
| | |  |                                  └─ RID (the specific account)
| | |  └─ subauthority 3: machine / domain ID (machine SID on a workstation)
| | └─ authority 5 (NT Authority)
| └─ revision 1
└─ literal "S"

What you actually care about per RID:

  • 500 — built-in Administrator.
  • 501 — Guest.
  • 1000+ — regular accounts created over time. Lower RIDs were created earlier; 1000 is the first non-default user.
  • S-1-5-18 — LocalSystem.
  • S-1-5-19 — LocalService.
  • S-1-5-20 — NetworkService.

A $I under S-1-5-18 means a SYSTEM-context delete. That is not a normal user action — usually a scheduled task, a service, or something running as SYSTEM that does not have a desktop session.

Mapping a SID to a user

From the registry (works against a dead image):

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>
  ProfileImagePath = C:\Users\<username>

The registry parser renders this hive cleanly. On a live host, wmic useraccount get name,sid or the PowerShell Get-LocalUser | Select Name,SID does the same job. For domain accounts, the local SOFTWARE hive only resolves users who have logged in at least once. For the rest, you need the domain controller's record or Get-ADUser.

Why this is strong attribution

A $I file in S-1-5-21-…-1013 was written under that account's logon session. Combined with the FILETIME deletion timestamp, you have:

  • Who — the SID owner.
  • What — the original path and size from the $I.
  • When — UTC to the second.

That triplet, corroborated against a 4624 logon in the same window, is about as direct as Windows attribution gets.

When the attribution gets noisy

  • Roaming profiles or RDS hosts. Multiple users hit the same volume. Read the SID, do not assume "the obvious user".
  • RunAs and impersonation. A user can hold tokens for other accounts. A delete under SID X could in principle be initiated by user Y via runas. Cross-check with the EVTX 4648 (explicit-credential logon).
  • Account deletion. A SID whose ProfileList entry is gone still shows up as a folder. The RID is unique forever; if the user was deleted you may need a backup hive to resolve it.

Further reading

Frequently asked questions

Why does $Recycle.Bin contain folders named S-1-5-21-...?
Each subfolder is a user's Security Identifier (SID). Windows isolates each user's deleted files in their own SID folder so users can't see each other's recycled items.
How do I find which user a SID belongs to?
Run 'wmic useraccount get name,sid', check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList in the registry, or use PsGetSid / 'Get-LocalUser' in PowerShell.
What does the S-1-5-21 prefix mean?
S-1-5-21 marks a domain or local machine account. The digits after it are the machine/domain identifier, and the final RID (e.g. -1001) identifies the specific account; 500 is the built-in Administrator.
Can SID folders attribute a deletion to a user?
Yes. A $I file inside a given SID folder was created by that user's session, which is strong attribution evidence in an investigation.