Strange recycle bin files

I am sketchy on this, but from EDD work I have done on recycle bins, the files in the recycle bins are simply pointers to the original file.
There fore, that files original location was C\"Suspect Name"\To Do.doc. Therefore looks like the employee was breaking policy.

However I would prefer someone to check me on that.

From memory, this looks like a classic case of software tools being overly helpful, and giving out misleading information.

Again, from memory, when a file gets deleted on NTFS, it is MOVED to the recycle bin, into the user's relevant SID sub-folder, (in your case, the S-1-5-21-3750935238-4294770906-241084290-1135 sub-folder).

The file and filenames get changed as follows

$I[XXXXXX] file - contains data about the original file
$R[XXXXXX] file - the ACTUAL file

What FTK (and EnCase) seem to do is point you to the original location, which is not correct anymore, it merely tells you where the file was when it was deleted.

To be clear this file is NOT deleted, it is accessible, and it is located within the recycle bin on the specified partition, NOT deleted and in its original location as provided by FTK.

From the SID above, the user account identified in the registry as 1135 is responsible for deletion of this file, so I would suggest registry (SAM file) examination to determine which named user is assigned to this account number.

Hope this helps

Ben

hmm. check me on this but

Archived from groups microsoft.public.windowsxp.general (More info?)

=?Utf-8?B?TGVwZXI=?= wrote
>
> Is there a way to make a copy of all files put into recycle bin or deleted?
> Like a dual target directory. Just some way to automatically have a backup
> copy of any thing deleted. Something like shadow copy does i guess. What I am
> asking is, if a file is moved to the recycle bin, can another copy be put
> somewhere else automatically. Like in another " second chance" folder.

Files ARE NOT MOVED TO THE RECYCLE bin. A pointer is simply made there
so if you decide to empty the bin the pointer then finds the file to
delete.
http//www.tomshardware.com/forum/56414-45-copy-recycle-files

Dug out my old course notes 😉

When a file goes to recycle bin

File remains current
Short name (if present) is lost - replaced with new short name derived from logical drive and record number (for XP/INFO2 based recycle bins)
INFO2 updated to show date/time of deletion
Reference to file in original folder's tree list is removed - this is the key bit; the file has effectively undergone a MOVE procedure.

The INFO2 (or $I files on Vista/7) contain the data that makes it possible to put it back where it was.

The publicly held MS explanation is an oversimplification to the point of actually getting it wrong

I guess the problem is, as often happens of linguistical nature, whenever you use the (good ol' DOS command) MOVE command - unless the target destination is another volume, nothing is moved but the pointer to it.

Meaning that the actual bytes occupy exactly the same sectors on the hard disk as they did before.

From the mouth of the wolf
http//support.microsoft.com/kb/136517/en-us

The change appears to have happened with Vista
http//en.wikipedia.org/wiki/Recycle_Bin_(Windows)
rifiuti
http//www.foundstone.com/us/resources/proddesc/rifiuti.htm
and
rifiuti2
http//code.google.com/p/rifiuti2/

are always something worth a try.

OT, but not much
http//www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=5150

jaclaz