Additional Bitlocker Incident Response tips

In January, I posted some Incident Response tips on how to deal with a Vista system with Bitlocker enabled. You can read the initial post here. I was recently doing some training and we discussed Bitlocker techniques in depth and decided to post a follow up with some additional tips.

The first thing you must do when you roll up on a system running Vista is to determine if Bitlocker is enabled. Remember that Bitlocker is only available in the Enterprise and Ultimate editions of Windows Vista. A quick look at the system properties should tell you what version you are dealing with:



There are a couple of easy ways to determine if Bitlocker is enabled. The first method is to simply open Windows Explorer and look at the logical drive list. Bitlocker requires two logical volumes. One for the OS and user data files and the second is a small boot partition 1.4GB in size, that is not encrypted. By default, Windows assigns the logical drive letter "S" to this small boot partition:



Also, NTFS is the required filesystem on the logical volume encrypted with Bitlocker.
The second method to determine if Bitlocker is enabled is to simply look at the Bitlocker configuration from the Control Panel:



Finally, you can open an Administrative Command Prompt and use the following command to check the status of Bitlocker:

"cscript manage-bde.wsf -status"



This last option tells you that the logical volume "C" is encrypted with Bitlocker and that an external key (USB) and a numerical password are being used as protectors. This tells the investigator that there must be an external USB device with a key on it (.BEK) extension and that there may be a numerical password written down somewhere. The password is very long consisting of eight groups with six numbers in each group, such as: "363319-629200-548735-017523-429363-314292-005962-259380". The status output also tells you if Bitlocker is currently enabled.

Once you have determined that Bitlocker is in fact installed and enabled, the investigator now has to decide how to handle this volume so later analysis can be performed. There are a couple of options available at this point. The investigator could use a live response CD and make an image of the logical drive while the system is running. It is important to understand that a LOGICAL image must be taken, because it uses the Windows API in order to obtain the decrypted data. If a physical image is taken, you will end up with a full image of the hard drive in its encrypted state and then you will have to deal with decrypting it later in order to perform an analysis.

Another solution is to disable Bitlocker. Disabling Bitlocker does not decrypt the data, in turn altering each file. Instead, it stores the key on the disk so that it can be decrypted the next time it is booted or accessed without the need for the startup key or numerical password. The following command shows how to disable Bitlocker from the command line:

"cscript manage-bde.wsf -protectors -disable c:"



The above command will disable Bitlocker (not decrypt) and if later attached to another Vista machine using a write blocker, all the data will be visible and available for imaging.

The investigator should also obtain the numeric recovery password as a safety measure to ensure later access to the drive for imaging. The following command will display the numerical recovery password:

"cscript manage-bde.wsf -protectors -get c:"



Here is a video showing all the above commands:

Incident Response - Recovering a BitLocker Recovery password before system shutdown

This post is just a refresher for those of you who may encounter a running Vista machine that has BitLocker enabled. The following command will display the recovery password in a command prompt so it can be recorded (a photo) for later use by the examiner.

When initially looking at a running Vista machine, one easy indication that bitlocker is installed is the presence of two volumes. The main volume labeled "C:", and a second volume labeled "S:" (Of course this labeling is by default and could be changed).



The second volume labeled "S:" is a small boot partition that is created when BitLocker is enabled and is typically 1.46GB in size. The contents of this volume is minimal and will at a minimum contain the following files & folders:



If you suspect BitLocker is installed, and even if you recover a removable flash drive that you suspect contains the startup key, the following command is recommended. Start a command prompt with escalated privileges by right-clicking on the command prompt option from the Start menu and choosing "Run as Administrator". Once the command prompt starts, it should say "Administrator: Command Prompt":



Once you have this prompt, the best practice would be to insert your Incident Response toolkit CD-ROM that you previously built (you did previously build it, right?) that contains two WMI scripts that can be found on a default installation of Vista with Bitlocker enabled. These two files can be found in the system32 folder of a BitLocker enabled Vista installation and are named:

manage-bde.wsf
manage-bde.ini.en

You should copy these two files along with the cscript.exe interpreter to your incident response CDROM, you know, the one that's in your incident response toolkit and ready to go....:(

These files are installed by default when the BitLocker feature is enabled, but you shouldn't use the ones on your suspect's installation of Vista. Yes, you are already using the suspect's untrusted operating system, but this is about minimizing risk.

The command to obtain the BitLocker recovery password is:

"cscript manage-bde.wsf -protectors -get c:"



The best method is to take a photo, but verify the photo is not blurry or washed out by the flash before you proceed. Alternatively, you could pipe this information to a text file on a floppy or an inserted flash drive (remember you are going to create registry keys, so document).

You can then shutdown the system and remove the drive to be later imaged in the lab. Once connected to a write-blocker, EnCase (with the EDS module) will recognize the volume as a BitLocked volume and ask for the recovery password. You can then enter the recovery password as it was displayed and make a complete decrypted copy of the data at the logical level (if you look at from the physical level, it will still be encrypted because the data is still encrypted as it sits on the disk).

Alternatively, you can connect the drive to a write blocker (better yet, make a bit level copy and use that) and then connect it to a forensic machine that has Vista installed with BitLocker enabled. Vista will see the volume as a foreign encrypted volume and ask for the recovery password. Once entered, Vista will then mount the volume and assign a drive letter. You can then fire up your favorite trusty imaging application and image the logical volume in a decrypted state.

Both methods will make a decrypted copy of the data so from that point forward, BitLocker is removed from the equation.


*NOTE: There are two primary methods of implementing BitLocker. The first is with the use of an onboard TPM chip. The second is currently the more common implementation and only involves a removable flash drive (a third method exists that involves using both a TPM chip and removable flash disk, which is considered the more secure implementation). The above described commands will succeed for all the different BitLocker methods, but if a TPM chip is installed and used, the decryption process when attempting to image the volume will not work because it relies on the TPM hardware component as part of the decryption process. In theory the only solution in that scenario would be to connect a bit-level copy of the original hard drive to the original suspect's computer and then provide the recovery password at boot and then image the visible volume off to a external drive. I have not yet had the opportunity to test this because I do not yet have a TPM enabled computer. If someone has used or tested this method, please advise.

Vista Volume Shadow Service (VSS) Information - Assistance Request

*Edit 11/20/07 - For clarity, I renamed this blog to Vista VSS information since that is actually the information I am trying to extract, not the System Restore Point information.

Windows Vista introduced several new features, one of which I think will have a huge impact on computer forensics, that being the "Previous Version" feature. The "Previous Version" feature uses the Volume Shadow Service present in Windows 2003, but brings it to a new level by making block level copies of clusters that can contain user files (documents, images, etc).

I have been looking into the new VSS storage method and I think I have found a way to extract some good information about the VSS (step one). Then once I get that figured out, I hope to write an EnScript that might be able to extract the files that have been stored inside the VSS.

This is where I need some assistance from those who have a either running Vista machine with EnCase loaded or image file of a Windows Vista system that can be viewed in EnCase 6. I have written an EnScript to highlight a record of information in the VSS files, but I am not sure yet what the various differences can be based on types of machines, number of drives, etc. So I am asking for assistance by downloading and running the EnScript below and then submitting that back to me so I can compare the various records to see what the differences are.

The EnScript below searches for a record identifier, then bookmarks possible valid records. It also exports the record to a raw file in your default export folder (one file for every valid hit). My Initial research shows one record is present for each VSS file in the "System Volume Information" folder.

The EnScript is not compiled and is readable by anyone, so you can see what it is doing. I have heavily commented each line of code to explain what the EnScript is doing, line-by-line. It is fairly simple. It is looking for a hex value present at the beginning of each record, then reading a value which indicates the length of the record and then bookmarking/exporting that record. The record does not contain anything I consider super-sensitive. The record does contain the name of your machine, the workgroup/domain it belongs to, your machine GUID, some timestamps, the VolumeGUID and the label of the volume.



If you are uncomfortable with sending me this information, thanks for your interest, but stop here.

For those willing to send me this information, please download the EnScript below, preview/load a Windows Vista system in EnCase 6, select all files with GUID names in your "System Volume Information" folder and then run the EnScript.



Once completed, look in your default export folder (C:\Program Files\EnCase6\Export), review the contents to make sure you are comfortable with sending me the contents. Feel free to edit any of the Unicode strings (machine name/domain name, etc) in the exported data with an editor to redact anything you don't wish to share with me, just be careful to preserve the original format of the record. If you are then comfortable nothing sensitive is contained in the files, zip up the exported files and send them to me at lance (at) forensickb.com. I will not be sharing any of the submitted files with anyone else. Please indicate when sending information, what version of Vista it is.

Those of you who participate and send me exported data, I will send you beta/final versions of the EnScript as a token of appreciation for your assistance in its development.

Written for Encase v6

Download Here

EnScript to read Windows Vista Firewall rules

I was messing around with some Vista stuff and I noticed that it maintains the firewall rules (exceptions) in the registry differently than in Windows XP/2K3. They can be found here in the registry:

HKLM\SYSTEM\CurentControlSet\Services\SharedAccess\
Parameters\FirewallPolicy\FirewallRules\

So I decided to write an EnScript that reads the firewall rules and displays them in the console as well as creates some bookmarks. The EnScript, parses the SYSTEM registry hive and reads the firewall exceptions on a Windows Vista system. It then prints out all the ACTIVE firewall exceptions to the console.



In addition, three bookmark folders are created: All Active Firewall Rules, Active Firewall Rules with local port exception & Active Firewall Rules by Application. The first folder contains all the ACTIVE firewall exceptions. The second one only contains the ones that specify a local port exception and the third contains all of ACTIVE port exceptions but the first field is associated application so you can sort and look at what applications are associated with that exception.



Written for EnCase v6

Download Here

Vista Bitlocker in EnCase

During CEIC 2007, Dominik Weber gave a great presentation on Vista Bitlocker and how EnCase supports viewing Bitlocked drives. This presentation is a high-level overview of the various Vista bitlocker features and some things an investigator should be aware of when conducting forensics involving a bitlocker drive.

Download Here

Windows Vista Forensic Artifacts

I recently presented at CEIC 2007 on Microsoft Windows Vista forensics. The presentation was a brief overview of new features and artifacts that Vista creates as well as some changes in the way Vista does certain things, such as Windows Mail, the recycle bin, etc.

The presentation can be viewed here:
Download Here