Friday, March 16, 2007

Detecting BitLocker

Recently there's been a lot of concern about Bitlocker interfering with our ability to forensically analyze a system. I have to thank Microsoft for something...You've managed to force the issue of Live Response! Harlan Carvey has pointed out that Vista doesn't present any significant challenges to forensics, and I agree. But I do think it will modify the way we approach a system. In an effort to help people cope with their Bitlocker worries, I've written a REALLY BASIC script that will detect Bitlocker's presence on a computer. I decided to write it in VBS first with the hopes of porting it to perl very soon.

First off, let me say I'm no coder, I just dabble in a lot.

That said, Microsoft now provides two WMI classes that allow us to identify TPM usage and Bitlocker.
First we'll look at TPM. TPM is a hardware module that allows among other things, whole disk encryption. In Vista you can access and control TPM through the tpm console (tpm.msc). Once you've enabled and activated the TPM in the bios, you allow Vista to control what goes on. I'll go more in to this at a later time..

So, to access the TPM through WMI you need to use the new namespace:
and the class is Win32_Tpm.
More info is here

To take a look at bitlocker(which is far more interesting if you ask me) you need to use this namespace:
and the class is Win32_EncryptableVolume.
More on Bitlocker here

And now without further's my whopping Bitlocker detector!
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2\Security\MicrosoftVolumeEncryption")
Set colItems = objWMIService.ExecQuery( _
"SELECT * FROM Win32_EncryptableVolume",,48)
For Each objItem in colItems
Wscript.Echo "-----------------------------------"
Wscript.Echo "Bitlocker Encryptable Volumes"
Wscript.Echo "-----------------------------------"
Wscript.Echo "DeviceID: " & objItem.DeviceID
Wscript.Echo "DriveLetter: " & objItem.DriveLetter
Wscript.Echo "EncryptionMethod: " & objItem.GetEncryptionMethod

Here's what it looks like from my end:
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Bitlocker Encryptable Volumes
DeviceID: \\?\Volume{a1380f14-d3c6-11db-a066-00188b27a6b9}\
DriveLetter: F:
EncryptionMethod: 0

Obviously..I'm not using bitlocker yet, but my file system is ready for it.

Caveats: You need an administrative command prompt.

I'll keep plugging away on this..but it's a start.


TDog said...

I have seen quite a few Bitlocker machines and there is a very quick way to determine whether you even need to be concerned about Bitlocker. Bitlocker must have at least two partitions: a small partition of at least 1.5 GB for boot, and the partition containing the system. The small partition needs to be the active partition.
If I see this configuration, then I prepare myself for Bitlocker.

hogfly said...

Very true however it's not conclusive enough simply to look at a disk and see two partitions. What if they are the same size? Also, separating your boot and system partitions used to be recommended by Microsoft for performance reasons so I would imagine it's likely that people still might follow this information. Granted of course..all of the docs I've read from Microsoft and others is to use the 1.5GB boot partition.

echo6 said...

You could also just use the manage-bde.wsf script already available on Vista machines.

manage-bde.wsf –status

Queries all mounted volumes and ascertains if BitLocker encryption is used and what methods have been deployed e.g. TPM, external key or numerical key etc.

Simon said...

actually there's a fatal flaw in your script (which took me a few hours to work out).

objitem.getencryptionmethod returs the RESULT CODE of the call, not the result itself - so it will return 0 if the call was successful. To get the actual encryption method, you have to get a return value back, for example

status = objItem.GetEncryptionMethod(theMethod)

themethod will be the actual method, and status will tell you if it worked or not.

If you read the MSDN again, you'll see it's obvious, but everyone seems to have missed it.