EMDMGMT query

The final numbers should be the (converted to decimal) value of the volume serial, i.e. there should be an entry in EDMGMT for each volume on a multipartitioned device.
http//hatsoffsecurity.com/2014/06/08/usb-forensics-pt-4-volume-serial-number/

When you re-format the volume a new serial is created, so it is normal that a new key is generated.

As well it is (or should be) normal that if you change the label of a volume the key is re-generated, as the "middle part" of the name should be the volume label, but it is possible that the serial is "prevalent", i.e. that Windows does not re-probe (or does not re-probe always) for the volume label if the volume serial key is already present. ?

I have not been able to find documentation on how exactly the leading part of the name (the "VAG___" or "DX_Q__" in your example) is generated, though. oops

jaclaz

The final numbers should be the (converted to decimal) value of the volume serial, i.e. there should be an entry in EDMGMT for each volume on a multipartitioned device.
http//hatsoffsecurity.com/2014/06/08/usb-forensics-pt-4-volume-serial-number/

When you re-format the volume a new serial is created, so it is normal that a new key is generated.

Agreed and understood

As well it is (or should be) normal that if you change the label of a volume the key is re-generated, as the "middle part" of the name should be the volume label, but it is possible that the serial is "prevalent", i.e. that Windows does not re-probe (or does not re-probe always) for the volume label if the volume serial key is already present. ?

That's the bit I've struggled to reproduce on my system. Specifically in the last two working days I've connected two different Seagate Backup Plus drives, it appears however that a new EMDMGMT sub-key does indeed get created if you re-name the volume, but only after the first time you re-connect the device after having renamed the volume - and the VSN stays the same.

That's based on very limited testing )

Cheers

OMG this is weird.

To arrive at the previous conclusion "but only after the first time you re-connect the device after having renamed the volume" clearly I had to remove the USB drive to re-connect it (not safely though!!)

The timestamp on the new sub-key wth the new volume name is timed BEFORE when I re-connected it! I used the Date/Time control panel to ensure that I didn't re-connect it until shortly after 1339, the new subkey has a last-write time of 133834.

I then re-named, safely removed, and re-connected. Sure enough, new subkey with date/time of re-connection

Then renamed, unplugged, and didn't re-connect - no new sub-key created

And lastly re-connected - new subkey created with the correct timestamp

So how the time of 133834 was created I have no idea.

That anomaly apart, it looks as if a new sub-key isn't created until you re-connect the drive.

I haven't tested (a) using different USB ports or (b) creating and analysing LNK files at all the above stages

HTH

Cheers

Specifically in the last two working days I've connected two different Seagate Backup Plus drives, it appears however that a new EMDMGMT sub-key does indeed get created if you re-name the volume, but only after the first time you re-connect the device after having renamed the volume - and the VSN stays the same.

Yep, this also sounds "logic".
I mean the ID of a volume should be "primarily" connected to the volume serial, so it would be logic that only a label change wouldnt trigger by itself (unlike a re-format) a key change until the thingy is re-scanned (i.e. removed and inserted again or the machine rebooted).

It is very likely that either the formatting or the mount manager/mountvol "notifies" across all subsystems the volume serial change, whilst the "label" change has not the same kind of "dignity".

What would be interesting would be changing the volume serial through "direct disk access" (i.e. simply hexediting with a disk editor or dding a new number in the bootsector) and whether the "untold" part of the NTFS volume serial is in any way connected ? (the last part of the key is the "short" version of the volume serial such as VOL or FSUTIL
http//www.forensicfocus.com/Forums/viewtopic/t=11250/
http//reboot.pro/topic/19698-how-to-get-uuid-of-an-imdisk-mounted-drive-image/

jaclaz

Thanks Jaclaz

Going back to the theory that the leading characters / prefix could lend some historical context, does anyone out there have any ideas as to the worth or otherwise of this theory?

Cheers

Going back to the theory that the leading characters / prefix could lend some historical context, does anyone out there have any ideas as to the worth or otherwise of this theory?

I didn't see any when I was performing my own research, nor was I able to determine any value from what I saw, or from testing.

I guess I'm still interested in what you were able to determine with respect to the goals of your exam…specifically, to look for files accessed on the E\ volume.

Did you look at and find anything in shellbags? TrustRecords? Anything beyond LNK files and Jump Lists?

I didn't see any when I was performing my own research, nor was I able to determine any value from what I saw, or from testing.

Maybe there's value in mentionining the lack of concrete evidence in a part of an artefact?

I guess I'm still interested in what you were able to determine with respect to the goals of your exam…specifically, to look for files accessed on the E\ volume.

Did you look at and find anything in shellbags? TrustRecords? Anything beyond LNK files and Jump Lists?

ShellBags - yes but very little to move forward with
TrustRecords - am not familiar with them (
Other sources - some bits and pieces from Event Logs showing connection of USB devices which I can use, which in a timeline comes before (but not immediately before) E file access but nothing so far to tie the "VAG___Username" volume name to anything.

So at the mo I think all I can say is that a device with volume name xx had files accessed on it on xx date/times by user account nnnn

There are other USB devices with last connection dates, I can mention them in the report as well but no file access ties that I can see to them apart fom a very few which I can tie up via VSN in LNK/JumpList matching EMDMGMT

Thanks for your input guys, and for the research and documentation which helps make life a little easier for guys like me )

Cheers

Other sources - some bits and pieces from Event Logs showing connection of USB devices which I can use, which in a timeline comes before (but not immediately before) E file access but nothing so far to tie the "VAG___Username" volume name to anything.

I guess that can be frustrating, particularly when you're pursuing a line of analysis that others are saying, "hey, you're not likely to find anything down that road…". No harm in trying, I suppose, but there are those who have gone down that road already, have "been there, got the t-shirt", and found nothing, particularly nothing of value.

I will say that you can definitively tie the device information you found in the EMDMgmt subkey to the USB device information in the system hive, using the unique instance ID, NOT the volume name or volume serial number. This has been published a number of times, by a number of different people…I'm not saying that it's 100% correct, but others have found it to work.

So at the mo I think all I can say is that a device with volume name xx had files accessed on it on xx date/times by user account nnnn

Based on what you'd said in your second post, I understood that to be the goal of your exam.

There are other USB devices with last connection dates, I can mention them in the report as well but no file access ties that I can see to them apart fom a very few which I can tie up via VSN in LNK/JumpList matching EMDMGMT

To me, with the admittedly limited and narrow view of your case that I have, my thoughts are that this would simply be confusing to whomever will be reading the report. If you have a USB device that you're interested in, and you can identify it by it's unique instance ID (which _may_ be the serial number of the device…again, this information has been published repeatedly), and you know the volume to which it was mounted, and your client simply wants to know which files on that external device were accessed by the user…well, it's pretty easy. With an image of the system, all of that can be determined in well under 4 hrs. Checking the file system and Registry locations that you already have checked, and throwing in others, such as application MRUs, you should have a pretty solid bit of information.

[quote="keydet89]To me, with the admittedly limited and narrow view of your case that I have, my thoughts are that this would simply be confusing to whomever will be reading the report. If you have a USB device that you're interested in, and you can identify it by it's unique instance ID (which _may_ be the serial number of the device…again, this information has been published repeatedly), and you know the volume to which it was mounted, and your client simply wants to know which files on that external device were accessed by the user…well, it's pretty easy. With an image of the system, all of that can be determined in well under 4 hrs. Checking the file system and Registry locations that you already have checked, and throwing in others, such as application MRUs, you should have a pretty solid bit of information. Harlan, I think I understand where to get all that information, and while ordinarily it may take me more than 4 hours, in this case I just can't see at all where I can get the unique instance ID for a device which I can link to "VAG___UserName", which is the only E device referred to by LNK and JumpList files.

Cheers

…I just can't see at all where I can get the unique instance ID for a device which I can link to "VAG___UserName", which is the only E device referred to by LNK and JumpList files.

Sorry, that was my mistake. Somewhere along the way, I thought I'd seen mention that this was a USB thumb drive…going back to your original post, it's clearly a USB external drive enclosure, and won't have a unique instance ID in the EMDMgmt subkey name. Sorry about that.