We've a Win7 platform in our company. In a forensic case we need to extract the partitions, decrypt them to start analyze them.
I decided to go ahead with Deftlinux for acquisition and SANS SIFT for analysation.
In a forensic case i get BIOS password and bitlocker recovery key from our helpdesk to change bootorder (boot from USB memory) and
So I started to do documentation how to do it on my company PC and made a dd of it.
There seems to be a different making a dd from a sdaX partition on the suspect PC to extraction from a sda drive dd.
I've made a dump with a USB Deftlinux Boot memory to an external USB disk.
SIFT comes with dislocker pre installed (v0.2) so tried to do it with that.
o Data acqisition
dcfldd if=/dev/sda bs=512 conv=noerror,sync of=/media/Evidence/[Nodename_Drive/Partition_examiner].dd (and the additional stuff to write down sha1 and md5 fingerprints in a file
I use dcfldd to see progress of doing the image in opposite to dd command.
o check after image is done in SIFT (looks the same in deftlinux)
I had a look on the drive dd layout with mmls
sansforensics@SIFT-Workstation/media/Evidence$ mmls XXXXX_sda_hoc.dd
DOS Partition Table
Offset Sector 0
Units are in 512-byte sectors
Slot Start End Length Description
00 Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01 —– 0000000000 0000015119 0000015120 Unallocated
02 0000 0000015120 0041957999 0041942880 NTFS (0x07)
03 0001 0041958000 0541265759 0499307760 NTFS (0x07)
04 0002 0541265760 0625136399 0083870640 NTFS (0x07)
05 —– 0625136400 0625142447 0000006048 Unallocated
sansforensics@SIFT-Workstation/media/Evidence$
remark
SDA1 is a hidden service partition
SDA2 is drive C
SDA3 is drive D
o extraction partition from drive dd
dcfldd if=XXXXX_sda_hoc.dd of=XXXXX_sda3_hoc.dd bs=512 skip=$[541265760-1] count=$[625136399-541265760+1]
o dd of partition on the suspect PC
dd if=/dev/sda3 of=/encrypted.bitlocker
o comparing both partitions
root@SIFT-Workstation/media/Evidence# ls -ln
total 667067280
-rw-r–r– 1 0 0 42941767680 2013-03-16 2143 encrypted.bitlocker
-rw-r–r– 1 0 0 21474754560 2013-03-14 0808 XXXXX_sda1_hoc.dd
-rw-r–r– 1 0 0 255645573120 2013-03-16 1204 XXXXX_sda2_hoc.dd
-rw-r–r– 1 0 0 42941767680 2013-03-16 1955 XXXXX_sda3_hoc.dd
-rw-r–r– 1 0 0 320072933376 2013-03-14 1132 XXXXX_sda_hoc.dd
-rw-r–r– 1 0 0 55 2013-03-14 1305 XXXXX_sda_hoc_sha1.txt
encrypted.bitlocker is made with dd on the suspect PC
XXXXX_sda3_hoc.dd is made with dd from the drive dd.
Both have the same size but looks different in hex editor
encrypted.bitlocker starts with EB 58 90 2D 46 56 45 2D 46 53 2D = .X.-FVE-FS-
XXXXX_SDA3_hoc.dd starts with EC 5C 42 3B B7 FF B3 EA 91 99 39 with no valid NTFS/ bitlocker header.
o dislocker
dislocker -v -V encrypted.bitlocker -p – decrypted.ntfs
it ask me for the recovery key and says
Sun Mar 17 153851 2013 [CRITICAL] Can't initialize keys. Abort.
Is there anything i made wrong on the move (wrong adress to extract)?
Got a hint from the developer of dislocker. Need to have a closer look on the github version (0.2.3) this evening.
It works with dislocker 0.2.3 from github. Sift with it's underlying Ubuntu Karmic seems to be to old, so that errors have to been disabled while doing the make.
o Installation in Sift
Install git to load sources from dislocker
In the process of installation say y to install.
sudo su
apt-get install git-core
cd /usr/local/src
sudo su
git clone git//
cd dislocker-git
pico src/accesses/rp/Makefile
remove -Werror in line 9 than write out, exit
cd src
make file
make install
dislocker --help should show v0.2.3 now
o dislock a bitlocker partition
mkdir /mnt/dislocker
remark dislocker wants to have an empty mount so the unlocked file/ mount couldn't be written to the mount where the evidence (encrypted.dislocker) is located
This needs to be done once in SIFT.
Remark 123456-… stands for the existing recovery key. This one is only a placeholder.
dislocker -v -r -V encrypted.bitlocker -p123456-123456-123456-123456-123456-123456-123456-123456 -- /mnt/dislocker
The last command writes a file called dislocker-file to /mnt/dislocker
o Loop mount the dislockt file
This needs to be done once in SIFT.
mkdir /mnt/decrypt
This will mount the decrypted file read only to /mnt/decrypt
mount -o loop,ro /mnt/dislocker/dislocker-file /mnt/decrypt
o Unmount
remark The mount of dislocker-file (/mnt/decrypt) is a normal mount. In opposite to this the fuse mount of the dislocker tool (/mnt/dislocker with the included dislocker-file) is a filespace in userspace.
umount /mnt/decrypt
fusermount -u /mnt/dislocker
I currently can only open the dislockt files in the mount with Sleuthkit. DFF and PTK doesn't like the mount (doesn't show it). Maybe a problem with the userspace mount of the bitlocker image?
Just installed fedora18 with CERT-Forensics-Tools to verify the testings with SIFT. Installation description could be much better to get the CERT stuff installed. Have to install dislocker from source again and will see..
Just also wanted to have a closer look on the new DFF 1.3 which comes with the CERT install package - but it crashs on start.
/edit
The crash is Firefox related. I forced to reinstall Firefox 22 which prevented the crash of Firefox.
[…]
I decided to go ahead with Deftlinux for acquisition and SANS SIFT for analysation.
[…]
Why? Why introduce a third party product for BitLocker, when the company OS already has it built into it? It increases your error rate.
Our SOP for something like this would be
Get the BitLockered drive out of the machine.
slave it to a Windows 7 machine through write-blocker.
Provide BitLocker key to OS when demanding it at boot up
Run FTK Imager to image full HDD as is (encrypted)
Run FTK Imager to image full HDD through OS, decrypted
This allows us to provide "original", that is the full image, and the actual content.
Not just that, we can create a VHD from the original image, and Win7 will see it as normal BitLockered drive and ask for code again. Perfect to provide to the other side.
Thereafter you can analyze it to your heart content with anything you need.
There is also the library libbde available on linux for this very purpose.
https://
I currently have a closer look on CERTs ADIA
http//
ADIA used to have the latest software installed and get regulary updates.
With CERTs ADIA you can also read bitlocker encrypted devices
sudo su
yum install libbde
yum install libbde-tools
This enables ADIA to read from bitlocker drive encryption (bde). The version from 20130422 will be installed. There's also a version from 20130626
https://
General libbde info
http//
Mounting bitlocker devices
http//
/edit
Seems to be that libbde/ libbde-tools only works with drive images and not partition raw files - still with version 20130626.
Looks the same like here https://
/edit2
Compiled again libbde 20130626 with verbose output enabled and tried again. I can decrypt a raw partition. Maybe I made yesterday an error. Also bdeinfo shows up the correct encryption info.
[…]
I decided to go ahead with Deftlinux for acquisition and SANS SIFT for analysation.
[…]
Why? Why introduce a third party product for BitLocker, when the company OS already has it built into it? It increases your error rate.
Our SOP for something like this would be
Get the BitLockered drive out of the machine.
slave it to a Windows 7 machine through write-blocker.
Provide BitLocker key to OS when demanding it at boot up
Run FTK Imager to image full HDD as is (encrypted)
Run FTK Imager to image full HDD through OS, decryptedThis allows us to provide "original", that is the full image, and the actual content.
Not just that, we can create a VHD from the original image, and Win7 will see it as normal BitLockered drive and ask for code again. Perfect to provide to the other side.Thereafter you can analyze it to your heart content with anything you need.
I'm faced with some malware on some of our systems and I'll like to seperate host and investigation platform and like not to be infectibable by windows malware on the investigation system. I saw malware which wasn't detected by major AV companies by over 4 weeks.
My plan is to use ADIA/ Sift with virtual box on a Mac in future.
Evidence drive is ext4 formatted and is not accessible by the Mac as default. Looks to be paranoid but that's experience.
And I don't like to have a system not knowing what the software is doing (eg Encase 7).
You could image the original drive as is, convert the image to VHD, and OS will see it and request BitLocker key for it as if it was the real, original drive.
The whole process can be done inside a VM.
The evidence drive is ext4 and is running BitLocker?
I agree - the more I know about a process, the more confidence I have in my conclusions.
You could image the original drive as is, convert the image to VHD, and OS will see it and request BitLocker key for it as if it was the real, original drive.
The whole process can be done inside a VM.
The evidence drive is ext4 and is running BitLocker?
I agree - the more I know about a process, the more confidence I have in my conclusions.
The evidence drive is ext4, containing the bitlocker images .dd files I acquired with Deft Linux from suspicious PCs.