Tuesday, March 29, 2011

Basic Computer Forensic Analysis Techniques in EnCase

I was recently asked to provide a list of forensic analysis techniques. After looking through some of my documents, I realized I didn't really have an up-to-date worksheet that listed most of the common analysis techniques, even though we all have them memorized.

My goal is to create a flow chart to guide a new examiner to perform the commonly used techniques that we typically use in *every* case, and then also provide *case* specific techniques depending on the type of analysis or investigation. The following list is not meant to be all inclusive of every technique that we use, but instead it is designed to be a starting point and as a reminder of things to think about depending on the type of your case. Currently, I am focusing on the analysis of Windows based machines in EnCase. Please feel free to comment and add your own ideas in the comment section for others to benefit:

General Forensic techniques

  • Load Image into EnCase, verify Image
  • Check physical size of drive and compare to physical label
  • Identify & compare logical partition size(s) to physical drive size to identify any deleted partitions or unused disk space.
  • Recover folders
  •  Conduct hash analysis, indentify “known” and/or “notable” files. "Known" files can be excluded from remaining analysis techniques to reduce time and increase efficiency.
  •  Conduct file signature analysis, review renamed files.
  • Retrieve time zone settings for each disk and apply correct time zone, if applicable.

 Case specific techniques

  • Mount compound files
  • Conduct keyword search
  •  Recover client based email
  • Recover web based email
  • Recover Internet history (logical and unallocated)
  • Determine OS version, service pack, hotfixes & OS install date
  • Retrieve user account information (names, SIDs, logon dates)
  • Retrieve user specific registry artifacts (recent docs, userassist, etc.)
  • Retrieve attached USB history
  • Process LNK files to identify removable devices
  • Review installed applications
  • Review Office related files (doc, docx, xls, xlsx, ppt, mdf) & PDF files
  • Review multimedia & graphic image files
  • Identify encrypted files (entropy)
  • Data carve in unallocated (docs, multimedia, images, zips, base64)
  • Review Recycle Bin & recover deleted INFO2 records in unallocated
  • Review System Volume Information/old registry hives
  • Review Windows event logs
  • Mount image virtually and perform virus scan
  • Recover Windows logon password(s) (rainbow tables)
  • Recover username/passwords in protected storage areas

Windows Vista/7 specific

  • Review Volume Shadow Service

Thursday, March 24, 2011

Been procrastinating on upgrading EnCase?

So for those of you who have been putting off upgrading from EnCase v5 to V6, here is some incentive for you.

Take a look at this evidence file in V5, then use V6 or FTK Imager or other tool. Pay particular attention to Sector 280 and 676400.

For those of you using v6, don't think you live in a perfect world either, you may want to look at this too and see if it all looks "normal" to you.

I'm just saying...

Download Here

Sunday, March 13, 2011

EnScript to parse classic (.evt) event log entries in unallocated

This EnScript was inspired by a blog reader who emailed me to ask for a solution to parse some windows event log entries that were found in unallocated.

There are a couple ways I could think of to solve this issue. The easiest was to just build a parser to read a single event log record that was found in unallocated and display the data in the single record. The problem with that solution is it does not scale well and it will become very tedious when there are numerous records found in unallocated and requires a person to parse each one individually.

The final solution was an EnScript to perform a search for the magic value of "LfLe" which appears in every valid event log record. Once a hit is found, then the record is parsed and exported out into a separate .EVT file.  Every hit is exported out into the same .evt file and in the end, you will have a single "eventlog.evt" that contains all the valid windows event log entries that were found in unallocated. You can then use your favorite 3rd party event log viewer (Event log explorer, etc..) or the native Windows event viewer (eventvwr.exe) to read all the records that were found in unallocated. 

Each event log entry maintains a event record number. When searching in unallocated, it is possible that you could find two records with the same record number, therefore this EnScript renumbers all the records found in unallocated, but leaves the remaining data intact and as exactly as found in unallocated. Each record is assigned a new record number and then exported into the new .Evt file. A new header and footer is built based on the exported data so it can then be read with all the common event log viewing tools.

The exported records viewed in the EVENTVWR app in Windows 7:

The exported records viewed in the Event Log Explorer app in Windows 7:

None - This EnScript performs a search automatically. There is no need to search, select (blue check) or preprocess anything. The EnScript will search every unallocated object found, so if you have multiple drives loaded into the case, each one will be searched automatically. The EnScript automatically bookmarks all the "LfLe" search hits (valid and invalid). Some basic error checking is done to validate the record to attempt to ensure it is a complete and valid record before it is exported into the new .EVT file. The new "eventlog.evt" file is created in the default export folder for the active case.

This *only* searches and rebuilds classic Windows NT/2000/XP event (.evt) records. It does not yet support the newer .EVTX (xml) records that are used in Vista, 2008 & 7.

Download here

Answers to Forensic Puzzle #6

On February 24th, I posted a quick puzzle for people that were interested in working through a forensic puzzle. You can read the original post here.

Many comments and emails were sent asking about the puzzle, so I figured it was time to post the basic information that you were supposed to get. Going back to the scenario, a file was given to you for examination and you were asked to examine it and determine its purpose or any other information. You were also asked to provide the MD5 hash value of any final files you were able to examine.

Let start with the file:

Looking at the file and/or doing a file signature analysis using EnCase would reveal its a OLE compound file. The header is the same as a Microsoft Office document.  An OLE compound file has its own internal file system. The technical structure of this file can be found here. You can manually decode this file using the information provided on the MSDN library.

An easier solution is to use the built-in capabilities of EnCase. Since EnCase can parse OLE compound files, we can let EnCase do the tedious work for us.

Once we do this, the single file becomes two:

Now, looking at the contents of the single "suspicious file", you have two internal files named Details & File_0. Now, this next part is difficult to know without having looked at many files like this. This file is XOR encrypted. How do I know? I don't know. I's just something that after looking at many files like this, data patterns jump out and kind of reveal themselves. No, I am not Neo, but just like date fields and other structure become apparent after seeing them enough times, you can begin to recognize when data is XOR'd.

In this case, I theorized that the file named "file_0" was probably an EXEcutable. If you look at an Executable with a hex editor, you will see the MZ header followed by a bunch of zeros that make up the COFF header. So, looking at the image above, all the values with 6A, are actually 00. This makes un-xor'ing (technically xor'ing it again) the file easy since you can theorize that if this was originally an EXE, the value was 00, the resulting value is now 6A. Xor'ing the value of 00 with the XOR key of 6A, results in a value of 6A (imagine that). Therefore, we have just discovered our XOR key. 

If we XOR this file with the value of 6A, we end up with the following data:

We can clearly see this is a EXEcutable file and it has a standard COFF/PE header.  The MD5 of this file is 8dc601710e3e68b8d78b5cd73fb28616

A quick look at the contents of this file reveal a string resource that says:
"PopCap Games, Inc.,Zuma,,Zuma,Copyright © 2003 - 2004 PopCap Games, Inc.,Zuma.exe,Zuma Deluxe,,Presented by GameHouse".

If you save this file, there is a Icon associated with this EXE that is consistant with the game "ZUMA".  A strings of this file also reveals numerous text fragments that are consistant with a game.

If we look at the second file named "details":

We could try the same XOR key, which would work in this case. It would result in the file:

The MD5 hash value of this file is: f93a7bb8e02a8a23f87dad22b9ecd578

When I cannot determine the original type of file (like the first one above, I theorized it was an EXE by the patterns of data) or what XOR key that was used, then I use an EnScript I wrote to quickly XOR the data with all 256 possible values. It results in 256 files being written, each using a different XOR key, but then I can quickly look through those files and see any data I might recognize. 

Thanks to those who participated..... To date, *nobody* has posted any comments or answers to puzzle #1

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles