Daily Blog #72: Understanding the artifacts Prefetch

Hello Reader,
            I hope you got some time off for the labor day weekend, I know I enjoyed my weekend. We have another forensic lunch coming up this Friday 9/6/13 at noon, make sure to let know you are coming to get the link as soon as it goes live here: https://plus.google.com/u/0/events/cjng3fsgmksiiubfs9h7f8dqb64?authkey=CLC4nKvk24GEZg. Today we continue the understanding series to talk about Prefetch files, I think I'm almost done.

To learn more about the data structures and the like of Prefetch files start here:
http://www.forensicswiki.org/wiki/Prefetch

You can download a good prefetch parser from Tzworks here: https://www.tzworks.net/prototype_page.php?proto_id=1

I would like to think that all of us know what Prefetch files are, do and have our preferred tools for examining them. What you need to understand about Prefetch files is summarized below:

• Determine first execution time of an executable referenced by this prefetch file
• Determine last execution time of an executable referenced by this prefetch file
• Determine the number of executions of an executable referenced by this prefetch file
• What files and directories were loaded within the first few seconds of execution by this prefetch file

In terms of usage, which is our focus is in this series, we care most about what files and directories were loaded. Prefetch files get deleted after the maximum number of them exist (128 in xp/vista/7, 1024 in 8) with the oldest and not updated being deleted first and they get updated on each execution. There is one other caveat thats important to understand and highlighted in bold in the list above, prefetch files are not consolidated for an application like registry settings are. Here are a couple of examples

• If a program is executed and not executed again until after 128 other program executions the old prefetch file will have been deleted and a new prefetch file will be created after. 
• A prefetch is made for every program with a postfix on the filename that is a hash of the full path. 
• To determine what program is related to which prefetch hash you have to generate the hash of the full path to where you know the prefetch file to exist with a tool like Woanware's prefetch forensics
• http://www.woanware.co.uk/forensics/prefetchforensics.html
• If the prefetch files were deleted by a cleaning utility they would be regenerated on the next execution of the same program

We care mostly about identifying documents we care about being loaded on application start and the last time that the program executed. For instance lets say a copy or backup utility was running that provided us with no log or database of files being backed up. In those instances the paths fed into the program to copy may be located within the prefetch file. 

This is really helpful if the program in question is running from an external drive as its unique hash due to he external drive access will not be overwritten by any local versions of the same program.  If we have a program that has been executed multiple times and may be referencing files we care about then you should look into the shadow copies as they are also stored within them! 

Lastly Eric Zimmerman has reported that Windows 8 now has prefetch files on by default for all systems (ssd or not) and keeps up 1024 prefetch files. So with Windows 8 slowly being adopted you may have more prefetch files to analyze in your future then you had before!

Also Read: Daily Blog #71

Read More

Daily Blog #67 - Understanding the artifacts DeviceClasses

Hello Reader,
         Tomorrow is the Forensic Lunch, are you going to join us? Click here to RSVP and be notified when the YouTube link is live! Want to be on the video chat? Email me dcowen@g-cpartners.com and I'll get you in the video chat room.

Today we are going to talk about the DeviceClasses registry key. Introduced in Windows Vista the DeviceClasses subkeys are created when a plug and play device driver is successfully loaded. This is great for us because unlike USBStor/SBP2Stor and IDE it is not confined to any one type of connection and makes it harder to miss connected devices. If you want to read about PnP subsystem and how it updates the registry go here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff558808%28v=vs.85%29.aspx

I most regularly use DeviceClasses on Windows 7 system to determine last plug in times for external storage media. Understanding what it does, why it creates these keys, why there are so many keys and what you should expect to find in them will help you when everything else fails.

The DeviceClasses key found in the System registry under

SYSTEM\\Control\DeviceClasses\

 contain a number of subkeys, each subkey relates to the type of device that is being recognized. For instance the physical disk of an external drive would be in the GUID key: {53F56307-B6BF-11D0-94F2-00A0C91EFB8B}
reference: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545824%28v=vs.85%29.aspx

While the volume that is mounted would be stored under GUID: {53F5630D-B6BF-11D0-94F2-00A0C91EFB8B}
reference: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545990%28v=vs.85%29.aspx

The full list of storage device types and GUIDs can be found here:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff541389%28v=vs.85%29.aspx


The full list of all GUIDs by category of device can be found here:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553412%28v=vs.85%29.aspx

Whats important to understand here is that all PnP devices are recorded under these subkeys. If you have a case where you think a non standard device may have been utilized (a voice recorder, a media player without direct physical disk access, web cam, etc...) and a driver installed at one point you should look up the GUID that corresponds to the type of device to review the subkeys and determine what was plugged in.

For example, if you have a USB Storage Device plugged it will add keys to the two GUIDS listed earlier and contain information relevant to the disk/volume. The following examples call from the GUID key:
SYSTEM\\Control\DeviceClasses\{53F56307-B6BF-11D0-94F2-00A0C91EFB8B} 

As an example here is what a Tableau connected via Firewire looks like:

##?#SBP2#Tableau&Forensic_SATA_Bridge&LUN0&REV15#000ecc01000f4063#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Here is what an eSATA attached SSD looks like:

##?#IDE#DiskPatriot_Torqx_2_32GB_SSD________________S5FAM014#4&35e86db3&0&0.2.0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Here is what a F-Response iSCSI disk looks like:

##?#SCSI#Disk&Ven_FRES&Prod_FRES#1&1c121344&0&000000#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

This is what an external non generic USB Disk looks like:

\##?#USBSTOR#Disk&Ven_FUJITSU&Prod_MHT2060AH&Rev_#43527242060A&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

This is what an external generic USB Disk looks like:

##?#USBSTOR#Disk&Ven_&Prod_&Rev_PMAP#07032AE8AFBE2481&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

This is what a USB attached android phone looks like:

##?#USBSTOR#Disk&Ven_Android&Prod___UMS_Composite&Rev___00#8&d3cc3f0&0&304D1905736FB98E&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

When looking at the Volume GUIDs you'll see the full key:
SYSTEM\\Control\DeviceClasses\{53F5630D-B6BF-11D0-94F2-00A0C91EFB8B}

A MagicISO mounted image looks like:

##?#SCSI#CdRom&Ven_MagicISO&Prod_Virtual_DVD-ROM&Rev_1.0A#1&2afd7d61&0&0000#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

The volume of the generic USB storage device we referenced above looks like:

##?#STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_&PROD_&REV_PMAP#07032AE8AFBE2481&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

If you haven't taken a look at your own DeviceClasses key go take a look, there may be more facts you can determine from your own usage of your forensic workstation than you thought.

Many times in our analysis we focus on whats common, USB storage is the most common type of external storage for instance. There is no guarantee though that your custodian will oblige your convenience, so if you are dealing with something nonstandard this a great place to determine the last plug in time of your device.

I'll go into key analysis and linkage in the Usage post, so be sure to watch the Forensic Lunch live tomorrow and ask questions!

Also Read: Daily Blog #66: Understanding the artifacts setupapi.log/setupapi.dev.log

Read More

Daily Blog #66: Understanding the artifacts setupapi.log/setupapi.dev.log

Hello Reader,
            Friday is quickly coming up, have you made plans to spend your lunch hour with us? You can eat while we talk and then type your questions so you can be polite and not talk with your mouth full. You can RSVP for the lunch here, https://plus.google.com/u/0/events/ccu3b7246h9sk16jpg79l2co9mo?authkey=CJ3X6u7G6PjlSw, and email me dcowen@g-cpartners.com if you want to be on it!

            Today is a relatively simple post but I think I need to make sure to address it separately to be complete. Today we are going to talk about the setupapi.log (xp/2000/2003) aka the setupapi.dev.log (vista/7/8).

Windows XP/2000/2003
Starting with Windows 2000 and then continuing with Windows XP and 2003 the underlying installer system (setup) began logging for debug and troubleshooting purposes all of the drivers it loaded for devices. The log was called setupapi.log and located under %systemdrive%\Windows The underlying system and configuration for this logging is detailed on the following MSDN page:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff550882(v=vs.85).aspx

By default the logging level will be:

0x00000020                       Log errors and warnings.

So you will capture in this logfile all drivers and devices loaded onto the system with timestamps and which drivers were loaded. This is important to determine:

• When external devices were plugged in for the first time
• When a malicious driver was loaded onto a system
• What drivers were loaded for an unknown device to determine its functionality
• Proving a device was successfully installed and accessible

If you want to be exact in your interpretation of each logged line refer here:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff547657(v=vs.85).aspx

Windows Vista/7/8

The setup service log was split into two logs in Vista moving forward. There are now two logs both now in %systemdrive%\windows\inf:

setupAPI.dev.log - Device and driver installations 

setupapi.app.log - Application installations

The MSDN specification for these two logs can be found here:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff550887(v=vs.85).aspx

The device log is similar to the prior version but the application log is new and is of interest. In order to interpret the setupapi.app.log you need to refer to the following device install codes:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff549793(v=vs.85).aspx

I want to do some more research into this log as I've finding some interesting entries relating to my use of a network scanner. I'll make a new blog just about this file after we've done some testing.

The same type of data we talked about in the XP and after logs can be found within these logs as well. If you have not been including this data in your analysis make sure to do so! There are several factors about the setupapi logs that are important in your examination:

• They are created by default and cannot be turned off without a registry change 
• They do not delete themselves so you should have all devices every plugged in
• In an OS upgrade they would remain and indicate when the new OS was installed
• Many system cleaners focus on registry keys and miss the data located here
• It's the only exact source of first plug in times
• If the OS is reinstalled the log format is carvable

Tomorrow I'll see if there are any other artifacts I need to include before we talk about stitching it all together.

Also Read: Daily Blog #65: Understanding the artifacts EMDMgmt

Read More

Daily Blog #65: Understanding the artifacts EMDMgmt

Howdy Reader,
            Another good Sunday Funday come and gone. I want to make these contests fun and accessible for you and for those vendors who have graciously provided prizes worth your time and effort! Have an idea of how to make Sunday Funday better? Comment here or email me dcowen@g-cpartners.com. Also remember that this Friday we will be doing another Forensic Lunch and we will be showing the first alpha of our Plist parsing tool. You can register for the Forensic Lunch here to be notified when it begins and any changes and ask questions! If you want to be on the video chat for Forensic Lunch and have something to talk about email me dcowen@g-cpartners.com!

Today we are going back to the understanding series before I get more side tracked and wanting to write another topic. We've covered 6 artifacts so far in stitching together what it takes to really show usage but we are not done yet! Now we need to talk about a registry key first introduced in Windows Vista called EMDMgmt. Harlan has talked about it here: http://windowsir.blogspot.com/2013/04/plugin-emdmgmt.html and earlier in his blog as well. EMDMgmt or External Memory Device Management is part of the 'Readyboost' service first provided in Vista. Whether Readyboost is enabled or not the EMDMgmt key will be populated with all available external storage devices where it could write Readyboost data. In order to make sure it can uniquely identify a volume it includes both the driver identification and volume serial number of the attached device.

This is important for us in our investigations because it is the only key outside of Mountpoints to be able to link which external device found in the system registry corresponds to which volume serial number/volume name stored in the LNK files/Jump lists. To quote the Microsoft technet article found here:

ReadyBoost consists of a service implemented in %SystemRoot%\System32\Emdmgmt.dll that runs in a Service Host process, and a volume filter driver, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd is short for External Memory Device, the working name for ReadyBoost during its development.) When you insert a flash device like a USB key into a system, the ReadyBoost service looks at the device to determine its performance characteristics and stores the results of its test in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, seen in Figure 1.

Now many times you will see USB mentioned here but its not just USB devices you will find in this key. I find eSATA, USB, Firewire, local disks, anything non system drive storage that is plugged in will be stored here with the driver identification, volume label and volume serial number. This can be very helpful when you are trying to understand why a device you know was accessed does not appear in the USBStor. There are times when either a) a device isn't USB b) the driver loads a hybrid driver (cdrom/storage) and the drive will be appear as a local disk instead.

The one problem for analysts is that Readyboost is disabled by default on SSD drives on at least Windows 7 (part of the Windows 7 optimization for SSDs). This can lead to a lot of false positives of anti-forensics or spoliation from an inexperienced examiner. So you are back to timeline analysis to determine which drives were plugged in at what time if you have a SSD user.

Now if the system is Vista or 7 (Have not checked 8) and your suspect does not have a SATA drive this key is created by default. If it does not exist check to see if the readyboost service was disabled (some users complain about its performance) but that disable would have to have occurred before the first external storage device was plugged in. Otherwise you have a good indication of anti-forensics if this is missing.

EMDMgmt is something I've learned to rely on and tools like Woanware's USBDeviceForensics and TZworks USBStor Storage Parser relies on to uniquely match drives. If you haven't looked at it before I would encourage you to do so, it will make your life much easier!

Tomorrow we continue to wrap up the current understanding series!

Also Read: Daily Blog #66: Understanding the artifacts setupapi.log/setupapi.dev.log

Read More

Daily Blog #59: Understanding the artifacts ShellBags

Hello Reader,
           Another day, another blog. They say if you've done something for two weeks it becomes a habit. Well it's been two months and I will tell you that I know each evening that I should be writing tomorrows blog, but life (and good tv shows/movies) often gets in the way. 

So I just got back from lunch and its time to push through the remaining usage artifacts so we can talk about the combined analysis of them. I think after I'm done with all of these posts I will feel some feeling of relief but also another separate list of which artifacts I need to go into more technical detail on in the future. Blog posts sometimes just write other blog posts, but mainly your comments are what help drive the direction of my writing. Also please note that if you have not added me to your Google+ circles and made your comment limited, I can't see it.

Let's talk about Shell Bags! Shell bags is one of my favorite Windows artifacts as it reveals so much as to what the custodian was interested in data wise. For a technical primer on shell bags, go here:
http://computer-forensics.sans.org/blog/2011/07/05/shellbags
and
http://windowsir.blogspot.com/2012/08/shellbag-analysis.html

As has been stated shellbags record a users preference for each folder viewed within the gui explorer. That is important as the only ways to get around a shellbag in viewing folders that I know of is to:

• Load a command prompt
• Utilize a third party file system navigation tool
• Browse for files inside of an application that does not use the win32 browser call

Otherwise, if a folder is accessed and viewed within the GUI a shellbag entry is going to be made to record their preferences. As a by product of storing those preferences (item list type, window size, sorting) it also stores the MAC times of the directory, the full path, the last time of update to the registry key and in Windows 7 the MFT record number. 

For the most in depth treatise on the shell item format and how its changed between Windows versions read this: https://googledrive.com/host/0B3fBvzttpiiSajVqblZQT3FYZzg/Windows%20Shell%20Item%20format.pdf

This is important. Why you ask? While full paths are great for static drive letters, without volume serial numbers (as we find in LNK files) we have no way to uniquely match them to removable devices without doing some deep timeline analysis showing what was attached at what times. With the addition of the MFT record number (consisting of the entry number and sequence number) which will allows us to identify uniquely the directories and files being recorded in the shellbags to the directory/file located on external media.

Now I just assumed something of you reader, I assumed you understand the power of shellbags in getting more information about what was contained on removable devices. The shellbag entries are stored on a per user basis and are not limited in scope to just the local disks. Whatever removable or network based storage the user views through the GUI explorer gets recorded. As far as I know, and please leave a comment and correct me if i'm wrong, the shellbags are the only artifact that will reveal the existence of directories accessed without the need of a file being accessed within them. LNK files do get created pointing to directories at times, but not the breadth and depth that the shellbag entries show you. 

So, shellbags are awesome. You should be checking them. 

This is my favorite tool to check them with:

https://www.tzworks.net/prototype_page.php?proto_id=14

Don't exclude them in your analysis just because its not a built in feature of your tool.

Tomorrow we move onward towards more artifacts and greater understanding!

Also Read: Daily Blog #58: Understanding the artifacts Jump Lists

Read More

Daily Blog #58: Understanding the artifacts Jump Lists

Hello Reader,
         Another Sunday Funday is behind us and from it I've identified another blog series that need to be written. We are trucking along through the artifacts needed to better understand usage. We've covered LNK files, the USN Journal, USB Stor and User Assist. Today we are going to jump into Jump Lists which first made their appearance in Windows 7.

If you've never heard of Jump Lists before go here, http://www.forensicswiki.org/wiki/Jump_Lists, this blog post assumes you are familiar with them and seeks to help you better understand them. For instance I won't be explaining the difference between automatic/custom jump lists or where to find them and their structures.

If you want to read the most thorough write up of Jump Lists I've seen to date go here: http://articles.forensicfocus.com/2012/10/30/forensic-analysis-of-windows-7-jump-lists/.

An easy way to think about jump lists, though not technically accurate, is a chained series of LNK files stored on a per application basis. The biggest fundamental issue regarding Jump Lists versus the LNK files that analysts know and love is that LNK files where created, stored and maintained for the explorer shell (with the one exception I know of being Microsoft Office). 

Through program shourtcuts, recent documents, office application documents, etc... there is a shared set of LNK files maintained. Jump lists does not entirely replace this functionality but rather extends it allowing tracking of recently used documents from the registry to individual jump lists on a per application basis through automatic destination files.

In short, if you are analyzing a Windows 7 system and you are not parsing/analyzing the jump lists then you are missing evidence. Many up to date forensic suites are not parsing jump list data structures yet and instead will carve LNK files from custom destination lists. Get a tool that handles them correctly:

TZWorks: http://tzworks.net/prototype_page.php?proto_id=20
Woanware: http://www.woanware.co.uk/?p=265

This is good news for us as that means what documents are being accessed through an application are no longer just maintained in the registry through MRU's and we get much more data to analyze on a per file basis. 

Some applications, notably Microsoft Office, emulated this functionality through LNK files in prior versions of Windows but Jump Lists extends this through auto destinations. MRU keys only keep the date of the last file accessed for that MRU key and the order of last access, while automatic Jump Lists records the same type of data a LNK files does but extends it.

One of the difficulties investigators have had with jump lists was matching the appid that makes up the jump lists name back to which application it was tracking. Luckily for us Hexacorn seems to have solved this issue and made a perl script for use (Yay Perl!):
http://www.hexacorn.com/blog/2013/04/30/jumplists-file-names-and-appid-calculator/ which will allow you to generate the app-id for any given string.

So in short, and I probably will want to revisit this blog post, Jump Lists extend the analysis you did prior with LNK files and is stored on a per user basis for recent document access like LNK files, but is stored on a per application basis. 

One of things mentioned between all of the major sources is that jump lists are not deleted when a program is uninstalled and they would not be deleted by any system cleaner that is not 'Windows 7 aware'. So if you are not currently taking them into account in your investigations you should change that today.

Also Read: Daily Blog #57

Read More

Daily Blog #52: Understanding the artifacts LNK Files

Hello Reader,
               Time to continue the series of understanding the artifacts building up to a deeper understanding of proving usage. Today we are going to go into a well known artifact LNK files and them move through Jump lists, MRU keys and the other artifacts we use to establish use and explain how to stitch them together. Along the way we will detail the nuances that can change your opinion or possibly lead to misinterpretation.

LNK files are one the simplest artifacts and many, many, many people have written about them. Here are some of my favorite LNK write ups if you are reading this and are not familiar with them:

http://www.forensicswiki.org/wiki/LNK
http://www.forensicfocus.com/link-file-evidentiary-value
http://windowsir.blogspot.com/2013/06/there-are-four-lights-lnk-parsing-tools.html

The funny thing about artifacts as simple as LNK files is that they reveal as much information to the examiner as they care to know. When I do interviews for a position at G-C I ask a series of questions relating to artifacts and what they mean to the examiner. This isn't a trick question, which I explain to the interviewee, but rather a gauge to determine how far down the rabbit hole the examiner has gone. As an example for LNK files I would ask the following to an interviewee:

'What can you determine from a LNK file'

I can determine the rough expertise of an examiner by how many of the following points they answer with. I then take this in combination with other artifact questions/scenarios and the level of depth they answer to determine their level of forensic experience rather than focus on their resume.

Beginner Answer:

A LNK file reveals what files and/or programs a user accessed.

Intermediate Answer:

A LNK files reveals what files and/or programs a user accessed and the network path and MAC address of the where the access took place.

Experienced Answer:

A LNK file reveals what files and/or programs a user accessed and the network path and MAC address of where the access took place. In addition it contains the timestamps captured from the file and/or program being accessed that represents the file at the time the access took place.

Senior Answer:

A LNK file reveals what files and/or programs a user accessed and the full path\network path and MAC address of where the access took place. In addition it contains the timestamps captured from the file and/or program being accessed that represents the file at the time the access took place. It also contains the volume serial number of the device which you can use to match the LNK back to the volume the file came from if not a network data source. In addition LNK files contain shell items allowing the examiner to determine the type of folder being accessed (volume/network/file/uri).

Expert Answer:

A LNK file contains two sets of timestamps relevant to the examiner. The first set of MAC times belong to the LNK file itself, it reveals by creation date when the file was first accessed as recorded by this LNK file. The modification time records the last time the LNK file was updated and should reflect the last successful access. The second set of dates is maintained within the LNK file and represents the MAC times of the file being accessed based on the last successful access to the file from the LNK file. In order to determine prior states of the file you can examine the restore points (XP), shadow copies (win 7) and carved LNK files to find all the other versions of this LNK file that also reference this file and volume serial number/shell item uniquely. Each updated set of internal MAC times represents another successful access of the file through the LNK File and should be counted towards usage.

Now if you noticed I didn't say the Expert Answer had to go into depth on the technical structure as to what all can be contained within a LNK file, that isn't as important to me as the ability to properly interpret what the data means in the context of analysis. I assume that anyone who can give me an expert answer already has the technical knowledge of the file format to give additional facts when needed, but I find that people who give just technical information are missing the larger picture of what they data means in their analysis and what they can prove with it.

So with that said, tomorrow we will continue on with usage artifacts. Do you think I missed something or do you have an even better answer? Leave it in the comments, I'm always interested in additional views on analyzing familiar artifacts! 

Also Read: Daily Blog #51 - Understanding the artifacts USNJrnl

Read More