I've been reading through some of the presentations and papers that are part of the updates from the e-Evidence web site, and as always, I've found some good stuff linked there.
Matt Churchill has an excellent presentation that addresses examiners fighting back against anti-forensics techniques, in part through live response (slide 14) and learning new things (slide 20). Matt also suggests reaching out to others and having peer reviews, but honestly, I don't see this happening any time soon; however, I do believe that is immensely important, because none of us is as smart as all of us. Matt's presentation also reminds me of an analysts need to evolve.
Diane Barrett has another excellent presentation on Virtual Traces, addressing the use of virtualization and its impact on forensic analysis. I've read Ms. Barrett's presentations before and been impressed with her findings with respect to virtualized desktop environments such as Moka5 and MojoPac. While I have not personally run into the use of any of these environments, it something that I definitely keep in mind when looking at data exfiltration issues; some of the artifacts identified by Ms. Barrett are picked up by RegRipper.
Over on the ForensicFocus site, Dennis Browning compares the Apple property list to the Windows Registry...definitely an excellent read, particularly for anyone who deals with both.
From AccessData, Dustin Hulburt has an excellent paper on fuzzy hashing, and he references Jesse Kornblum's work, as well. More and more, in my own professional experience, traditional MD5 hash comparisons are becoming less and less effective, and in many cases, are significantly less effective than AV scans. In a recent examination, malware that was known (ie, by AV vendors and regulatory bodies) was modified, so that it was NOT detected by AV nor by hash comparisons, but the names of the malware files remained the same. Heck, even VirusTotal has been providing fuzzy hashes of submitted files. I ran into a similar instance over a year ago, where files of the same name and same apparent usage were found in examinations 8 months apart; although MD5 and SHA-1 hashes were different (completely obviating the use of EnCase or Gargoyle for detection), Jesse Kornblum's ssdeep indicated that the files were 97% similar.
These aren't all that's listed at the sight, just a taste. This is definitely a site you should have bookmarked, and check on a regular basis (monthly?), as well as submit links to.
I also want to thank Christine for her diligence in continuing to pull this stuff together and post it. This is one of the ways that examiners and responders can evolve, by being exposed to other approaches and ideas. Thanks!
Great roundup post!
ReplyDeleteI particularly enjoyed the references to virtulization. Use of "LiveCD" OS enviroments that boot (almost) entirely removed from the hardware and run in system memory are very common and becoming slightly more mainstream.
And while a bit different than Moka5 and MojoPac, certainly would present challenges for an investigator.
Microsoft's Virtual PC virtualization platform is also popular in offices and homes.
I'm particularly interested in it as Windows 7 pushes forward. Windows 7 Ultimate and Enterprise builds will offer an "embedded" virtualization of XP: Secret No More: Revealing Windows XP Mode for Windows 7. - Within Windows blog
Localized usage (as opposed to server-based) of most of these virtual systems would require a virtual hard-drive file somewhere; either on the local drive or removable media. As long as you can identify and recover that file, I suppose you still can apply traditional forensics methods on that "hard-drive".
What could also be worthy of investigation on these "virtual hard-drive" files are file-fragment records from the host system that get "trapped" in the free-space of the virtual drive.
Why does it take so long to create a fixed size virtual hard disk? - Virtual PC Guy WebLog
Quoting below:
"Imagine the following situation:
* You have a virtual machine with a bunch of confidential data running on a central server (e.g. your company payroll).
* This virtual machine gets moved to a new physical server in response to increased work load.
* You create a new virtual machine which is given to someone on from the in-house dev team - but the virtual hard disk data was not zeroed out.
* Developer then runs data recovery tools on his new, blank virtual machine and is able to recover data from the old payroll server (yikes!)
You see - data is never actually deleted from a disk when a file is moved or deleted (it is just dereferenced) so to avoid the above scenario - we must take the time to "do the right thing" and zero out the VHD contents."
End quote.
So non-technical users (or lazy technical ones) who quickly create virtual hard drive files might create security issues or leave breadcrumbs for a skilled forensic investigator in that virtual file environment.
For suspects who do their homework and use non-footprint leaving methods of their activity with virtual systems, Diane Barrett's presentation hit it on the mark that investigators may have to take some methods from security incident responders by moving on to corporate/home router/IP log file records to recreate Web activity.
On that, while many folks might already know about potential IP/Web activity logging in a corporate setting, it seems to me that forensic investigators might do well to examine any home routers used by suspects as well. Depending on the specific model and the suspect's technical knowledge, some SOHO/home routers have the ability to retain logs as well. Those might also contain evidence information.
Finally, as Diane Barrett (and you) point out out, (most) of these virtualization applications/environments do leave some evidence of their own presence behind. So even if the virtual environment itself disappears, the "wrapper" that ran it might be left behind to some degree. Familiarity of these markers might lead the examiner to then look deeper or elsewhere (server file, USB stick-drive, portable hard-drive) for the actual "hard-drive" file and all the information it contains.
Great find!
--Claus V.
Thanks for the shout out!
ReplyDeleteAnother great post!
ReplyDeleteTo add to the comment from Claus. From a security standpoint, has there been any discussion about XPM and patching the virtualized OS? We see plenty of users who don't bother to patch their systems. Would this be a double whammy by basically having 2 (possibly unpatched) OS's to exploit?
This might be quick on the trigger as I have not looked much into XPM, but would be curious how keeping a user keeps it up to date.
Thanks again for a great blog,
Ed
@ Ed - That's getting a bit off the forensics angle but that is an excellent point that hasn't been deeply discussed regarding the XPM environment.
ReplyDeleteI've not had a chance to play with it yet but it seems to basically be just another virtualized XP build OS that is interacting with the Windows 7 host OS a bit more "optimized" for application display purposes for the end-user. It has some more tricks up the sleeve but I'm also concerned with security patching methods for the XPM enviroment.
Also, Windows 7 appears to also still have the standard "Application Compatibility Mode" that XP and Vista have to run applications optimized on the host OS as XP/Win98/etc.
This is different than XPM which fully virtualizes the XP OS for the application
Application Compatibility Mode generally works well in Vista for most otherwise balky XP applications. So I'd initially assume that it would be the same under Windows 7.
With this in mind and the hardware impact of XPM as a client verses running XP apps on the host OS directly in the still available "application compatibility mode" I'm starting to wonder what class of applications that XPM mode is really needed for.
Plus all the administrative sysadmin overhead for deploying, configuring and maintaining XPM support on these client systems.
What started out sounding like a slam-dunk for Microsoft with this feature is now bring with it lots of (yet) unanswered questions on practicallity.
But then, this is a forensics blog and not a sysadmin blog. ;)
--Claus V.