Match external eSAT...
 
Notifications
Clear all

Match external eSATA drive to drive letter and/or file paths

9 Posts
4 Users
0 Likes
1,230 Views
(@stevegut78)
Posts: 44
Eminent Member
Topic starter
 

Hi all. I am stuck on case which is pretty much completed but I want to do some due diligence.

BACKGROUND
Basically, user was flagged on a corporate network having Tor.exe. McAfee HBSS logs all show entries pointing to E\…. for Tor.exe not to mention a slew of .torrent files. From the file paths listed in the HBSS logs, it looks as if the user was backing up personal computer data which included these prohibited files. User took off and returned the next day to hand in the approved eSATA external drive, presumably the E\.

Of course the drive was wiped/formatted. I imaged and analyzed using FTK Imager and FTK 6.3. The drive is basically empty, although it is formatted NTFS and contains an elaborate folder structure but no files except occasional temporary files "~filename.tmp", etc. Also, most of the MAC times for the folders and files are identical or within seconds of each other. $MFT, System Volume Information, all have the same MAC times. I think it's safe to say this is when the drive was formatted? Also, when viewing the drive in raw disk mode, most of the drive shows hex data as 00's. So I'm betting he zero'd out the drive on his own computer when he took the drive home, formatted and then copied over some folders but not the data to make it look like the drive was being used.

Using AccessData Registry Viewer, I was able to identify 2 hard drives in the Controlset\Enum\IDE. 1 is positively the laptop hard drive with the OS, the other is unknown and NOT the external eSATA he returned.

Under Controlset\Enum\SCSI I found the eSATA drive (verified the model of the drive that is in the enclosure).

NOTE USB drives are blocked via GPO so no entries under Controlset\Enum\USBSTOR

Now my question/problem
I know the eSATA drive was most likely wiped. But I'm not sure if the other mystery hard drive could be the one that contained the prohibited files. Who's to say that he wasn't connecting an unapproved (personal) hard drive and took that home but also wiped and copied back some empty folders to the company provided eSATA?

I know the evidence is pretty strong to show some conscious effort to destroy evidence after he knew he was flagged, but it would be just that more compelling to be able to say exactly which drive had the prohibited files on them.

Hope to get some insight, I've been mulling over ideas for the last few days but could use a fresh set of ideas.

Thanks

 
Posted : 22/01/2018 3:38 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Check the MountedDevices key
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

for the Disk Signature of the disk.

If there is still trace of it in the key and the disk has not been actually re-initialized but only re-formatted you can reasonably state that it was the same disk.

jaclaz

 
Posted : 22/01/2018 7:56 am
(@stevegut78)
Posts: 44
Eminent Member
Topic starter
 

Thanks for that info. I had that on my list of things to check when I got in the office. The only thing I see under Mounted Devices is C D E.. When I look at DosDevices there is nothing identifying this external HD. I only see is information identifying the CD ROM.

I did find some interesting data under SYSTEM\ControlSet001\Enum\SCSI\Disk&Ven_HGST&Prod__HUS724030ALE640. This is the external drive in question. There are 2 subkeys off of this, I'm assuming for the partitions? There is a subkey "Partmgr" under each one of the subkeys with an entry "DiskID" that contains a UID. Would this be a Volume identifier?

I was able to find entries for the DiskId UID all over the system, (windows event logs, setupapi.log to name a few). I will continue to research but not sure if this is a dead end if that Disk ID is not something associated with the actual disk and maybe just a ID for device class or something. Will be going through the search results of the DiskID to determine if this is a positive identifying bit of data or not. If anyone knows, that would help.

Thanks

 
Posted : 22/01/2018 5:44 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Thanks for that info. I had that on my list of things to check when I got in the office. The only thing I see under Mounted Devices is C D E.. When I look at DosDevices there is nothing identifying this external HD. I only see is information identifying the CD ROM.

No, there is some information, but it needs to be interpreted (and it may or may not be useful).

You see BOTH a key named *like*
\DosDevices\E
and one named *like*
\??\Volume{b0b284c4-8a33-11dd-8781-806d6172696f}

with the SAME value (binary) *like*
A3 DC 81 FB 00 7E 00 00 00 00 00 00

Each of these gives you some information.
The name \DosDevices\E tells you that a volume was mounted and assigned a drive letter (E in this case).

In the binary value
The A3 DC 81 FB is the Disk Signature (and you can check if it matches the one in the MBR of the disks that you presume have been connected to the machine )

The 00 7E 00 00 00 00 00 00 is actually 0x0000000000007E00 and is the offset in bytes (32256 in this case) to the start of the partition/volume that gets the drive letter (E in this case).

The name \??\Volume{b0b284c4-8a33-11dd-8781-806d6172696f} is a "GUID" or "UUID" (v.1) and can be decoded
b0b284c4-8a33-11dd-8781-806d6172696f
in the example decodes to

C\>uuid.exe -d b0b284c4-8a33-11dd-8781-806d6172696f
encode STR b0b284c4-8a33-11dd-8781-806d6172696f
SIV 234871048948522598704125441647825807727
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2008-09-24 122410.343750.8 UTC
clock 1921 (usually random)
node 806d6172696f (global unicast)
so, the volume in the example has been assigned the UUID (i.e. it was first connected to the machine and detected by the OS on, or in any case no earlier than)
2008-09-24 122410.343750.8 UTC

See also (the date/time may be cached, so not necessarily accurate, only indicative)
https://www.forensicfocus.com/Forums/viewtopic/t=15925/
https://www.forensicfocus.com/Forums/viewtopic/t=15034/

The contents of the binary only apply to "fixed disks" (actually what Windows sees as "fixed" and includes USB connected disk drives but not - with some exceptions - for USB sticks and similar that are usually "removable").

Such removable media, as well as CD-ROM's and similar have a much longer binary value easily recognizable because it begins with either 5F 00 3F 00 or 5C 00 3F 00.

jaclaz

 
Posted : 23/01/2018 5:29 pm
(@stevegut78)
Posts: 44
Eminent Member
Topic starter
 

Wow! Thanks so much for this very clear explanation; it helped tremendously. I was able to figure it out and also was able to analyze some LNK files which also provided Path and volume name that matched with the paths in the HBSS logs to further bolster my case. This one looks like a slam dunk, and shows that the user purposely wiped the drive before handing it over. I love being able to connect the dots and outsmart people who think they're slick )

 
Posted : 23/01/2018 11:29 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Wow! Thanks so much for this very clear explanation; it helped tremendously.

You are welcome , happy ) it was useful.

jaclaz

 
Posted : 24/01/2018 12:11 pm
Bunnysniper
(@bunnysniper)
Posts: 257
Reputable Member
 

…. was able to analyze some LNK files which also provided Path and volume name that matched with the paths in the HBSS logs to further bolster my case.

2 hints found any prefetch files (*.pf) indicating the use of tor.exe? Or evidence in the UserAssist key? I would have a look at it…..

best regards,
Robin

 
Posted : 24/01/2018 12:43 pm
(@mickarneke)
Posts: 53
Trusted Member
 

"…so, the volume in the example has been assigned the UUID (i.e. it was first connected to the machine and detected by the OS on, or in any case no earlier than) 2008-09-24 122410.343750.8 UTC"

Actually, the exact interpretation of this artifact is

"First time device was connected AFTER LAST reboot."

)

 
Posted : 01/02/2018 2:38 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

"…so, the volume in the example has been assigned the UUID (i.e. it was first connected to the machine and detected by the OS on, or in any case no earlier than) 2008-09-24 122410.343750.8 UTC"

Actually, the exact interpretation of this artifact is

"First time device was connected AFTER LAST reboot."

)

Not really 😯 , it is ""First time device was connected AFTER LAST reboot." ONLY IF it wasn't ever already connected before last reboot or IF - by sheer coincidence - another device with the SAME Disk Signature (and same ofset to the partition) was never connected before last reboot.
As said it is NOT exact science, there are a number of possibilities.

With most PC's (both "work" and "home", that are rebooted at least daily, it is usually at least the "right" day, but there is no guarantee in itself about the validity of the date, time belonging exactly to the time the device is connected, the only thing you can be sure is that no device with the same disk signature and partition offset has been connected EARLIER THAN that.

And still this assumes a computer with ALWAYS the correct date/time in BIOS and/or using Network time, though even if the latter is used, most probably a "wrong" date/time is updated or corrected after a new connected at boot device is enumerated.

jaclaz

 
Posted : 01/02/2018 4:48 pm
Share: