Tuesday, November 20, 2012

Verify your applications and service status

In order to evaluate the value of an artifact, we have to verify if the evidence exists as a result of a properly functioning service.  Since user generated data is hearsay and computer generated data is admissible as business records, we have to make sure the service was functioning as intended.  In order to establish this, we need reliable tools that can help us identify artifacts related to the data in question.  USN journal is the way volume management keeps records of file/directory changes.  FTK Imager did not interpret this data even as recently as version 3.0.1.  As you can see in the screen shot below, even though, the directory $Extend shows the item $UsnJrnlata, it does list it as an item in the File List.


 $UsnJrnlata also shows in the $LogFile with the MFT record for $UsnJrnl. 



$UsnJrnl does show up properly in FTK Imager version 3.1.1 as a 0 size file.  



If we look at the  $UsnJrnl file, we can see that it contains two Alternate Data Streams ( ADS ) one $J that contains all the changes to files and directories; and $Max that contains FILETIME based date that is used as Usn Journal ID.  ( fsutil usn queryjournal c: )
Usn Journal ID   : 0x01cb228e91afda72
First Usn        : 0x0000000040340000
Next Usn         : 0x00000000427485a8
Lowest Valid Usn : 0x0000000000000000
Max Usn          : 0x7fffffffffff0000
Maximum Size     : 0x0000000002000000
Allocation Delta : 0x0000000000400000



 $UsnJrnl does not exists by default on USB thumb drives unless the administrator decides to create it manually.  Thus, even if you have the application that can interpret the data structure, you need to make sure if it is suppose to exist.  You can run fsutil usn enumdata 1 0 1 C:, where C: is the drive you want to view if it has this service enabled.  Anyone with administrative right can create this journaling on any NTFS drive,
fsutil usn createjournal m=1000 a=100 C:.  Also, this data can be deleted from the device
fsutil usn deletejournal /D C:.  


Reason decoded in this example: 07 80 00 80 -> 0x80008007
0x80000000  close
0x00000001  overwritten
0x00000004  truncated
0x00000002  extended
0x00008000  A user has either changed one or more file or directory attributes, or one or more time stamps.
------------------------------------------
0x80008007  result to be saved in journal


Version 2 structure
typedef struct {
  DWORD         RecordLength;
  WORD          MajorVersion;
  WORD          MinorVersion;
  DWORDLONG     FileReferenceNumber;
  DWORDLONG     ParentFileReferenceNumber;
  USN           Usn;
  LARGE_INTEGER TimeStamp;
  DWORD         Reason;
  DWORD         SourceInfo;
  DWORD         SecurityId;
  DWORD         FileAttributes;
  WORD          FileNameLength;
  WORD          FileNameOffset;
  WCHAR         FileName[1];
} USN_RECORD_V2, *PUSN_RECORD_V2, USN_RECORD, *PUSN_RECORD;
 
Version 3 structure
typedef struct {   
DWORD         RecordLength;   
WORD          MajorVersion;   
WORD          MinorVersion;   
BYTE          FileReferenceNumber[16];  
 BYTE          ParentFileReferenceNumber[16];  
 USN           Usn;  
 LARGE_INTEGER TimeStamp;  
 DWORD         Reason;   
DWORD         SourceInfo;  
 DWORD         SecurityId;  
 DWORD         FileAttributes;  
 WORD          FileNameLength;  
 WORD          FileNameOffset;  
 WCHAR         FileName[1]; 
} USN_RECORD_V3, *PUSN_RECORD_V3; 
 
http://msdn.microsoft.com/en-us/library/aa365722%28VS.85%29.aspx
 
Testing Procedures 


1. Default USB Drive Configuration

11/20 1:44pm copy file1.txt to g:\
copy f.txt 1:45
copy g.txt 1:45
open file1.txt 1:45
added to file1.txt 1:46
copy h.txt 1:47
copy test.jpg 1:48
added to file1.txt 1:50
added journaling 1:54
                                   fsutil usn createjournal m=1000 a=222 g:




2. After Journaling Enabled
g.txt h.txt deleted 1:53
added to file1.txt 1:54
copied f.txt h.txt g.txt back to drive 1:55 f.txt overwritten
copied test2.jpg  1:56
added to file1.txt 1:57
reduced file1.txt 1:58
deleted f.txt g.txt 1:59
added to file1.txt 2:00
file1.txt closed
file1.txt renamed to changed.txt 2:02
test.jpg, test2.jpg deleted with shift 2:02
changed added to closed 2:05

3. Tool used to extract journal data
E:\>jp -file JournalExample.txt
license is authenticated: registered to Demo; TZWorks LLC [non-commercial use only]
jp ver: 0.99, Copyright (c) TZWorks LLC

date, time, filename, type change,
11/20/2012, 19:53:19.162, h.txt, file_deleted; file_closed
11/20/2012, 19:53:19.180, g.txt, file_deleted; file_closed
11/20/2012, 19:54:50.109, file1.txt, data_overwritten; file_added; file_closed
11/20/2012, 19:55:27.100, g.txt, data_overwritten; file_added; file_created; attrib_changed; file_closed
11/20/2012, 19:55:27.152, h.txt, data_overwritten; file_added; file_created; attrib_changed; file_closed
11/20/2012, 19:55:28.869, f.txt, data_overwritten; file_added; file_truncated; attrib_changed; file_closed
11/20/2012, 19:56:26.975, test2.jpg, data_overwritten; file_added; file_created; attrib_changed; file_closed
11/20/2012, 19:58:20.194, file1.txt, data_overwritten; file_added; file_closed
11/20/2012, 19:58:46.229, file1.txt, data_overwritten; file_truncated; file_closed
11/20/2012, 19:59:12.154, g.txt, file_deleted; file_closed
11/20/2012, 19:59:12.164, f.txt, file_deleted; file_closed
11/20/2012, 20:01:02.624, file1.txt, data_overwritten; file_added; file_closed
11/20/2012, 20:01:54.041, changed.txt, file_renamed; file_closed
11/20/2012, 20:02:24.337, test.jpg, file_deleted; file_closed
11/20/2012, 20:02:24.347, test2.jpg, file_deleted; file_closed
11/20/2012, 20:05:08.216, changed.txt, data_overwritten; file_added; file_closed

Conclusion
Update your tools and verify if they work as expected.  Understand how a service works and know how to enable it so you can test in "real" cases if the service was working properly.  Know what time zone information is saved and/or reported by your tools.  Know how to verify your findings in Hexviewers.  In my case, the changes were correctly identified after I have enabled the journaling on the drive. 

Wednesday, November 14, 2012

User action or Auto generated response

I'm sure many of us typed in Google searches and misspelled words.  Google results will suggest corrected spelling or allow you to do the search with the “unique” spelling.  Thus, I wanted to see if there is a difference in the request and see if the user requested word search can be linked to a user initiated, but completed based on auto generated Google suggestion.  Each auto generated request seems to request based on the index value of the generated requests, starting with 1 ( most likely ) to distinguish between multiple spelling options.  I also tried Bing to see the difference in the request format.
Google
Firefox
Correct spelling request
Misspelled request
Suggested options auto generated by Google
Showing results for digital forensics
Search instead for digital forensico
Clicking on the suggested correction created a spell=1 request
“en-US:official&spell=1&q=digital+forensics”.
Clicking on the suggested “bad” spelling, but auto generated suggestion created a nfpr=1 request
 “en-US:official&nfpr=1&q=digital+forensico”
IE
IE was behaving the same in its requests as firefox.
Showing results fordigital forensics
Search instead for digital forensico
Clicking on the suggested correction created a spell=1 request
Clicking on the suggested “bad” spelling, but auto generated suggestion created a nfpr=1 request
Bing
Bing requests were different from Google, but also consistent between browsers. 
IE
Correct spelling request
Misspelled request
Including results for digital forensics.
Do you want results only for digital forensico?
Clicking on the suggested correction created a FORM=AWRE request
Clicking on the suggested “bad” spelling, but auto generated suggestion created a FORM=RCRE request
Firefox
Including results for digital forensics.
Do you want results only for digital forensico?

Monday, October 15, 2012

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.