Hello Reader,
One of the things that in my opinion makes an examiner better at digital forensics is the ability to re-create events, create test scenarios and possibly find new artifacts. The best way to do that is through recreation testing and its something we do in the lab quite often. The premise is simple and there is some things you can do ahead of time to make your life easier.
In my lab we could receive anything so we have fresh install virtual machines from Windows 95-Windows 8 and all the server variants. For this kind of work a MSDN license is very, very helpful but some of the older operating systems are no longer on MSDN so we turned to ebay to fill the gaps in getting install media. We also have some virtual machines for OSX/Linux but they are not used as frequently as they make up a smaller percentage of casework.
In your lab if you work within a company your first step is to determine what operating system versions you make use of internally and then get to work putting them into a base state of what would be on your standard corporate image. If your company as a 'gold image' or a production image that your IT personnel deploy to new equipment that's even better to use as your test bed.
1. VHD has cross platform support without the need to install the virtual machine that created it. FTK Imager in windows supports VHD, Windows 7 and up can mount VHDs a local physical disks and in Linux/OSX through Joachim Metz's libvhdi http://www.forensicswiki.org/wiki/Libvhdi amongst other tools.
2. VHD allows for file systems to be mounted read only natively in Windows/Mac/Linux without additional software.
3. Cross support from multiple virtual machine vendors (Hyper v, virtual pc, vmware, virtual box)
Now you can pick any virtual drive format you'd like but those are the reasons I chose VHD.
For many people this answer defaults to Vmware. I like Vmware but for my day to day VM creation I have migrated to Virtualbox. Virtualbox is free, it supports a wide range of operating systems and it has a pretty low overhead. Whatever virtual machine software and drive format you choose is really up to your preference, they all should generate the exact same test data. The important thing is to standardize so that you can easily pick up your work or switch operating systems with little effort.
This may seem obvious to many of you who work with virtual machines regularly and are thinking about snapshots, there is just one problem with that. When you create a snapshot all the changes to the disk are stored in snapshot overlay files and not the underlying disk image. Your forensic tools do not support snapshot overlays (I don't know of one that does at least) and you base image won't get updated leading you to conclude that nothing has changed.
Instead you'll need to follow one of three scenarios:
Scenario 1 - Capture the full drive
After each change image to compress the data or just copy the virtual drive to a separate folder after suspending the system. This will give you all the data that has changed on the disk but leaves you with the unfortunate task of trying to diff whole images.
Scenario 2 - Capture artifacts of interest
If you are interested in changes occurring to artifacts you know about it may be enough to just extract the artifacts after each change. However, when do you do this make sure to capture it two ways. Once from the running system to capture any settings that may get purged on shutdown and again after shutdown to get all the keys/files that may not be accessible on the file system until TxF and TxR are committed.
Scenario 3 - Run a system comparison tool
For trying to identify possible locations of interest this is where I typically start. My comparison tool of choice is called SysTracer Pro from blueproject.ro, http://blueproject.ro/systracer/download. I like this tool because it will quickly capture the state of all registries and files within the virtual machine and allow you to compare between any two snapshots with full details of what changed. The 'pro' version even has a remote service so you can collect snapshots from the running system without having to add more artifacts by executing anything within the user profile.
That's all for today, I'll continue this with my methodology next week. Tomorrow is the Forensic Lunch at a special time of 2pm Central so make sure to tune in!
One of the things that in my opinion makes an examiner better at digital forensics is the ability to re-create events, create test scenarios and possibly find new artifacts. The best way to do that is through recreation testing and its something we do in the lab quite often. The premise is simple and there is some things you can do ahead of time to make your life easier.
Step 1. Determine which operating systems you have in your environment to test.
In my lab we could receive anything so we have fresh install virtual machines from Windows 95-Windows 8 and all the server variants. For this kind of work a MSDN license is very, very helpful but some of the older operating systems are no longer on MSDN so we turned to ebay to fill the gaps in getting install media. We also have some virtual machines for OSX/Linux but they are not used as frequently as they make up a smaller percentage of casework.
In your lab if you work within a company your first step is to determine what operating system versions you make use of internally and then get to work putting them into a base state of what would be on your standard corporate image. If your company as a 'gold image' or a production image that your IT personnel deploy to new equipment that's even better to use as your test bed.
Step 2. Determine which virtual drive standard you will use
You have a lot of options these days in virtual drive image files. VMDK, VDI, VHD and other formats are all out there and usable. For our testing I have a preference for VHD and I'll explain why.1. VHD has cross platform support without the need to install the virtual machine that created it. FTK Imager in windows supports VHD, Windows 7 and up can mount VHDs a local physical disks and in Linux/OSX through Joachim Metz's libvhdi http://www.forensicswiki.org/wiki/Libvhdi amongst other tools.
2. VHD allows for file systems to be mounted read only natively in Windows/Mac/Linux without additional software.
3. Cross support from multiple virtual machine vendors (Hyper v, virtual pc, vmware, virtual box)
Now you can pick any virtual drive format you'd like but those are the reasons I chose VHD.
Step 3. Determine which virtual machine software you will use
For many people this answer defaults to Vmware. I like Vmware but for my day to day VM creation I have migrated to Virtualbox. Virtualbox is free, it supports a wide range of operating systems and it has a pretty low overhead. Whatever virtual machine software and drive format you choose is really up to your preference, they all should generate the exact same test data. The important thing is to standardize so that you can easily pick up your work or switch operating systems with little effort.
Step 4. Determine how you will compare changes within the system over time
This may seem obvious to many of you who work with virtual machines regularly and are thinking about snapshots, there is just one problem with that. When you create a snapshot all the changes to the disk are stored in snapshot overlay files and not the underlying disk image. Your forensic tools do not support snapshot overlays (I don't know of one that does at least) and you base image won't get updated leading you to conclude that nothing has changed.
Instead you'll need to follow one of three scenarios:
Scenario 1 - Capture the full drive
After each change image to compress the data or just copy the virtual drive to a separate folder after suspending the system. This will give you all the data that has changed on the disk but leaves you with the unfortunate task of trying to diff whole images.
Scenario 2 - Capture artifacts of interest
If you are interested in changes occurring to artifacts you know about it may be enough to just extract the artifacts after each change. However, when do you do this make sure to capture it two ways. Once from the running system to capture any settings that may get purged on shutdown and again after shutdown to get all the keys/files that may not be accessible on the file system until TxF and TxR are committed.
Scenario 3 - Run a system comparison tool
For trying to identify possible locations of interest this is where I typically start. My comparison tool of choice is called SysTracer Pro from blueproject.ro, http://blueproject.ro/systracer/download. I like this tool because it will quickly capture the state of all registries and files within the virtual machine and allow you to compare between any two snapshots with full details of what changed. The 'pro' version even has a remote service so you can collect snapshots from the running system without having to add more artifacts by executing anything within the user profile.
That's all for today, I'll continue this with my methodology next week. Tomorrow is the Forensic Lunch at a special time of 2pm Central so make sure to tune in!
