±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 1 Overall: 32229
New Yesterday: 5 Visitors: 124

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

RSS Feed Widget

±Latest Webinars

Recoverability of data from virtual machine - advice needed

Computer forensics training and education issues. If you are looking for topic suggestions for your project, thesis or dissertation please post here rather than the general discussion forum.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page Previous  1, 2, 3  Next 
  

Re: Recoverability of data from virtual machine - advice nee

Post Posted: Thu Feb 23, 2017 3:33 pm

- StudentofLife

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
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 
  

Re: Recoverability of data from virtual machine - advice needed

Post Posted: Sat Mar 04, 2017 4:15 pm

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  

StudentofLife
Member
 
 
  

Re: Recoverability of data from virtual machine - advice nee

Post Posted: Sat Mar 04, 2017 4:33 pm

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?  

StudentofLife
Member
 
 
  

Re: Recoverability of data from virtual machine - advice nee

Post Posted: Sat Mar 04, 2017 4:47 pm

Hello jaclaz,

Thank you for taking the time to respond.

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).


1 query to this beautiful explanation

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? Wouldn't a reinstall properly wipe everything? SN: I didn't click the option to keep all files + data  

StudentofLife
Member
 
 
  

Re: Recoverability of data from virtual machine - advice nee

Post Posted: Sun Mar 05, 2017 4:56 am

- StudentofLife


1 query to this beautiful explanation

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? Wouldn't a reinstall properly wipe everything? SN: I didn't click the option to keep all files + data

Well, unless you wiped the disk (or formatted the volume(s) involved on a OS Vista or later WITHOUT the /q switch) everything that is not overwritten will remain.
Even if you created a new backing file (virtual disk) for the newly installed VM, there is nothing preventing it - by chance (but not improbable as it may seem) - to occupy partially the same extents on disk than the previous one.

You have to understand how data such as an e-mail is just a sequence of bytes written to a given address on disk.
You normally (that is what filesystems are for) access that piece of data through indexing/addressing structures, but the fact that these indexing/addressing structures are removed/deleted/corrupted doesn't in any way change the actual data.
Unless something else is overwritten at that particular address the previous data remains there (on hard disks, SSD's may behave differently).

As a side note what most people use in VM's (and that should NEVER be used, unless in certain given setups when there is a reason for using them ) are "growable" or "dynamic" virtual disks, i.e. files that are not of a fixed size but that can expand automatically in case of need, and in such cases there is an added risk of having a fragmented backing file on the host filesystem (which consequently increases the probability of having traces of the contents of the virtual disk scattered anywhere on the "real" disk).

To give you an example (intentionally extreme), let's say that you are using a "real" machine with - for the sake of the example - 2 Gb of RAM and a 40 Gb hard disk (old, I know) on which you freshly install (on a 00ed or "wiped" disk) as "host" OS Windows 7 32 bit using the "standard" install.
Likely, you will have:
100 or 200 Mb occupied by the "boot" volume (what the good MS guys call "system")
39.8 Gb occupied by the "system" volume (what the good MS guys call "boot")
Of this latter, the Windows 7 and a few programs, including the VM software will occupy roughly 18 Gb, lets say to round up numbers 17.8
You have remaining 22 Gb of disk space, from which you have to subtract, let's say, 2 Gb for the pagefile.sys, and 1.5 Gb for hiberfil.sys.
You have remaining roughly 18.5 Gb.
Now you create a 15 Gb virtual disk and install to it - still say - a XP 32 bit.
From this VM you send a number of emails (or do any activity).
Then your Windows 7 gets corrupted and you re-do the same thing from start.

How many probabilities are there that the newly created XP virtual disk overlaps (partially) the same sectors on the real disk as the previously created virtual disk?

I would say pretty high, while I would expect to be pretty low the chances that the newly sent three e-mails (or something else) overwrite the same sectors where the ones sent in the previous VM install were stored to and thus you can find traces of the "previous" e-mails by carving an image of this virtual disk.

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 
  

Re: Recoverability of data from virtual machine - advice nee

Post Posted: Mon Mar 06, 2017 12:04 pm

A quick question to everyone:

BACKGROUND: I have a case in which a 3rd party IT consultant created a VMDK virtual machine backup of the computer I am asked to investigate. The IT consultant has zero background in forensics but was trying to "preserve" the computer in case the subject later deleted evidence.

I need to recover usage of 3rd party email accounts and web browsing.

I did not work with the IT consultant to create the VMDK virtual machine so I have no clue how the IT consultant setup the backup process.

QUESTION:

Can a VMDK virtual machine be created (and later examined forensically) which includes the equivalent of a full physical forensic image including unallocated space and file slack space?

If yes, then I could point Internet Evidence Finder at the VMDK files and get to work carving the PageFile, HyberFile, etc.

If no, then I need to make a physical forensic image and then use IEF.

Thanks!  

UnallocatedClusters
Senior Member
 
 
  

Re: Recoverability of data from virtual machine - advice nee

Post Posted: Mon Mar 06, 2017 12:31 pm

- UnallocatedClusters

QUESTION:

Can a VMDK virtual machine be created (and later examined forensically) which includes the equivalent of a full physical forensic image including unallocated space and file slack space?

Yes/No.
Meaning that:
1) a VMDK is not a virtual machine it is an image (virtual disk) format (of which there are several types).
2) In theory it can be made BUT anyway it won't be a "proper" image (if it has been booted even once) as the OS (or the operator to have it booting) will have changed quite a lot of things to "adapt itself" to the virtual hardware. One among the various VMDK formats is actually a RAW image with an external "descriptor file", very similar to the "old" .pln format, but - depending on the tools actually used to create it - it is rarely "first choice", as normally "growable" images that include only the actually allocated sectors are used for backup.
2) Creating such a "forensic sound" VMDK would normally (since Vista I believe) imply doing that from a (BTW forensic sound) "external OS", such as a forensic Linux distro or a WinFE, which I doubt the third party IT consultant will have used.
3) Without knowing EXACTLY the steps/method/procedure used by the IT consultant (that 99% probability will NOT be correct from a forensic point of view and will NOT include unallocated space) you simply CANNOT trust the image or its contents, it is of course "better than nothing", but you really should proceed to make a new image through the correct forensic procedures.
The good news are that a lot of artifacts (like - say - internet browsing history and similar) will likely be findable in the VMDK image alright, but you can forget about unallocated space and similar.

You will probably need anyway to make another "proper" image, and analyze both.

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 

Reply to topicReply to topic

Share and Like this forum topic to get more replies




Page 2 of 3
Go to page Previous  1, 2, 3  Next