One of the challenges posed by Vista to traditional forensic analysis is the use of BitLocker to encrypt data on the hard drive. However, this really isn't any different from other similar technologies such as PGP, etc., that already allow encryption of files, partitions, or drives.
The response to encountering active drive encryption, particularly when dealing with an uncooperative suspect, should be to acquire a live image of the system hard drive, as in many cases, powering off the system and removing the hard drive may result in encrypted data being imaged, and until we get some kind of instantaneous image translation technology, that would be a "Bad Thing" for analysts.
So, when approaching a system, how does one tell whether or not there's any drive encryption in use? Well, Hogfly wrote an excellent WMI VBS script for detecting BitLocker. Using Perl, you could implement this script and then "compile" it into a standalone EXE and run it from a CD prior to imaging.
At this point, all we'd need to do is come up with other "signatures" for drive encryption that we can look for. Using a checklist of visible references to look for on the screen, and combining that with a small applet that would be run from a CD and tell the responder (ie, LEO, etc.) if drive encryption was active and in-use, would likely be the best approach.
Thoughts?
10 comments:
I assume BitLocker support requires a driver (or two). Could you check for the presence of those drivers? Are they loaded if BitLocker is not running? (I'm speculating here...)
"Well, Hogfly wrote an
excellent WMI VBS script for detecting BitLocker."
Using WMI may cause a new process to start, namely the WMI service, if the service is not already running. This is the default case on desktop systems. This does not necessarily mean that WMI should not be used. However, investigators need to understand the effects which this script may have on a running computer system.
- Rossetoecioccolato.
Using WMI is actually a recommended method of determining whether or not bitlocker is active. There's a raw disk structure that identifies bitlocker on the disk.
Troy Larson responded as to how he detects bitlocker in a comment on my blog.
The MSDN blog link for bitlocker detection:
http://blogs.msdn.com/si_team/archive/2006/10/26/detecting-bitlocker.aspx
Hogfly,
Thanks for the MSDN blog reference as it may be of value to me in the future. WMI is the recommended method from a general programming perspective. Forensic applications have special requirements, however; namely, to minimize alterations to the subject system. I am simply pointing out that the choice of WMI has forensic implications which need to be understood and which you do not discuss in your blog. I do think that there is a sound application of WMI within the "live" forensic context, for example, after you have acquired the physical memory. We are also (unavoidably) using WMI in our remote (enterprise) forensic tool deployment application. However, the impacts need to be documented so that resulting output will be defensible as evidence.
- Rossetoecioccolato.
Not trying to promote a product but x-ways capture will look for bitlocker and other encryption programs and will logically copy the files as well as imaging the disk. I wrote about using this software to do a remote acquistion of a computer on the network on my blog. It is a pretty slick tool and inexpensive for what it can do. The size of the main program is aprox 160 KB. It will run on both linux and windows.
Mark,
X-Ways Capture is a nice product. Do they document what method they use to detect encrypted volumes or whether or not they are using WMI? You can probably tell if they are using WMI by dumping the strings.
- Rossetoecioccolato.
From the documentation (sorry it is so long):
a) EncryptionCheckProcessList:
The names of active processes are matched against a list with the names of known
Windows-based encryption software programs, specified in the section
X-Ways Software Technology AG • Agrippastr. 37-39 • D-50676 Köln
Web: http://www.x-ways.com • E-Mail: mail@x-ways.com • Tel.: +49-221-420 486 5 • Fax: +49-721-151 322 561
X-Ways Capture 1.16 4/9
[SearchProcessesFor Encryption]. For example, the name of the resident
service/process of PGP Desktop 9.02 is “PGPserv.exe”.
b) CheckDriverListForEncryption
Searches the driver list creating by DumpDriverList for driver names taken from the
section [SearchDriverListForEncryption]. If the driver list has not been created yet, it
is produced for this step.
c) EncryptionCheckProcessMemory:
The loaded .exe files of all running processes are searched for keywords that appear
in the [SearchProcessMemory] section of the configuration file, both in the ASCII
and the Unicode character set. With this approach, X-Ways Capture can identify a
known encryption software product even if its .exe file has been renamed such that
the running process has an unexpected name. Suitable keywords are e. g. internal
program names or copyright notices as they appear the version information within
.exe files. E. g. “PGPsdkService” is the internal name of the service “PGPserv.exe”.
d) EncryptionCheckDiskSectors
Unless access is prevented by missing administrator rights: Certain sectors on each
hard disk are read with two different methods. The results are compared. Different
results indicate that the hard disk is encrypted by a resident software such as
“SecureDoc” or “CompuSec”.
e) EncryptionCheckAllFiles
All files on NTFS drives are checked for EFS encryption. This stage is usually the
most time-consuming one in this section, depending on the number of files on NTFS
drives. This test excludes the drive that X-Ways Capture was started from as well as
the output drive. This step is useful only if Logicalbackup is skipped, since
LogicalBackup will always copy and report EFS files under Windows. The
parameter network controls whether this step affects network drives. +network
enables encryption search on network drives, -network disables this. –network is the
default.
f) CheckForBitLockerVolumes
All mounted volumes are checked for a BitLocker signature.
I am sure if you had any quesitons Stefan Fleischmann would be happy to answer them.
-- Mark
George,
You make a good point, and I did not mention the implications of using WMI - something I'll spend a bit of time on. However as I'm sure you know, even the act of capturing memory displaces its contents and has its own implications. Minimizing impact is of course the objective, and I'll have to explore what exactly the script changes on a system.
If I had to make an educated guess - which is all I can do right about now...I'd guess it:
-creates a new svchost.exe process
-accesses associated dll's
-displaces a small amount of memory
Vista has the WMI service enabled by default, so starting the service isn't a real concern --unless it's been disabled, which can be detected pretty easily.
Can't we just count on Microsoft's usual half-assed approach and total cluelessness about encryption?
Everything they've made so far has been crackable if you have physical access to the system.
Anonymous,
In your rush to MS-bashing, you've missed the point of the post and comments all together.
Jesse...yes, you're right, there is a driver, and that is one way to check. There's also a signature on the drive that may be able to be queried, as well.
Post a Comment