"Defeating" Whole Disk Encryption - Part 2 "Ok, I've got the password, now what"

In my last post I discussed some techniques for obtaining a PGP encrypted password from a DD image of the physical memory. Let's quickly take a look at how to tackle a dead box before we start to tie all this together.

Dead box:

I'm going to quickly go over this, as I haven't tested what I'm going to write about here.

Accessdata's Password Recovery Toolkit and Distributed Network Attack can be used to bruteforce a dead box. I have not done this, but I'm a big fan of all of Accessdata's tools.

So now we have broken the password/passphrase what are your choices?

Let us assume that you have the password, but you couldn't make a live image of the box. How to get in? Before I start, I'm going to put a big shout out to Dave Shaver over at the US Army's Computer Crime Investigative Unit - a lot of what follows is based on his research and work. . . There are a few other ways that might work here, but this is the one that I've tested.

The Attack:

You are going to need Vmware workstation and Encase. You will also need to download the PGP decryption .iso for the PGP encryption version that your box is running. You can download those here.

Step 1:

In VMware workstation create a VM that you can install Encase (XP, 2000 etc).

Step 2:

Boot your drive, install vmware tools - shutdown the VM.

Step 3.

Edit your shared folders , , and add the folder/drive to add the encrypted image files to something that the VM can access. You might also want to add the folder where you have the Encase installer executable and the Hasp Driver installation file (or you could download those from guidancesoftware.com - your call, but they need to be on the VM or in a folder the VM can access).

Step 4:

Add a second hard drive to your virtual machine. The second hard drive should be slightly larger than the original drive on the encrypted machine. So if the original drive was 188.6 GB, you will want to make your machine 188.7 in VMware. (Note: If you have problems, keep incrementally increasing the size of the drive)

Step 5:

Reboot the VM, install the hasp driver and Encase. With VMware in the foreground, plug in your Encase dongle and start Encase.


Step 6:

Encase should be running in forensic mode. Add the image into Encase. Go through the restoration procedures as if you were restoring the image to a drive, but here, you are going to restore the image to the second drive that we created in step 4. There's a how-to in the Encase manual if you are not sure of the procedures.

Step 7:

Power off your VM, take a copy of the file related to the step 4 drive and copy them to the drive where you have the original image files - copies are your friend here. It's good forensic practice and even if you don't think you need to do this, you'll see why you want to as you read on.

Step 8:

Edit the settings on your virtual drive. Remove the drive that you used to boot (the one we created in step 1). The only drive that should remain active for your VM is the drive from Step 4 - the restored image of the PGP encrypted computer.

Now it is decision time. What are you looking for? Will you be satisfied with only the files that are not deleted, or do you want to make a few changes to the drive and have the chance to get into unallocated space? The good news is that you can have it both ways.

We will tackle that in the next post.

"Defeating" Whole Disk Encryption - Part 1

An issue that we are going to continue to encounter is computers with whole disk encryption (WDE). I'm going to post a couple of techniques that have worked for me, and hopefully they'll be of use to someone else out there. In this post, we will look at PGP's WDE, although the techniques outlined here should be easily applied to other encryption schemes.

The background:

PGP WDE uses 256 bit, symmetric AES encryption. For those of you that don't know what this means, suffice it to say that the algorithm is sufficiently strong to prevent the average person/company/government agency from breaking it.

In many cases we do not have the cooperation of the system owner, so how do we handle this?

Scenario 1 - the computer is running:

If there ever was a reason to argue the Live vs. Dead acquisition arguement, disk encryption has to be one in favor of the live side. My personal preference is to acquire the volatile memory (at a minimum) before shutting down the system. Let's assume that you cannot image the whole system live - grabbing the memory with a tool like George Garner's forensic DD. No, it won't work on Vista or Server 2003 with a service pack installed, but the price is right. If you have the money though, George has solved that problem too.

So now you have a dd image of the physical memory, and a dead computer. You image the same computer and you start looking at the drive and realize that you are seeing nothing but garbage - there's no usable data on the drive.

Fortunately, Adam Bolieau help solved that problem. Adam and Tmasky did some really interesting work on acquiring memory via firewire, but he also wrote some really useful code that will read BIOS passwords from memory. Fortunately for us, PGP stores its passwords in the same memory location. So all we have to do is point bioskbsnarf.py[1] at the DD image that we made of the memory and viola - there's the password.
or at least the last 16 bytes in the keyboard interrupt buffer in the BIOS Data Area before you enter protected mode - so you may not see the "whole" password, but would you rather try to brute force but wouldn't it be easier to brute force the password "I am Computer Geek" if you could see: " a Computer Geek"? I think so. . .

Coming up:

Ok, I've got the password. Now what?

[1]. biobksnarf needs a Python interpreter to run. Python can be downloaded from Python.org, though I have not used the windows binaries with biokbsnarf. If you run into problems, try cygwin's python interpreter on a windows system.

From the command line: "python biobksnarf.py " should do the trick.

IE7 Internet.evt continued

Andreas Schuster has some follow-up regarding the internet.evt file. Andreas points out that with XP SP2 (German Locale) the file is "Windows .evt" Take a minute to check out his blog.

Further testing on my system reveals that this file has remained its default size 65,536 and clearing the log file seems to have no effect - same file size, same lack of content.

Has anyone seen anything different?

And just to clarify:

In my last post, I wrote that "Using psloglist against the file appears to dump the contents of the file." However, further testing shows that the file is not readable - when Windows cannot find the event file specified, it opens AppEvent.evt.

To illustrate, here is a screenshot of psloglist being run against "cybermonkey." Since there is no cybermonkey.evt on my computer, I get the data from AppEvent.evt.

First off, Harlan Carvey mentions that his new book has information about this on page 205; I still haven't made it out to buy the book yet, but the day isn't over. Harlan also mentions that the file is created when IE7 is installed.

Wow, there's been quite a response to the first post. . . A couple of things that Andreas Schuster requested. This is the contents of the HKLM\System\CurrentControlSet\Services\EventLog\Internet Explorer


and this is the HKLM\System\CurrentControlSet\Services\EventLog\Internet Explorer:



This is Internet.evt opened in a hex editor:



the remainder of the file appears to be empty. Using psloglist against the file appears to dump the contents of the file.

Internet.evt

While coding an event log dumper for Windows systems. I stumbled upon a something that was, I thought, of interest to forensic examiners. I found a new (and apparently undocumented) event log - %windir%\system32\config\Internet.evt.

According to this post, and this one as well, the file shows up when Internet Explorer 7 is installed. This coorelates with the computers that I have available (that is computers with IE7 have the file, and those with IE6 do not), though I have not yet tested this to determine that this is in fact the case.

I haven't spent a lot of time looking at the structure of .evt files generally, but in my experience, they are generally readable with a hexeditor, but this is not so with the internet.evt. The windows event viewer, when opened shows this file as Internet Explorer, but it appears empty. When I turned the log viewer I was coding towards the file, however; it had some interesting artifacts.

Most notably, software installations were logged. Including (I think) software installations that were performed using Firefox. This could be very relevant when investigating intrusions where a web browser is used to download and install tools, but obviously some more testing needs to be done.

I'll post what I find in a follow-up, but to summarize:

I know Internet.evt:

1. exists on XP with IE7 installed.
2. does not appear to exist with pervious versions of IE.
3. resides in the %windir%\system32\config
4. is not visable to the windows event viewer in XP home (tested on 1 box).
   

I suspect the file:

1. is created when IE7 is installed.
2. has a file structure that differs from standard event logs.
3. also logs internet related software installations from other browsers.
   

To do:

1. test suspicions
2. figure out what types of data are stored in the file.
   
3. determine what registry entries (if any) are associated with the file.
   

If anyone knows anything more about this, I'd be interested in hearing from you. I couldn't find any reference on Microsoft's Technet but, we all know the schitzophrenic nature of Technet, so there might be some reference somewhere. . .