Test It Before Encrypt It

This is not about acquisition tools, but about understanding why we need to test our tools even if the tool was just updated.  The latest and greatest tool without testing can be a risk factor just like the old and worthless.
I remember how excited I was to test TIM (Tableau IMager) on a multi core system and see it outperform the competition.  It was just as much exciting as finding out about Access Data’s FTK Imager CLI.  It was not about the performance improvement ( since there was none ), but the OS support and the ability to encrypt images using a certificate.
It’s been working great, but in the latest version something has changed.  Using version 3.1.1 to acquire an image on Windows 7 Professional 32/64 bit worked as it was advertised.

C:\temp\ftkimager>ftkimager.exe \\.\physicaldrive1 c:\temp\usb --e01 --outcert C:\temp\pub.cer
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Creating image...
Image creation complete.

The image was opened in FTK Imager 3.0.1 using the private key and the given password and FTK Imager was happy to comply.  Of course, the question can come up to verify the image in the tool that created it.  Surprisingly, the newest version of the software gave an error message and refused to take the private key with the password that worked just fine in GUI.

C:\temp\ftkimager>ftkimager.exe c:\temp\usb.e01 --verify  --incert c:\temp\pri.pfx p@$$w0rd
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Error setting up decryption: DecryptWithPrivateKey: Cert encrypted and password failed: c:\temp\pri.pfx
** AD Decryption setup failed.

This seemed to be odd since new version of software supposed to fix problems and not break what was working just fine.  The natural thing was to think that it must have been the command line options I used, the spelling of words, or the spaces.  Then, the private key and password were blamed.  Then, in a final attempt, I wanted to see if the previous version was able to access the image and verify it.  It worked.  It felt grate to verify that I do know how to spell and remembered my password correctly.  The image was not lost and a lesson was learned about the value of tool testing.

C:\FTK ImagerCLI 2.9.0_Win32>ftkimager.exe c:\temp\usb.E01 --verify --incert c:\temp\pri.pfx p@$$w0rd
AccessData FTK Imager v2.9 CLI (May 11 2010)
Copyright 2006-2010 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Verifying image...
Image verification complete.
[MD5]
 Computed hash: 08d27c2233aee57c95ddecb0386e1e6f
 Image hash:    08d27c2233aee57c95ddecb0386e1e6f
 Report hash:   08d27c2233aee57c95ddecb0386e1e6f
 Verify result: Match
[SHA1]
 Computed hash: 38e1d87975594abd14608960e2236737619f08db
 Image hash:    38e1d87975594abd14608960e2236737619f08db
 Report hash:   38e1d87975594abd14608960e2236737619f08db
 Verify result: Match

Problems like this must be treated as a valuable lesson that no books and training classes can relay.  Know your tools and you should treat every update with caution.  Maybe there is a good reason for projects like NIST’s Computer Forensics Tool Testing (CFTT) Project.  It would have been an interesting feeling to find out that you couldn’t decrypt an encrypted evidence file.  There no substitute for risk management and methodological problem solving.  I do hope, that AccessData will remedy this issue and will not create another "teachable moment" in future releases. 

P.S. It still does not make sense why the User Manual PDF file does not show the -- ( double dashes ) that are required for the options to work.  It's been like that since the first release.

FTK Imager CLI with Certificate

Abstract

Learn how to use command line imaging tool, FTK Imager CLI, using certificate based encryption.

Explanation

In some cases, you will have to collect evidence in a remote site or hire someone to collect the evidence for you.  In that case, you will allow the person acquiring the evidence physical access to the drive, but if you do not want that person to make a copy and later examine the image of the acquired drive, then you’ll need to protect it.  Understanding Public Key Infrastructure ( PKI ) is very important and this exercise will help you understand it usage.  The main idea is that you need to create two keys, one public and one private.  In order to encrypt data, you will need the public key.  In order to decrypt it later, you will need to apply the corresponding private key.  Thus, only the person can see the saved data who has the private key.  A person who has access to the public key is allowed to encrypt the data, but since that person does not have the private key. He/she will not be able to decrypt it afterwards.  Therefore, it is a safe method to give your public key to a person acquiring an image.  That person can acquire the image and ship it to you and no one will be able to decrypt it, only you.  Let’s try it.

Before You Begin

Enable write blocking of storage devices on your workstation to provide software write blocking for the evidence.  It can be done using regedit Graphical User Interface ( GUI ) or Command Line Interface ( CLI ).  You can also download simple software to accomplish the same, but you should practice the GUI and especially the CLI methods until you feel comfortable with the concept.  This will also allow you to realize that simple text based scripts can change registry settings or these types of commands could be sent over the network.  More you learn about command line commands, more you develop pattern recognition, thus anomaly detection.

Key, value, and data you’ll need to create to enable write blocking.  Data of 00000000 will disable the write blocking.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
“WriteProtect”=dword:00000001

Command line to accomplish the same ( change data to 00000000 in order to disable write blocking )

C:\>reg add HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies\ /v WriteProtect /t REG_DWORD /d 00000001

You should insert a USB thumb drive into the acquisition workstation and test the write blocking by trying to copy a file onto your thumb drive.  If you receive an error message that you are not allowed to write to the device, then you can remove the thumb drive and insert your evidence you are trying to collect.

Create a certificate that you will use to acquire devices

If you do not already have a certificate that you could use, then you can create one in Windows and use it to encrypt your images.  The easiest way to create a certificate is to use EFS and export its certificate.

Type cermgr.msc  to see if you already have a certificate that you might use for your acquisition.  If you do not see a certificate listed in your persona certificates, then you will have to create one by encrypting a new file with EFS.

If you do not see a certificate in the personal certificate folder, then create a new file and encrypt it with EFS.  Then, refresh the certificate manager window and you should see a certificate was created.

Internet Explorer also shows the available certificates in its Content menu.  Internet Explorer also allows you to export the certificate to backup or to use in acquisitions.

Since our goal is to give only the public key to the person performing the acquisition for us, you can export the certificate without the private key.  This way, only the public key will be stored in the certificate.

After you have exported the public key, you will also export the private key at this point.  Since we are using the EFS certificates, it might change later as you change your login password.  Therefore, it is best to export the private key at the same time and save it in a location not accessible by anyone, but you.  If you lose this private certificate, then you will not be able to access any one of the images created by the public key.  So, be careful and handle the private key with care.  If you do lose your private key, you might try to re-export the private key from the machine you exported it from the first place and try to see if it will decrypt the image. 

After you’ve saved the private key, make sure you not just delete the private key from the storage device, if you have to move it to another location, but wipe it so on one will be able to recover it.

In our case, we just store the public and private keys in the same folder for ease of access.

Note: You can also use the EFS recovery keys for this purpose.  You can just generate these with cipher utility from the command line.
C:\>cipher /r:acquire
Please type in the password to protect your .PFX file:
Please retype the password to confirm:

Your .CER file was created successfully.
Your .PFX file was created successfully.

02/20/2013  11:02 AM               892 acquire.CER                       //you can rename this to public.cer
02/20/2013  11:02 AM             2,686 acquire.PFX                       //you can rename this to private.pfx

CER - Certificate file contains the public key
PFX - Contains a certificate (CA-issued certificate or self-signed certificate) and a corresponding private key

Read New Features

Note: Your version of FTK Imager CLI might be different, but the procedure should be the same

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe /?

AccessData FTK Imager v2.9 CLI (May 11 2010)

Copyright 2006-2010 AccessData Corp., 384 South 400 West, Lindon, UT 84042

All rights reserved.

Usage:  ftkimager source [dest_file] [options]

source can specify a block device, a supported image file, or `-' for stdin if dest_file is specified, proper extension for image type will be appended if dest_file is `-' or not specified, raw data will be written to stdout

Options:

  --help        : display this information

  --list-drives : show detected physical drives

  --verify      : hash/verify the destination image, or the source image if no destination is specified

  --print-info  : print information about a drive or image and then exit

  --quiet       : do not show create/verify progress information

  --no-sha1     : do not compute SHA1 hash during acquire or verify

(The following options are valid only when dest_file is specified):

  --s01         : create a SMART ew-compressed image

  --e01         : create an E01 format image

  --frag x{K|M|G|T} : create image fragments at most x {K|M|G|T} in size

                  also accepts kB, MB, GB, and TB for powers of 10 instead of 2

  --compress C  : set compression level to C (0=none, 1=fast, ..., 9=best)

  e01/smart metadata (use quote marks when X contains spaces):

    --case-number X

    --evidence-number X

    --description X

    --examiner X

    --notes X

AD Encryption Options:

  --inpass P      : decrypt source file using password P

  --incert C [P]  : decrypt source file using certificate C with password P

  --outpass P     : encrypt dest file using password P

  --outcert C [P] : encrypt dest file using certificate C with password P

Use FTK Imager CLI to acquire/verify images

List available drives attached to your workstation and select the appropriate drive to acquire.  In my case, it will be \\.\PhysicalDrive1

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe --list-drives

\\.\PHYSICALDRIVE0 - ST96812AS ATA Device [60GB IDE]

\\.\PHYSICALDRIVE1 - USB Flash Memory USB Device [1GB USB]

\\.\PHYSICALDRIVE2 - ST964032 2AS USB Device [640GB USB]

Make sure you understand the options you will need in order to get the desired results.  In this case, I used the option –print-info that will print information about the drive and exit.  Thus, it did not create an image file, only printed the drive info.  It would be very surprising if you thought you created the image this fast and moved on to the next drive to image thinking that you’ve created the image of this drive.  Do not move to the next drive until you’ve verified the image was created properly.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe \\.\physicaldrive1 c:\temp\ image-encrypted --verify --print-info --e01 --outcert pub-cer.cer

Physical Evidentiary Item (Source) Information:

[Drive Geometry]

 Cylinders: 231

 Tracks per Cylinder: 255

 Sectors per Track: 63

 Bytes per Sector: 512

 Sector Count: 3,719,167

[Physical Drive Information]

 Drive Model: USB Flash Memory USB Device

 Drive Serial Number: u

 Drive Interface Type: USB

If you use the proper options, you should have the image created and encrypted with the public key.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe \\.\physicaldrive1 c:\temp\

image-encrypted --e01 --outcert c:\temp\public.cer

Creating image...

Image creation complete.

Because we encrypt with public key, we need to decrypt the image with the corresponding private key.  Having the private key is not enough to decrypt the image since we have protected the private key with a password.  Thus, we have to supply the private key password in order to successfully decrypt the image.  Therefore, if you require the person performing the acquisition to also verify the image, you will have to provide the corresponding private key and its password to do so.  That will defeat the purpose of only giving out the public key in order to provide some level of confidentiality to the collected image.  You will have to decide on setting the policy for this.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe c:\temp\image-encrypted.e01  --verify

 --incert c:\temp\private.pfx

Error setting up decryption: DecryptWithPrivateKey: Cert encrypted but no password provided: c:\temp\private.pfx

** AD Decryption setup failed.

If you provide the corresponding private key and the correct password, FTK Imager CLI will verify your image.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe c:\temp\image-encrypted.e01

--incert c:\temp\private.pfx pass1111111111

Verifying image...

Image verification complete.

[MD5]

 Computed hash: df82774348e9a784b631841203bb428d

 Image hash:    df82774348e9a784b631841203bb428d

 Report hash:   df82774348e9a784b631841203bb428d

 Verify result: Match

[SHA1]

 Computed hash: feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Image hash:    feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Report hash:   feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Verify result: Match

You can also fragment the image using FTK Imager CLI.  In this case, I fragment the image to 400MB per portion.  Each portion will also be encrypted.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe \\.\physicaldrive1 c:\temp\

image-encrypted-fragmented --frag 400M --e01 --outcert c:\temp\public.cer

Creating image...

Image creation complete.

In order to verify the fragmented image, only list the first portion of the image file for the complete verification.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe c:\temp\image-encrypted-fragmented.e01 --verify --incert c:\temp\private.pfx pass1111111111

Verifying image...

Image verification complete.

[MD5]

 Computed hash: df82774348e9a784b631841203bb428d

 Image hash:    df82774348e9a784b631841203bb428d

 Report hash:   df82774348e9a784b631841203bb428d

 Verify result: Match

[SHA1]

 Computed hash: feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Image hash:    feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Report hash:   feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Verify result: Match

Take an image of the same drive with FTK Imager and compare the resulting hash values to the FTK Imager CLI acquired image files.

To verify if FTK Imager can open the encrypted image, try to open the image created and encrypted by FTK Imager CLI. 

As you can see in the following image, FTK Imager identifies the encrypted image and asks you to enter either a password or a certificate.  In this case, we used the public key to encrypt the image, so we need to point FKT Imager to the corresponding private key and enter the protective password.

Just to see what will happen, you should also try to point FTK Imager to the wrong private key or enter a wrong password and learn about the error messages you will get.  In this case, I’ve entered a wrong password.

You should also learn and realize that not every image will be encrypted, so when you try to verify an image that was created with FTK Imager, you can just use the standard commands and verify the image.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe c:\temp\image-ftkimager.E01  --verify

Verifying image...

211.28 / 1816.00 MB (30.18 MB/sec) - 0:00:00 left

Verifying image...

Image verification complete.

[MD5]

 Computed hash: df82774348e9a784b631841203bb428d

 Image hash:    df82774348e9a784b631841203bb428d

 Report hash:   df82774348e9a784b631841203bb428d

 Verify result: Match

[SHA1]

 Computed hash: feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Image hash:    feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Report hash:   feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Verify result: Match

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe c:\temp\image-encrypted-fra

gmented.e01 c:\temp\image-concatenated --incert c:\temp\private.pfx pass1111111111

Creating image...

Image creation complete.

C:\FTK ImagerCLI 2.9.0_Win32\FTKImager>ftkimager.exe c:\temp\image-encrypted-fragmented.e01 c:\temp\image-raw-verified --frag 400M --verify --incert c:\temp\private.pfx pass1111111111

Creating image...

Image creation complete.

Verifying image...

Image verification complete.

[MD5]

 Computed hash: df82774348e9a784b631841203bb428d

 Report hash:   df82774348e9a784b631841203bb428d

 Verify result: Match

[SHA1]

 Computed hash: feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Report hash:   feba86a9bb7d050e9a8ac914a8b5a5071ad5393c

 Verify result: Match

Observations

As you can see, the help file for FTK Imager CLI specifies the encryption option as “AD Encryption Options” or AccessData Encryption Options.  That means using password or certificate based encryption will only be decrypted by AccessData products.  Make sure you use the AD encryption sparingly and only use it after you feel very comfortable with the concept. 

UserAssist

We talk a lot about UseAssist key and its structure, but I don;t see much talk about what it really means to forensic investigators.  We've seen its structure change since WinXP and now the run count starts from 0 instead of 5 and it has some strange structures, but the time is still there to interpret. 

First of all, we need to understand what we have to check in order to see if it should keep the list of programs that were executed by the user.  If the values are empty, you should not jump to the conclusion that your suspect must have used an evidence eliminator.  It might have been set by the user previously or by the network administrator group policy.

The following image shows the settings that control is you see anything under your UserAssist key in the registry.  Un-checking the first check box not just disable the application logging, but it also clears the UserAssist key of any existing entries. 






The following registry keys correspond to the check boxes above.

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_TrackDocs
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_TrackProgs









Disabling the program logging ( TrackProgs ) will also update the following key.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.exe\OpenWithProgids\exefile

Since the start Menu properties window also includes the Power Button Action settings, every time you apply your settings changes, you will see this value also accessed.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_PowerButtonAction

Note: Just in case if you are interested, its values are:
2             - shut down
1             - log off
256         - switch user
512         - lock
4             - restart
2097168 - sleep

So, the main question I wanted to answer was: Is UserAssist key keeps track of applications that were ran on a machine by a user?




Legend:
Green - Always 0s or Fs
Pink - Run count
Blue - Focus count
Orange - Focus time
Light orange - always same
green - always Fs
Purple - last run time
Red - unused

As you can see above, I can see that I launched calc.exe from its default location twice ( pink area ), but after I've moved it to c:\temp and wanted to start calc.exe, it did not launch and still showed the application run count.  Therefore, my conclusion is that you can not reliably determine how many times a user used an application, but how many time he/she tried to use it.