Recoverability of d...
 
Notifications
Clear all

Recoverability of data from virtual machine - advice needed

21 Posts
5 Users
0 Likes
2,635 Views
(@studentoflife)
Posts: 15
Active Member
Topic starter
 

Hello all,

I'm a university student writing my dissertation on virtual machines; specifically what can be recovered from a VM (using VMware Workstation 12.5)

My dissertation will be in 3 parts

1 - Incorrectly and correctly turning off a VM and analysing the data which can be retrieved from both using FTK Toolkit 6.0 (inspired by a paper conducted by Richard Bares - Hiding in a Virtual World Using Unconventionally Installed Operating Systems)

2 -

3 - Creating a framework for investigators who encounter VM's at an investigation

I have left number 2 blank as this is where I'm stuck.
I know that I would like to conduct certain activities in the VM (such as downloading pictures, using the internet, sending money, changing date/time on files etc) but I'm not sure what to do with this information.

My supervisor suggested using predictive coding to extract data from the VM.
I'm thinking about creating a script to either detect the presence of a VM on a Windows machine or to extract data from a VM.

I'd just like some thoughts/inputs about these 3 ideas and anything else I could possibly do to improve this.

Thank you in advance

 
Posted : 21/02/2017 5:55 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I am not entirely following you.

A virtual machine doesn't exist (it is virtual wink ) but is composed of
1) a virtual hardware (that doesn't as well exist) which is the program that makes the machine virtually exist, the VmWare Workstation
2) some settings for it (usually in the form of a "real" settings file, like a .ini or a .xml, etc.)
3) one or more virtual disk(s) and other virtual devices, such as a virtual floppy drive or a virtual CD drive (that also do not really exist if not within the realms of the VM) where the OS is installed or however runs, but that do exist in the form of backing file(s), typically a .ima for floppy, .iso for CD/DVD, .vdk for disk (in VmWare).

The sheer moment the VM is off, all you have remaining is these "backing files", which can however be mounted (or accessed) by using a number of dedicated existing tools or drivers, as they are (or can be converted to) RAW images of the corresponding virtual device.

Once you can access these files, they are RAW images exactly like the ones you can take out of "real" devices, and the way they can be analyzed/information retrieved is not in any way different from the way you would analyze an image of a "real" disk (or floppy, or CD) coming from a "real" machine/PC (which is BTW the only thing you can get once the machine/PC is off).

Can you expand on what you believe would be different from analyzing a "real" machine disk?

jaclaz

 
Posted : 22/02/2017 12:51 am
(@athulin)
Posts: 1156
Noble Member
 

Dissertation … what kind of dissertation?

I have left number 2 blank as this is where I'm stuck.
I know that I would like to conduct certain activities in the VM (such as downloading pictures, using the internet, sending money, changing date/time on files etc) but I'm not sure what to do with this information.

Well, is that of any interest? It seems it would be the same kind of traces found on non-virtual machines – and it's not obvious that the added layer of virtuality provides anything interesting, at least not at first look.

I mean, I'd just mount the virtual disk, and then treat it as a normal disk. If anything prevents me from doing so, it would be interesting. Or if there's anything that I wouldn't 'see' …

The virtual disk itself might be interesting especially if it's 'expand at need' disk, where blocks aren't 'present' until they're written to, and then remain. (Or do they remain? Perhaps the VM is TRIMming?) What does go on on the virtual disk level?)

Perhaps the virtual disks does something interesting with blocks they could in theory be moved around and remapped, and I wouldn't notice … but that requires either analyzing the file format of a virtual disk, as well as analyzing the run-time handling of blocks.

My supervisor suggested using predictive coding to extract data from the VM.
I'm thinking about creating a script to either detect the presence of a VM on a Windows machine or to extract data from a VM.

Predictive coding I associate with ediscovery a method for discovering important documents. But it seems that it is just as well done by mounting the virtual disk using normal tools, and then do it as if it was a physical disk. The VM layer is just a mild inconvenience, if even it is that.

 
Posted : 22/02/2017 1:21 am
(@studentoflife)
Posts: 15
Active Member
Topic starter
 

Hello jaclaz,

First of all, thank you for taking the time out to respond.

My motivation for writing this paper came from a few articles which said that crimes committed using VM's are on the increase. Suspects think that they can simply delete the VM's files and all trace of their activities are deleted with it. I wanted to see how true this is.

Can you expand on what you believe would be different from analyzing a "real" machine disk?

The difference is that a VM’s disk doesn’t really exist whereas a real machine’s…does. Whereas a physical drive requires a connection to another physical drive, a VM’s disk is a bunch of files. So if these are deleted, are all traces of activities conducted in the VM deleted along with it? What exactly can/cannot be recovered?

When you delete a file on a physical disk, Windows removes the pointer and marks the sectors containing the file’s data as available, this can then be overwritten as you continue to use the machine. My experiments involved me creating a VM, installing an OS, conducting activities within it, imaging it, deleting the VM from disk, then creating a new VM with the above steps. So in theory, the data from the previous VM’s should’ve been overwritten – just like it is from a Windows hard disk. However, during my analysis of each VM I have been able to find information in a VM, linked to its predecessor(s).

Therefore, it would seem that the data from VM’s are even more recoverable than from a physical hard drive (I’m not yet in a position to say this with complete conviction)

I hope this answers your question. I understand that a VM is a virtual computer and therefore there won’t be very different to an actual, physical PC. But there are people who believe that the contents of a VM are unrecoverable – I hope to dispel the myth

P.S. Based upon this advice I will no longer be creating a framework for approaching a VM at a crime scene. Thank you.

 
Posted : 23/02/2017 12:43 am
(@studentoflife)
Posts: 15
Active Member
Topic starter
 

Hello athulin,

First of all, thank you for taking the time out to respond.

It is a dissertation for my third year undergraduate degree of Computer Forensics.

I mean, I'd just mount the virtual disk, and then treat it as a normal disk. If anything prevents me from doing so, it would be interesting.

I’ve had a few issues doing this. I’ve copied the VM files from my testing drive and proceeded to open the VM on a different drive, using the same version of VMWare Workstation. All is well for 6 – 8 minutes then the VM shuts down with an error message telling me that 1 of the VMDK’s is missing, even though I’ve copied the whole folder and double checked that the contents are the same.

Or if there's anything that I wouldn't 'see' …

I’ve not tried to see whether there is any difference between the data that you get when you mount the virtual disk and image it live and when you process the dead VMDK through FTK Toolkit. But it is an idea and I thank you.

The virtual disk itself might be interesting especially if it's 'expand at need' disk, where blocks aren't 'present' until they're written to, and then remain. (Or do they remain? Perhaps the VM is TRIMming?) What does go on on the virtual disk level?)

Can I assume that this is what you mean by TRIM?
http//searchsolidstatestorage.techtarget.com/definition/TRIM

Finally, do you think that a script to either extract data from a VM/detect a VM would be helpful at all?

Thank you.

 
Posted : 23/02/2017 12:45 am
(@athulin)
Posts: 1156
Noble Member
 

It is a dissertation for my third year undergraduate degree of Computer Forensics.

Thanks – that helps put it into perspective.

I’ve had a few issues doing this. I’ve copied the VM files from my testing drive and proceeded to open the VM on a different drive, using the same version of VMWare Workstation. All is well for 6 – 8 minutes then the VM shuts down with an error message telling me that 1 of the VMDK’s is missing, even though I’ve copied the whole folder and double checked that the contents are the same.

Did you figure out what the problem was? In the cases I've seen this, it has always involved confusion in the minder of the FA confusing the folder with the virtual machine. To lessen the risk of that kind of confusion, help would be useful, admittedly. But then, it could just be something that parses the main VM file to say 'these files constitute the VM'.

Can I assume that this is what you mean by TRIM?[/quoye]

Yes. A VM might benefit from an operating system issuing TRIM commands, and use those to deallocate blocks. That's one of those things that seem to be technically possible, but I have no idea if it actually happens or not. But if it happens, it is important to know.

Finally, do you think that a script to either extract data from a VM/detect a VM would be helpful at all?

In the right context. By which I mean something on the line of

1. What files constitute parts of VMs? (All VMs, current as well as obsolete, workstation VMs as well as server VMs. Could be just the top 10 VMs, based on good statistics, but preferably as many as possible.)

2. What tools already exist to find those files? (In forensic toolkits, as well as stand-alone products. Or closely-related products, such as the file(1) command and its database. In normal file systems as well as in sectors from deleted files.)

3. How well does those tools do? Do they reach 100%? Or are there significant omissions in coverage?

If the last question has 'yes' for an answer, then I would think additional tool/tools are called for.

First, to identify all files belonging to one VM.

To extract those files is a slightly different question In a normal file system, just getting the files identified is often enough help – extracting the files can be done by any suitable method, as long as the output from the 'identifier' can be reused. To extract them by other means … probably needs careful thinking over.

 
Posted : 23/02/2017 9:38 pm
(@c-r-s)
Posts: 170
Estimable Member
 

My motivation for writing this paper came from a few articles which said that crimes committed using VM's are on the increase. Suspects think that they can simply delete the VM's files and all trace of their activities are deleted with it. I wanted to see how true this is.

Sorry, if I'm wrong, but it seems to me that you're not fully aware of the known limitations of VM storage isolation.

Basic "hacking manuals" advise perpetrators to use an encrypted VM. This is because the virtual disk abstraction layer itself doesn't hide anything. From the perspective of examining a host file system, virtual disks on this file system impose two main issues relativity of file system specification and block addressing.

Therefore, a file carving process will regularly penetrate most (monolithic, unencrypted) virtual disk structures residing on the volume which it is applied to. This is maybe a point to focus on, since you're obviously at risk to mix up the findings, if you miss the existence of (deleted) VM storage in a carving scenario.

You see, my recommendation basically is to leave aside the examination of an intact VM image, because it is not structurally different from a physical volume. It becomes interesting when you try to, are forced to or simply unwittingly analyse the VM storage contents together with the host file system.

The reason you give for examining a VM image (if I get it correctly), is that you'd like to find remains of other/previous VMs in that image, and you already did. Strange things happen, and I don't want to deny that this may be the case in some situations. Indeed, it would be very interesting, if you encountered such one. But generally speaking, this is impossible under the provision of a "proper" VM storage setup and not injecting data into the VM storage with host permissions. It probably indicates the use of an unfit disk creation procedure/tool and, due to the massive security implications, can't be expected to be the default behaviour of a vendor supported configuration or tool.

 
Posted : 24/02/2017 1:30 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

The difference is that a VM’s disk doesn’t really exist whereas a real machine’s…does. Whereas a physical drive requires a connection to another physical drive, a VM’s disk is a bunch of files. So if these are deleted, are all traces of activities conducted in the VM deleted along with it? What exactly can/cannot be recovered?

As I see it there is no real difference.

The physical disk (intended as the actual disk device) of course exists, but anything on it (DATA) doesn't really "exist", similarly to what happens in a VM.

The virtual disk is (usually) a single, huge, file which is accessible by the "outer" or "hosting" OS only because a partition and a filesystem are applied to the file extents, indexing them.

I mean, take a normal PC/OS, we all know that when you delete a file let's say for the sake of the example a small text file, you normally just mark that particular file (actually the extent it occupies) as "free space, ready to be overwritten" and until that particular extent is actually overwritten, no real deletion occurs.

So a common practice is to carve "free space" for "traces" of text or known file headers, etc. to see if anything "deleted" can be recovered, and if this carving is carried on soon enough and you have a little luck you can find that file alright.
Now, imagine that for whatever reasons, you wipe the MBR of the disk (physical disk) and the whole FAT (or $MFT, etc.) of the partition where you stored the text file, your deleted text file is still there, and can be retrieved by carving just the same, the only difference is that the whole extents of the disk (and not just the "free space" in the partition) needs to be "carved", it will take more time, but at the end you will find it.

If you do the same in a VM, then delete the virtual disk, the small text file is still there and can be found (in the "free space" of the physical disk), but of course before looking for it you would probably first be looking for the virtual disk backing file, and if you find and can mount the volume you are exactly in the same situation as on the real PC (you know where to look for the file, i.e. know the extents that represent the "free space" in the filesystem on the virtual disk).

No real difference.
What you will be able to retrieve depends IMHO on three factors
1) accuracy of deletion
2) time the OS (the "main" one) was used after deletion
3) luck

If the Virtual disk was "properly" deleted (please read as wiped) and/or the backing file was filled with 00's, factors #2 and #3 are irrelevant, and you won't find anything of use, except - maybe - that a VM was used (but you would probably find many more artifacts of VM usage in the "main" OS).
If the Virtual Disk was not "properly" deleted, factors #2 and #3 come into play, but both are - I believe - outside your control.

If you can recover (via various traces of the MBR, bootsector, FAT, $MFT, etc.) at least the extents of the backing file, then you are exactly in the same situation of a (possibly corrupted) "real" disk.

jaclaz

 
Posted : 24/02/2017 1:33 am
(@studentoflife)
Posts: 15
Active Member
Topic starter
 

Hello athulin,

Thank you for taking the time to respond.

Did you figure out what the problem was? In the cases I've seen this, it has always involved confusion in the minder of the FA confusing the folder with the virtual machine.

I didn't figure out why I'm unable to open a VM - it may have something to do with a corrupted VMDK descriptor file/.VMX but it's not something I'm actively trying to fix.

Please don't think that I don't search abbreviations when you use them but because there are so many out there, I have to be sure; what does FA mean? I'm thinking File Allocation/File Analysis but I'm not sure.

I've also decided to take your advice and see how different forensic tools react to hosts with VM's, VM files and VMDK's themselves. Any limitations will be noted and a script will be created to fill the gap.

On a separate note (I'm not sure if I should be starting a new thread for this or not) I have a query…

I created a VM in VMware Workstation, installed an OS, sent 3 emails within the VM, imaged the host, extracted the VM, imaged the VMDK in FTK Imager + Toolkit. My host's OS then got corrupted. I then reinstalled the OS on my host, created a VM in VMware Workstation, installed an OS onto this, sent 3 emails within the VM, imaged the host, extracted the VM, imaged the VMDK in FTK Imager + Toolkit and I'm able to find traces of the email I sent in the VM which was active before the corruption occurred - how?

I thought it could be linked to Window's unistore as it saves email data…but this is only on the local drive and should be cleared after reinstalling

I also thought it could be linked to a system similar to trial software. Trial software adds a key in the registry and when uninstalled and reinstalled, it detects the registry key and gives the user message like “Your trial period has expired." Maybe something similar happens with VMware? Maybe it detects a key and restores memory of some sort…

As you can see I'm stumped and clutching at straws. Any advice would be appreciated.

Thank you

 
Posted : 05/03/2017 2:15 am
(@studentoflife)
Posts: 15
Active Member
Topic starter
 

Hello C.R.S.,

Thank you for taking the time to respond.

Sorry, if I'm wrong, but it seems to me that you're not fully aware of the known limitations of VM storage isolation.

No you are correct and this is something I'll read up on. Thank you for the idea.

You see, my recommendation basically is to leave aside the examination of an intact VM image, because it is not structurally different from a physical volume. It becomes interesting when you try to, are forced to or simply unwittingly analyse the VM storage contents together with the host file system.

This is definitely a good idea and something I will attempt in the future. I have a little over a month to get my dissertation wrapped up. But thank you for the idea.

The reason you give for examining a VM image (if I get it correctly), is that you'd like to find remains of other/previous VMs in that image, and you already did. Strange things happen, and I don't want to deny that this may be the case in some situations.

But this has happened with every single VM I've analysed (so far…I still have a few to do). The method I used for my experiments

Create guest VM on testing hard drive
Conduct activities within the VM
Image the host on lab hard drive
Extract VM files
Image VMDK in FTK Imager
Process it in FTK Toolkit
Delete VM from disk, within VMWare
Create guest VM on
Conduct activities within the VM
Image the host on lab hard drive

And the process repeats

At one point my host OS got corrupted. I then reinstalled the OS on my host, created a VM in VMware Workstation, installed an OS onto this, sent 3 emails within the VM, imaged the host, extracted the VM, imaged the VMDK in FTK Imager + Toolkit and I'm able to find traces of the email I sent in the VM which was active before the corruption occurred - how? What could be deemed an 'unfit disk creation procedure/tool' in these scenarios?

 
Posted : 05/03/2017 2:33 am
Page 1 / 3
Share: