Identifying a mounted TrueCrypt volume from artefacts in volatile memory using Volatility 2.

1
Friday, 17th August 2012 Bridgey the Geek <forensicgeekinthecorner@gmail.com>

Introduction
This document illustrates a walk-through for identifying the path of an unknown file which has been mounted as a TrueCrypt volume. The work is done almost entirely using the Volatility 2.1 framework. I have tried hard to make it error-free but the odd one may have crept in. Please feel free to email me corrections.

Thank You
A big thank you to all the contributors to the Volatility user mailing list: it would have been a much more painful experience without your help, and to JSE, my colleague, for his encouragement and interest.

Tools Used
The walk-through is carried out using Microsoft Windows 7 64-bit. Besides Windows, all tools are free to download please observe their licenses. Tool
Volatility Framework 2.1 RegRipper Windows Prefetch Parser Windows USB Storage Parser

Available From
https://www.volatilesystems.com/default/volatility/ http://regripper.wordpress.com/ http://tzworks.net/prototype_page.php?proto_id=1 http://tzworks.net/prototype_page.php?proto_id=13

Useful Resources
Resource
The Volatility 2.1 command reference The Volatility users mailing list

Available From
http://code.google.com/p/volatility/wiki/CommandReference21 http://lists.volatilesystems.com/mailman/listinfo/vol-users

The Scenario
I have been presented with an hard disk drive (HDD) which apparently shows use of a TrueCrypt volume, but initial analysis could not identify the file which is the TrueCrypt volume. As a way of learning about Volatility I have decided to see if I can identify the file which is the TrueCrypt volume from artefacts in the hiberfil.sys. The HDD shows a Windows 7 install with Service Pack 1 (SP1) and has 2 partitions: a 100MB system partition (which is typical of Windows 7) and the remainder of the HDD is in use as the C drive (C:). I have already confirmed that all sectors are accounted for, that is, there is not a block of disk space which might be a hidden partition which is actually a TrueCrypt volume.

The Walk-through
Step 1: Preparation
I have created a folder called 'tc' (TrueCrypt) on the root of my D drive (D:\tc). I have placed a copy of volatility-2.1.standalone.exe in this folder.

I have copied the hiberfil.sys file from the suspect HDD to this folder.

Step 2: Getting the list of processes

My first thought was to take a look at what processes could be found from the hiberfil.sys. The Volatility plugin for this is pslist: D:\tc>volatility-2.1.standalone.exe -f hiberfil.sys --profile=Win7SP1x64 --output-file=pslist.txt pslist As it's the first time, let's break this command line down: volatility-2.1.standalone.exe -f hiberfil.sys --profile=Win7SP1x64 --output-file=pslist.txt pslist The exe of the Volatility framework The f switch specifies the file on which to operate The profile specifies the OS from which the file comes Save output to a file rather than stdout (the screen) The particular Volatile framwork plugin to run

I deliberately specify the arguments in this order because it makes it easier to run other plugins: I can simply use the up arrow to show the last command and then edit the last two parameters of the command. I almost always output to a file as this allows me to manipulate it in gvim (or other tools) and often I forget important details from a particular plugin and so I can simply refer back to the saved output rather than having to rerun the command. When the command finished I opened up pslist.txt. I have snipped and tidied the output for readability. Offset(V)
0xfffffa8006cef9e0 0xfffffa800a24eb30 0xfffffa800a055b30 0xfffffa800a852870 0xfffffa800b02eb30 0xfffffa800b490b30 0xfffffa800713f660

Name
System wininit.exe services.exe winlogon.exe explorer.exe Dropbox.exe

PID PPID Thds Hnds Sess Wow64

4 464 520 636 0 384 464 456 135 3 12 5 82 21 4 530 79 250 127 516 227 -----0 0 1 1 1 0 0 0 0 0 1 1

Start
2012-07-29 08:13:55 2012-07-29 08:14:03 2012-07-29 08:14:04 2012-07-29 08:14:06 2012-07-29 08:14:27 2012-07-29 08:14:55 2012-07-29 08:18:46

2920 2832 3476 2920

2251 1

TrueCrypt.exe 3520 2224

As can be seen, there is a TrueCrypt.exe process, started at 08:18:46, which has a Process ID (PID) of 3520. Therefore, TrueCrypt is running there was no Exit time for the process.

Step 3: A list of devices

As the TrueCrypt file is mounted as a volume it is therefore a device - it should be possible to see something indicative of TrueCrypt using the devicetree plugin: D:\tc>volatility-2.1.standalone.exe -f hiberfil.sys --profile=Win7SP1x64 --output-file=devicetree.txt devicetree For this command I have simply changed the output file and the plugin name. The output file contains 812 lines which I searched for TrueCrypt. I got 3 results: DRV 0x23ea15de0 \Driver\truecrypt ---| DEV 0xfffffa800946f080 TrueCryptVolumeG FILE_DEVICE_DISK ---| DEV 0xfffffa8007127ac0 TrueCrypt FILE_DEVICE_UNKNOWN

Note TrueCryptVolumeG - that tells us that there is a TrueCrypt volume mounted as the G drive (G:). We know that a TrueCrypt process is running and we know there is a TrueCrypt volume mapped as G:.

Step 4: Getting handles associated with the TrueCrypt process

As we have the PID of the TrueCrypt process we can look for handles owned by that process. If we're lucky, there will be a File handle to our TrueCrypt volume file. The plugin for handles is handles. Handles has a number of parameters to allow us to apply filters to what is returned. We are going to use the --pid parameter to filter just for our TrueCrypt process and the -t (type) parameter to filter for only handles of type File: D:\tc>volatility-2.1.standalone.exe -f hiberfil.sys --profile=Win7SP1x64 --output-file=handles-3520-files.txt handles pid=3520 -t File Once finished, the output looks like this: Offset(V) Pid Handle Access
0x100020 0x100020

Type
File File \Device\HarddiskVolume3\

Details

0xfffffa8007 3520 0x1c 10a1c0 0xfffffa8007 3520 0x20 0f6070

\Device\HarddiskVolume2\Windows\winsxs\ x86_microsoft.windows.commoncontrols_6595b64144ccf1df_5.82.7601.17514_none_ec83dff a859149af \Device\HarddiskVolume2\Windows\SysWOW64\enUS\setupapi.dll.mui \Device\KsecDD \Device\HarddiskVolume2\Windows\winsxs\ x86_microsoft.windows.commoncontrols_6595b64144ccf1df_6.0.7601.17514_none_41e697 5e2bd6f2b2 \Device\TrueCrypt \Device\HarddiskVolume2\Windows\Fonts\ StaticCache.dat \Device\HarddiskVolume2\Windows\SysWOW64\enUS\user32.dll.mui \Device\HarddiskVolume2\Windows\winsxs\ x86_microsoft.windows.commoncontrols_6595b64144ccf1df_6.0.7601.17514_none_41e697 5e2bd6f2b2

0xfffffa8006f 3520 0x84 dbc90 0xfffffa8006 3520 0xcc d74670 0xfffffa8007 3520 0x100 0ec580

0x120089 0x100001 0x100020

File File File

0xfffffa8007 3520 0x328 06edd0 0xfffffa8006 3520 0x374 d7c8a0 0xfffffa800b 3520 0x378 408370 0xfffffa8006 3520 0x394 ea2180

0x100080 0x120089 0x120089 0x100020

File File File File

There is nothing especially notable except maybe \Device\HarddiskVolume3\. As previously stated, the HDD only has two partitions so why does TrueCrypt have a handle to a third volume? There must be another volume attached in some way. The files which TrueCrypt has a handle on all seem very reasonable for a Windows application: fonts and common controls. So we didn't get lucky: nothing here seems to be the TrueCrypt volume.

Step 5: Looking up symbolic links

Andrew Case on the Volatility users mailing list informed me that: MHL suggested using the symlink scan command as this will map drive letters to physical

device paths. Maybe the symlinkscan plugin would reveal something about G: or \Device\HarddiskVolume3: D:\tc>volatility-2.1.standalone.exe -f hiberfil.sys --profile=Win7SP1x64 --output-file=symlinkscan.txt symlinkscan Opening the output showed 261 symbolic links. Perusing them I found a number of interesting results: Offset (P)
0x000000016 09a6950 0x000000018 6ea19e0

#Ptr #Hnd
1 1 0 0 0 0 0 0 0 0

Creation Time
2012-07-29 2012-07-29 2012-07-29 2012-07-29 2012-07-29 2012-07-29 2012-07-29 2012-07-29 08:19:14 08:19:14 08:14:05 08:14:05 08:14:05 08:14:05 08:14:05 08:14:05

From
Volume{eb...335ad7f} G: Harddisk1Partition1 Volume{eb...335ad7f} I: STORAGE#V...91efb8b} Partition1 HarddiskVolume3

To
\Device\ TrueCryptVolumeG \Device\ TrueCryptVolumeG \Device\ HarddiskVolume3 \Device\ HarddiskVolume3 \Device\ HarddiskVolume3 \Device\ HarddiskVolume3 \Device\ HarddiskVolume3 \Device\ HarddiskVolume3

0x00000001c8 1 3021e0 0x00000001c8 1 383160 0x00000001c8 1 3842e0 0x00000001c8 1 3849f0 0x00000001c8 1 3c9060 0x00000001c8 1 4b5060

There is a wealth of information here. At 08:14:05 the I drive (I:) was mounted as \Device\HarddiskVolume3 the TrueCrypt process has a handle to the I:. Also, there is a link to \Device\HarddiskVolume3 from Harddisk1Partition1 given that the numbering starts at 0, this is a separate drive to the HDD being examined. At this point, I'm convinced that this I: is crucial to the use of TrueCrypt.

Step 6: Querying the Registry for attached devices

The Windows Registry holds information about attached devices. Volatility has a plugin which allows the printing of a particular Registry key from the volatile memory: printkey. However, I've not been able to find a way to process the SYSTEM\CurrentControlSet\Enum\USBSTOR key using Volatility. Instead, I made use of usp (USBSTOR parser) from tzworks. This application runs on the SYSTEM hive. So having copied the SYSTEM hive from the HDD: D:\tc>usp64 -sys SYSTEM The output gave me 3 devices. Following are the details of one of the devices: Device name vid/pid key update [UTC] ven/prod/rev key update [UTC] Disk Device update [UTC] Volume Device update [UTC] Seagate Portable USB Device 08/01/12 21:18:57.165 08/01/12 21:18:57.198 07/29/12 08:14:05.704 <none found>

Orig Install date [Localtime] Instance ID/Serial # Driver Volume ID Disk ID Volume name Parent ID Prefix Vendor ID Product ID Revision Vendor/product Acct that mounted vol

<none found> 1abcd234____&0 {4d36e967-e325-11ce-bfc1-08002be10318}\0002 <none found> eb944bf9-c98f-11e1-b3e6-80ee7335ad7f <none found> <none found> 0bc2 2300 130 seagate/portable <couldn't search for user w/o volume id>

As can be seen, this device (and only this device) was last updated at the same second the I: was attached to the system. A very strong indicator that this Seagate Portable USB Device is the I: which contains the TrueCrypt data. (I have changed the serial number of the device for this document)

Step 7: Getting handles to files from all processes

After seeing more evidence that the I: was a good place to be looking, I considered another point made by Andrew Case on the Volatility users mailing list: you may want to run [handles] across all processes (the default) because we have seen where files opened by drivers end up in other processes' handles (e.g. SYSTEM). I knew that getting the handles for all File objects from a 5GB hiberfil.sys file would give me a lot of data, but this was a very sensible next step. Plus, I was really only looking for handles to either I: or \Device\HarddiskVolume3\. So back to the handles plugin, but this time not filtering for a process and filtering for File objects: D:\tc>volatility-2.1.standalone.exe -f hiberfil.sys --profile=Win7SP1x64 --output-file=handles-files.txt handles -t File This ran for quite a while and produced 2235 results. There were no references to I:. There were however 15 references to \Device\HarddiskVolume3:

Offset (V) Pid Handle

0xfffffa800 4 9fff3d0 0xfffffa800 4 a002f20 0xfffffa800 4 a000f20 0xfffffa800 4 a87bf20 0xfffffa800 4 a879b20 0xfffffa800 4 a89af20 0xfffffa800 4 a88d370 0xfffffa800 4 a88ebd0 0xfffffa800 4 a87bbc0 0xfffffa800 4 a315910 0xfffffa800 4 713f520 0x3d0 0x3dc 0x3e0 0x3e4 0x3f0 0x3f8 0x3fc 0x404 0x41c 0x708 0xc28

Access
0x12019f 0x120089 0x12019f 0x12019f 0x13019f 0x13019f 0x1 0x12019f 0x12019f 0x120000 0x12019f 0x13019f 0x100081 0x100180 0x100020

Type
File File File File File File File File File File File File File File File

Details
\Device\HarddiskVolume3\$Extend\$RmMetadata\$TxfLog\ $TxfLogContainer00000000000000000002 \Device\HarddiskVolume3\System Volume Information\EfaData\SYMEFA.DB \Device\HarddiskVolume3\$Extend\$RmMetadata\$TxfLog\ $TxfLogContainer00000000000000000001 \Device\HarddiskVolume3\$Extend\$RmMetadata\$TxfLog\ $TxfLog.blf \Device\clfs\Device\HarddiskVolume3\$Extend\$RmMetadata\ $TxfLog\$TxfLog \Device\clfs\Device\HarddiskVolume3\$Extend\$RmMetadata\ $TxfLog\$TxfLog \Device\HarddiskVolume3 \Device\clfs\Device\HarddiskVolume3\$Extend\$RmMetadata\ $TxfLog\$TxfLog \Device\HarddiskVolume3\System Volume Information\EfaData\SYMEFA.DB \Device\HarddiskVolume3\ \Device\HarddiskVolume3\apple \Device\HarddiskVolume3\System Volume Information\tracking.log \Device\HarddiskVolume3\$Extend\$ObjId \Device\HarddiskVolume3 \Device\HarddiskVolume3\

0xfffffa800 956 0x61c acb6580 0xfffffa800 956 0x628 acad560 0xfffffa800 956 0x630 acc5a20 0xfffffa800 352 0x1c 710a1c0 0

The vast majority of the 15 could be ruled out as being part of Windows processes, but 15 is such a low number that one could manually check each in a short amount of time anyway. However, in my mind there were only two likely candidates: 1. \Device\HarddiskVolume3 could the entire volume be a TrueCrypt encrypted volume? 2. \Device\HarddiskVolume3\apple a seemingly meaningless name and no file extension?! The more I thought about this the more I thought candidate 1 wasn't really an option: if the whole volume was encrypted then we wouldn't be seeing files on the volume, for example, candidate 2. However, my TrueCrypt knowledge at this level isn't that great so I kept it as a candidate for now. I'm also sure that something can be discerned from the Access granted to the object, but I'm yet to fully understand that value.

Step 8: The big reveal

Checking the list of seized items, there was indeed a Seagate USB hard disk drive. Examining the device showed that it had very few files on it: they were all known TrueCrypt files, except one: apple.

Other Considerations
Matching the disk signature
Further analysis of the MountedDevices key showed that the disk signature of the I: matched the disk signature of the Seagate Portable USB Device.

Analysing the Truecrypt prefetch file from the HDD

Within the C\Windows\Prefetch folder was TRUECRYPT.EXE-3576920E.pf. This file is the prefetch data for TrueCrypt.exe. Using tzwork's Windows Prefetch Parser I was able to see that: One of the mapped files was: \DEVICE\HARDDISKVOLUME3\TRUECRYPT.EXE. The exe had been launched 4 times, most recently at 07/29/12 08:18:46.416 - 28 seconds before the G: was mounted.

Using RegRipper to look for attached devices

The excellent RegRipper could also have been used to see the timestamp of the Seagate Portable USB Device being attached. Use the devclass plugin.