Home Archives for August 2013

13 - Detecting Forensic Artifacts on SSD Drive Challenge

Hello Reader,

It's that time again, Sunday Funday time! For those not familiar every Sunday I throw down the forensic gauntlet by asking a tough question. To the winner go the accolades of their peers and prizes hopefully worth the time they put into their answer. This week I am changing things up and letting the winner pick their choice of prizes!

The Prize:

A signed copy of the new book

The Rules:

You must post your answer before Midnight PST (GMT -7)
The most complete answer wins
You are allowed to edit your answer after posting
If two answers are too similar for one to win, the one with the earlier posting time wins
Be specific and be thoughtful
Anonymous entries are allowed, please email them to dcowen@g-cpartners.com
In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

The Challenge:

One of things that's important in any investigation is knowing whats normal, what should be there and whats missing. On a Windows 7 system with a SSD drive what forensic artifacts no longer get created or maintained by default?

Also Read: Daily Blog #69

Saturday Reading by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,

It's Saturday!

1. We had another Forensic Lunch on Friday, watch it here. We talked about legitimate uses for Tor, the CryptoParty movement, our new Plist parser and much more! Give it a watch and tune in live next week and get involved!

2. Over on Mari DeGrazia's 'Another Forensic Blog' there is a new tool for parsing Safari binary cookies, http://az4n6.blogspot.com/2013/08/safari-binary-cookies-now-with-more.html, Mari has written and put up for download a tool that will parse an entire directory of binary cookies at once as well as decoding the Google analytics values! Well done Mari!

3. On the Ride the Lighting blog there is an interesting write up on a news article that is making the rounds, http://ridethelightning.senseient.com/2013/08/insurance-company-refuses-to-pay-for-data-breach-will-yours.html. The midwestern grocery chain Schnucks had a data breach back in March and had to disclose the loss of 2.4 million credit card numbers. Like most companies dealing with the legal and operating expenses of dealing with a breach, remediation and notification Schnucks filed a claim on their insurance for it. The insurance company is has denied their claim and the resulting lawsuit (I'm guessing one is coming) will make for interesting case law on what an insurance company has to cover for breached companies.

4. I enjoy the cyb3rcrim3 blog as its one of the few legal blogs out there that focuses on the evolving case law of digital evidence. This week an interesting post went up http://cyb3rcrim3.blogspot.com/2013/08/staples-laptop-and-4th-amendment.html describing an individual who was prosecuted for posession for child porn after bringing in the computer to Staples to have a virus removed and the technician found the child porn and reported it. If you are in a corporate environment and want to understand more about your obligations and the law regarding what to do when child porn is located on a system in your possession, read on.

5. On the Mandiant M-unition blog there is a good first post in a series on determining proof of program execution https://www.mandiant.com/blog/execute/. I watched Mary and her co-worker at Mandiant give a great presentation at the DFIR summit on the Application Compatibility Cache aka shimcache and learned some interesting caveats to shimcache evidence on a per OS version.

6. Chad Tilbury has posted an hour long video with SANS on an introduction to Windows Memory Analysis. While its not something you can read it is worth you time to watch if you are unfamiliar with it! https://www.youtube.com/watch?feature=player_embedded&v=SjDH_vTuefM

7. Lastly two new SANS courses are coming out that I plan to finagle my way into sitting though. The first is FOR 572 which is the new advanced network forensics class. The concept behind FOR 572 is really neat, they took all the network captures from the attacks you discover in FOR 508 and built a class showing how to do the same level of response on the network level. Very cool stuff.

The second class FOR 585 is all about mobile forensics. In the course of my investigations I do mobile phones on a regular basis and I am always looking for new ways to get more data. Heather Mahalik and Cindy Murphy have worked hard to build quite a course and I'm waiting to see what new tricks they have up their sleeves.

That's all for today! Tomorrow is Sunday Funday, I hope your ready for a challenge!

Also Read: Daily Blog #68

Discussion with Kyle Maxwell and James Lohman

Hello Reader,
It's time for another Forensic Lunch! Join us as we talk IR tools with Kyle Maxwell, More extended MAPI fun with James Lohman and updates on our OSX plist parser and the triforce.

Also Read: 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

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

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

Hello Reader,

Another Sunday Funday has come and gone and this week I decided to change things up again. I gave out two questions and allowed people to either answer one or both of them. I thought this would be a fun way to allow for varying levels of difficulty within the same challenge. I had several good responses and picking a winner was tough.

The Challenge:

Two questions this week! Answer one or both for those over achievers:

Question 1:

Your client has a home computer running Windows 7 and uses Internet Explorer for his web access. He has switched jobs and is working on a competing product. An opposing expert has issued a report stating that your client must have accessed a website containing the new competing product earlier than the internet history shows because he found the same fragment of a page found in the unallocated space of a shadow copy he imaged. He is alleging that this earlier access shows he was working for the competitor before he quit his job.

Why is he wrong?

The Wining Answer:

Sajeev Nair

Unallocated is not monitored by VSS, so what they were seeing was the general unallocated and not associated with VSS. Only volumes are tracked.

This can be confirmed by

checking the registry value HKLM\SOFTWARE\Microsoft\WINDOWS NT\CURRENTVERSION\SPP\Clients\ {09F7EDC5-294E-4180-AF6A-FB0E6A0E9513}, this value determines which volume is currently monitored by VSS.

Additionally, the below registry key determines, which files are not copied by VSS.

HKLM\System\CurrentControlSet\Control\Backup Restore\FilesNotToSnapshot

What I liked about this answer is that they included the registry keys to see what is and is not being included within VSS snapshots. The second place answer actually talked about overlays which was great, but looked at it from a live system perspective rather than the issue at hand. There is more to this and Joachim Metz's papers are great place to start if you want to understand the possible misinterpretations you'll likely have to face in the future.

Question 2:

Your suspect has a new work computer running Windows 7 and uses Google Chrome to access the internet. He has switched companies and used to work for your client. You have found Google Chrome history that predates his employment at the new company that reflects accesses to your clients system.

Why is the activity there?

The Winning Answer:

Paul Bobby

You can 'log in' to Google Chrome, so to speak. Browsing history from other devices, such as home computers or previous work computers, that also use Chrome (and log in to synch changes) are now visible on this new work computer.
If you synch Chrome by 'signing in', open a new tab. In the lower right you will see an "other devices" pull down.

What I liked about this answer is mentioned not just about the Chrome sync service but also how to identify where the other devices are. Knowing how to distinguish what system is creating the history Chrome shows is important when assigning activity to a system!

Thanks everyone for playing! Winners please send me a message for what prize you are picking. Tomorrow its back to either the business of forensics or finishing the understanding the artifacts series.

1. Pre-Requirements for a successful lab

Before you start a lab you should make sure you that you actually are ready to do so. I've seen many a person go out and spend time and money putting out their sign without realizing what it takes to attract the business they need to succeed.

You will need at a minimum

a. At least one person who has already successfully testified as an expert witness in digital forensics

This is probably where I've seen the most problems for people trying to start new labs. You really, really need someone (preferably you to keep costs down) who has testified before to get civil expert witness work.

If you have been doing forensics work internally for a company for 15 years thats great, but lawyers only want to put experts on the stand who have testified before. If this person is not you, or can't be you, that's OK. You need to find a partner who has testified to fulfill this requirement while you spend your time getting business, managing the lab and working with clients.

This is where law enforcement has an advantage, most LE investigators will testify long before their civil counterparts will in terms of years of experience. As such its more common to see part time or retired law enforcement set up shop to offer services to the civil side.

If you only plan to take on IR work I still would encourage you to find a testifying expert to work with as it will make the lawfirms who your IR client retains more comfortable with your work product. In the end there may never be a lawsuit against the attacker you detected, but the people whose data was breached may sue and the IR team may have to testify.

b. The ability to qualify for whatever licensing is required in your state/country

You may have a disagreement with licensing for digital forensics but for those of who you live in a country/state with such restrictions its something you have to do. Take the time to research the requirements for your country/state and find out whats needed. For instance in Texas you have to become a licensed PI company, but the PI managers qualifications don't provide any provisions for experience as an examiner for qualification. Instead they want someone who has either

i. Been a PI manager for another company for 3 years
ii. Has a degree in criminal justice
iii. Has taken a course to earn a certificate of competency as a PI manager

Point iii didn't exist until a couple years after the law was changed so many existing labs had to pay existing PI managers to 'manage' their company until they had the requisite number of years managing a licensed PI company so they could take the managers test. The managers test BTW contains 0 questions about forensics.

c. Enough cash reserves to last three months without payment

When you first start our and you are working your first cases you'll be quite excited when you submit your first invoices. You'll be very sad when they don't get paid within 30 days. When you are a new vendor to a large company you will first have to be placed into the accounting system for payment and then your invoice will sit the requisite waiting period they established before they will mail out a check.

When all your clients are new you should expect that it will take two months to get paid for your first months work (if you are lucky enough to get work your first month). With that in mind make sure you have enough cash in the bank for the following:

i. Your expenses
ii. Business insurance
iii. Office expenses, unless you are going to work from home (which is just fine)
iv. Taxes
v. Expenses for travel and hard drives

If at the start of the 3rd month you have no business or your bills are still being questioned and you don't have enough cash saved to go beyond 3 months its time to go look for another job!

d. Enough prior exposure to local lawfirms and companies for word of mouth to build

This is important and only really understood by those who get the work already. When a lawyer looks to hire an expert witness they don't just go to google and search for 'expert witness'. They call other lawyers in the their lawfirm and their lawyer friends and ask who they used and are happy with.

Word of mouth is what civil forensic labs live and die off of. No matter how much money you spend on marketing, ad words, websites, cards, logos, flyers, brochures, super special deals on your services it won't matter if someone else has not already used you and liked you.

There is a considerable amount of risk involved for a lawyer picking the expert witness. If you can't produce a good report and provide good testimony then their case will suffer. Worse if your findings are proven to be incorrect or you are disqualified as an expert they will look to their clients as if they didn't do their job right. Possibly leading to lawsuits against the lawyer and you for negligence.

So understand and respect this requirement, you can't change it. I don't know how IR work is gained but I will tell you that civil expert witness work comes from the outside lawfirm no matter how many good friends you have working within a company who recommend you to in house legal.

e. Licensed copies of your preferred tools

Please, please, please don't ever used pirated software in your work as a testifying expert. If you are going for a full open source shop thats great, but never used pirated software. If it comes out in testimony that you don't have a license for the software you used to generate the results it will not reflect well on your testimony.

I think that's enough for this post, I'll be writing more about this topic as the blog moves forward to give me a variety of topics to discuss. I hope my past experience is helpful to you and will lead you to future success. We need more independpent labs out there, every case needs at least two experts!

Also Read: 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

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.

Daily Blog #70: Sunday Funday 9/1/13 - Detecting Forensic Artifacts on SSD Drive Challenge

Daily Blog #69: Saturday Reading 8/31/13

Daily Blog #68: Forensic Lunch 8/30/13 - Discussion with Kyle Maxwell and James Lohman

Daily Blog #67 - Understanding the artifacts DeviceClasses

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

Daily Blog #65: Understanding the artifacts EMDMgmt

Daily Blog #64: Sunday Funday 8/25/13 Winner(s)!

Daily Blog #63: Sunday Funday 8/25/13 - Two Challenges

Daily Blog #62: Saturday Reading 8/24/13

Daily Blog #61: Forensic Lunch 8/23/13 - Discussion with Matthew Seyer, Kyle, and David Cowen

Daily Blog #60: On the business of being in business in the expert business, business

1. Pre-Requirements for a successful lab

You will need at a minimum

a. At least one person who has already successfully testified as an expert witness in digital forensics

b. The ability to qualify for whatever licensing is required in your state/country

c. Enough cash reserves to last three months without payment

d. Enough prior exposure to local lawfirms and companies for word of mouth to build

e. Licensed copies of your preferred tools

Daily Blog #59: Understanding the artifacts ShellBags

Daily Blog #58: Understanding the artifacts Jump Lists

Daily Blog #57: Sunday Funday 8/18/13 Winner!

Daily Blog #56: Sunday Funday 8/18/13 - Gnome and CVS Challenge

Daily Blog #55: Saturday Reading 8/16/13

Top Posts/Right Now