Notifications
Clear all

EMDMGMT query

21 Posts
4 Users
0 Likes
2,428 Views
(@cults14)
Posts: 367
Reputable Member
Topic starter
 

Query on EMDMGMT

I'm looking at a system where a device is listed in EMDMGMT, parsed using Harlan's emdmgmt v.20120207 it looks like this
UserName VPC
LastWrite Thu Nov 21 015917 2013 Z
VSN E09B-7A77
LastTestedTime Thu Nov 21 015917 2013 Z

Where UserName happens to be the user's last name

The key is
SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\VAG___UserName VPC_3768285815

"VAG", "VPC" and "3768285815" don't turn up anywhere else in the Registry (as keys at least), and don't appear in any other USB artefacts that I've parsed so far, in RegRipper have used these
usbstor v.20080418
usbdevices v.20120522
mountdev2 v.20120403
mp2 v.20120330
emdmgmt v.20120207
removdev v.200800611
devclass v.20130630

It also doesn't appear in setupapi.dev.log

It's unsettling as the device appears when I parse LNK files and Jumplists, with Mod dates ranging from 22nd March 2014 to 21st May 2014

The user is no longer with the company, having joined a competitor.

Can anyone suggest why this might be happening? The user had Virtual Box installed on his Win7 Enterprise SP1 system, I have no experience with this (and very little with Virtual Machines in general), but as I don't have his network login password I beleive I can't build a VM using LiveView?

Cheers

 
Posted : 13/08/2014 9:30 pm
(@cults14)
Posts: 367
Reputable Member
Topic starter
 

Forgot to add, it always appears as Drive E

 
Posted : 13/08/2014 9:32 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

Can anyone suggest why this might be happening?

Why what is happening? Are you referring to this…

"VAG", "VPC" and "3768285815" don't turn up anywhere else in the Registry

I wouldn't expect them to.

What is it that you're attempting to determine? Are you simply wondering why those keywords don't seem to appear anywhere else in the Registry, or was that search part of an attempt to determine something else?

The user had Virtual Box installed on his Win7 Enterprise SP1 system, I have no experience with this (and very little with Virtual Machines in general), but as I don't have his network login password I beleive I can't build a VM using LiveView?

I'm not clear on why you'd need their login…what are you trying to do? If the issue is determining what they did in any VMs they have installed in Virtual Box, just analyze them as you would any other image file…

 
Posted : 14/08/2014 2:19 am
(@cults14)
Posts: 367
Reputable Member
Topic starter
 

I wouldn't expect them to.

What is it that you're attempting to determine? Are you simply wondering why those keywords don't seem to appear anywhere else in the Registry, or was that search part of an attempt to determine something else?

Am looking for evidence of data files accessed on external media. So looking for anything not on C and also not on S which is a network share. E - with Volume Label "UserName VPC" with VSN E09B-7A77 crops up frequently in LNK and JumpLists, I want to know what it is. In the RegRipper plugins I ran, the only place in Registry that this Volume Label appears is in EMDMGMT. David Cowan says here http//hackingexposedcomputerforensicsblog.blogspot.co.uk/2013/08/daily-blog-65-understanding-artifacts.html that EMDMGMT "…. can be very helpful when you are trying to understand why a device you know was accessed does not appear in the USBStor". So, as this device didn't appear in any of the "usual" locations where one would track USB history (see earlier list of RegRipper plugins), I ran registry-wide searches in keynames to see if it cropped up anywhere else that I wasn't accustomed to (it doesn't appear in this particular setupapi.dev.log, but it's not reliable as the first dated Boot Session after BootLog post-dates many other artefacts, and some USB dvices don't appear there either (although they do appear in the "usual" places in Registry).

I've now run a registry-wide search for "VPC" and the only other place it appears is under SOFTWARE\Microsoft\Windows Search\VolumeInfoCache
E and F, both of which have values and data of
DriveType 0x00000003 (3) and is REG_DWORD
VolumeLabel "UserName VPC" and is REG_SZ

FYI C thru I are listed under this key, all have same DriveType values, VolumeLabel for C is System, D is TestOS, G thru I are (value not set)

I don't know what to make of this, can't find much about volumeinfocache or what options there are for DriveTypes

I'm not clear on why you'd need their login…what are you trying to do? If the issue is determining what they did in any VMs they have installed in Virtual Box, just analyze them as you would any other image file…

Not sure what you mean here, my only previous attempts at looking at VMs have been trying to boot a VM using LiveView, which as far as I recall needs the user's logon password (which I never have).

HTH

 
Posted : 14/08/2014 3:38 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

In the RegRipper plugins I ran, the only place in Registry that this Volume Label appears is in EMDMGMT. David Cowan says here http//hackingexposedcomputerforensicsblog.blogspot.co.uk/2013/08/daily-blog-65-understanding-artifacts.html that EMDMGMT "…. can be very helpful when you are trying to understand why a device you know was accessed does not appear in the USBStor". So, as this device didn't appear in any of the "usual" locations where one would track USB history (see earlier list of RegRipper plugins), I ran registry-wide searches in keynames to see if it cropped up anywhere else that I wasn't accustomed to (it doesn't appear in this particular setupapi.dev.log, but it's not reliable as the first dated Boot Session after BootLog post-dates many other artefacts, and some USB dvices don't appear there either (although they do appear in the "usual" places in Registry).

I've now run a registry-wide search for "VPC" and the only other place it appears is under SOFTWARE\Microsoft\Windows Search\VolumeInfoCache
E and F, both of which have values and data of
DriveType 0x00000003 (3) and is REG_DWORD
VolumeLabel "UserName VPC" and is REG_SZ

Don't take this the wrong way, but you're going about this analysis in completely the wrong way. 😉 Sorry, I really couldn't come up with a nice, politically-correct way of stating it.

As I've described in my books, and most recently in WFA 4/e, the information you found in the EMDMgmt key is something of a standalone finding. By that, I mean that you can't expect to search the other Registry keys associated with USB devices and expect to find either the volume name or VSN.

In the materials that I provided to accompany WFA 4/e, there's a file named "usbdev.pdf" in the ch 5 folder that provides a visual representation of the information available on a Windows 7 system (mostly in the Registry) that is associated with USB devices.

Now…you had said…

Am looking for evidence of data files accessed on external media. So looking for anything not on C and also not on S which is a network share.

…and…

E - with Volume Label "UserName VPC" with VSN E09B-7A77 crops up frequently in LNK and JumpLists, I want to know what it is.

So, as I understand it now, you're looking for information regarding files the user accessed on external media, specifically on we see as the E\ drive.

In July 2013, I posted a bunch of "HowTos" to my blog, which I also included in ch 8 of WFA 4/e…this one talks specifically about determining user access to files

http//windowsir.blogspot.com/2013/07/howto-determine-user-access-to-files.html

So, if you *know* that the drive letter is E\, I'd recommend looking for accesses to files on that volume.

If you were interested in trying to tie down more information about the device itself, what you should be correlating is the unique instance ID, which I described in WFA 4/e (as well as previous editions). The volume serial number and keywords such as "VPC" aren't going to do it for you.

HTH. If there's anything else I can do to assist, please let me know.

I don't know what to make of this, can't find much about volumeinfocache or what options there are for DriveTypes

The RegRipper volinfocache.pl plugin has some good info in it; it not only has the drive types listed, but references an MS KB article, as well.

Not sure what you mean here, my only previous attempts at looking at VMs have been trying to boot a VM using LiveView, which as far as I recall needs the user's logon password (which I never have).

What I'm asking is, why do you need to log in? VM files are very much like raw image files (in most cases), and you can easily open them in tools like FTK Imager. From there, you can blow out a raw/dd image file, or just access data right there. So you don't need to boot a VM when you're looking at one…

If you do feel as if you need to login to the VM, download Peter Nordahl's NT change password tool…if you get the .iso file for the CD/DVD version of the tool, you can add that to the VM as a CD and boot off it. This will let you change any password on the local system.

 
Posted : 14/08/2014 9:18 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Don't take this the wrong way, but you're going about this analysis in completely the wrong way. 😉 Sorry, I really couldn't come up with a nice, politically-correct way of stating it.

What about
I believe you might be directionally challenged in your current approach that, as is, appears to be leading you to deferred success. wink
http//www.collinsdictionary.com/dictionary/english/deferred-success

If you do feel as if you need to login to the VM, download Peter Nordahl's NT change password tool…if you get the .iso file for the CD/DVD version of the tool, you can add that to the VM as a CD and boot off it. This will let you change any password on the local system.

Shameless plug 😯 , but JFYI
http//reboot.pro/topic/18588-passpass-bypass-the-password/
http//www.sherlock.reboot.pro/passpass-bypass-the-password/

(the advantage - if any - is that the Registry is not touched at all)

jaclaz

 
Posted : 14/08/2014 10:10 pm
(@cults14)
Posts: 367
Reputable Member
Topic starter
 

Thanks guys

Harlan, too much info to digest this evening (UK), will re-visit over the next coupe of days

FYI I can see no VM files in the DD image I have of the drive, a colleague (in Colorado) of our ex-worker however tells me that the user kept about a dozen VMs on an external drive which had a Dymo label on it saying "UserName VPC" - coincidence?

And we don't have the external drive (

Cheers

 
Posted : 15/08/2014 3:03 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

FYI I can see no VM files in the DD image I have of the drive, a colleague (in Colorado) of our ex-worker however tells me that the user kept about a dozen VMs on an external drive which had a Dymo label on it saying "UserName VPC" - coincidence?

And we don't have the external drive (

JFYI

Once is happenstance. Twice is coincidence. Three times is enemy action

It seems to me like Mr. User Name left very little to chew on. (

If the Virtualbox was installed on the "C\" drive, there may be still some traces, but this would be a "rare" case, and it would anyway need that snapshot were used. ?
See
http//programs.online.utica.edu/pdf/Neal_6_Gonnella_Forensic_Recovery_of_Evidence_from_Deleted_Oracle_VirtualBox_Virtual_Machine.pdf
but even if these were used , if they were saved on the external drive you can do nothing.

jaclaz

 
Posted : 15/08/2014 2:43 pm
(@cults14)
Posts: 367
Reputable Member
Topic starter
 

In the course of trying to understand EMDMGMT I noticed that on my system (where there are >140 sub-keys in EMDMGMT), all the drive enclosure sub-keys seem to begin with some kind of prefix, ranging between 3 and 5 characters e.g. HD_J% or IP_MD

In testing, I noted that
* First connection of an enclosure (external HDD) creates a sub-key like "DX_Q__Seagate Backup Plus Drive_1792307332"
* Re-formatting the HDD in Windows creates a new sub-key but with the same prefix, and a new VSN
* Re-formatting the HDD in Computer Management also creates a new sub-key but with the same prefix and with a new VSN
* Re-naming the drive in Windows (what many users might do - Right-clickProperties or press F2) creates no new sub-keys although something - I'm not sure what - can happen to update the last-write key of EMDMGMT sub-keys.

I know the VSN behaviour has been noted elsewhere before, but I've not noted anything on the prefix. If this is repeatable and predictable behaviour, then could this help to identify volumes (via VSNs and Volume Names) which are referred to in LNK files and JumpLists?

It doesn't help me in this case as the "prefix" of original Sub-key "VAG___UserName VPC_3768285815" doesn't appear anywhere else in EMDMGT ( Which might suggest that this is not repeatable and predictable (

But I was wondering if others had noticed this behaviour and if so if there is any method behind the allocation of the prefix (I think it may be random based on where in EMDMGT new sub-keys get created).

Cheers

 
Posted : 18/08/2014 4:45 pm
(@cults14)
Posts: 367
Reputable Member
Topic starter
 

Update

Closer examination of sub-keys and prefixes on my system suggests my earlier hypothesis was incorrect, e.g. (in the order in which they are listed)
WE_Q__Blank_3565214542 (Last Write time on key 30-Sep-2013)
WE_Q__Elements_3565214542 (16-Apr-2013)
WE_Q__My Passport_3565214542 (01-Apr-2014)

So all have same VSN but different keynames. What could cause 3 different subkeys to have the same VSNs?

Cheers

 
Posted : 18/08/2014 6:18 pm
Page 1 / 3
Share: