Monday, 12 November 2012

SANS Forensic Artifact 4: Index.dat / Places.sqlite

You may be wondering why at this point we've moved on from artifact 1 to artifact 4. I spent some time thinking about what I wanted to discuss PST/OST files and Skype logs and felt I needed some more time to make this more beneficial to everyone. This doesn't mean I won't be completing it just that I'll be coming back to it after we explore some of the other artifacts first. The category for today is in the  File Download category: Index.dat / Places.sqlite.

This should be a fairly easy category to post about as I've already posted some information and tools on how to parse this information.

SANS lists the following information within the poster.

Not directly related to “File Download”. Details stored for each local user account. Records number of times visited (frequency).
Location: Internet Explorer
XP %userprofile%\Local Settings\History\ History.IE5
Win7 %userprofile%\AppData\Local\Microsoft\Windows\History\History.IE5
Win7 %userprofile%\AppData\Local\Microsoft\Windows\History\Low\History.IE5
Location: Firefox
XP %userprofile%\Application Data\Mozilla\ Firefox\Profiles\<random text>.default\places.sqlite
Win7 %userprofile%\AppData\Roaming\Mozilla\ Firefox\Profiles\<random text>.default\places.sqlite

For today we can easily test the tools we have by browsing to certain sites and making a note in regards to the time we viewed the site. When we run our tools we should be able to see the same time referenced by our tool. Other areas we can look at are what happens when we delete the history and whether entries remain or they're removed. Finally I wanted to touch on some of the different entries you'll find within the index.dat file which are URL / LEAK / REDR entries. I'll touch briefly on LEAK entries and link to a practical example of how we create one of these entries. This should help us associate our own experiences in future incidents where we may be responding to incidents that contain these artifacts.

Firstly lets start by browsing three websites in both Internet Explorer and Firefox and i'll show how to parse the data using Harlan Carvey's open source perl scripts and some of my own. We'll then convert these into TLN format and confirm our times with those we noted at the time we visited each site.

Here are the times I noted for each site I visited with both IE and Firefox. I know this is an unrealistic example because nobody ever users bing or yahoo right? poor attempt at humour, stay with me it can only get better.

Firefox - 10:12am - 10.12am - 10.13am

Internet Explorer - 10.13am - 10.14am - 10.15am

I started by parsing my index.dat file with the following command, which uses Harlan's urlcache script, and producing my initial events.txt file -f "C:/Documents and Settings/username/Local Settings/History/History.IE5/index.dat" -l >> events.txt  

Following that I used my own script and ran the following command -p "C:/Documents and Settings/username/Application Data/Mozilla/Firefox/Profiles/fd9zh9ag.default" -d >> events.txt  

Finally I ran Harlan's parse script to create my timeline file. -f events.txt -c > timeline.csv  

Lets compare our timeline results with the times we listed above. Important to note is that Harlan's timeline tools produce output in UTC time. So depending which timezone you are in you may need to add a column and adjust the time to your local. I typically use a cell value such as the following =A1+TIME(#,0,0) where '#' should be replaced with the hours you wish to add.

So firstly I wanted to add that I've already had some value out of checking my own tool as you can see from the screenshot above the firefox history is in the wrong cell in comparison to Harlan's script. This is pretty easy to fix and I'll resolve that as soon as I can for everyone. It shouldn't affect your timelines in any way however.

If we compare our results from the above

Firefox - 10:12am - tln: 10:12am - 10.12am - tln: 10.12am - 10.13am - tln:

Internet Explorer - 10.13am - tln: 10.13am - 10.14am - tln: 10.14am - 10.15am - - tln: 10:15am

So the above is pretty clear that our tools are producing the output we are expecting. Again this is all fairly basic at this point but it shows now we have an understanding of what the output of our tools look like and we're confident that they're producing the correct times for us to evaluate. This can be critical in terms of your incident response as you do not want to miss an artifact because you thought your tool was providing the correct time when it was in fact off by a number of minutes or hours.

So what happens when we delete the history I presume we lose this information and our timeline should be empty. Lets test the theory by clearing all of the IE history and four hours firefox history.

I ran the same commands as I did above and as expected the last data I had was from the previous time I used the workstation and had nothing from the current day for firefox. There was also no information for Internet explorer at all. So this is worthwhile keeping in mind while you're investigating in that if the user has deleted their history you may need to go to other areas to identify sites visited. The guys at Volatility have written an excellent article on how to scan for Internet history through the use of one of their plugins.

Finally some further discussions around LEAK entries within the IE History. What are LEAK entries? Well Mike Murr from SANS classifies them as the following

"Essentially, a LEAK record is created when a cached URL entry is deleted (by calling DeleteUrlCacheEntry) and the cached file associated with the entry (a.k.a. "temporary internet file" or TIF) can not be deleted."

The above article discusses an easy way to create a LEAK entry. Mike also discusses in more detail at the following link on how to create LEAK entries using some Python scripts which are unfortunately unavailable due to dead links but you should be able to recreate it if required.

Again if you would like access to my firefox script you can grab it from the following


1 comment:

  1. Great blog post! I'm looking at some options for moving away from the script, because it uses a Perl module...I have some really good information regarding the format of the IE index.dat entries, and I'm going to look at parsing on a more direct level.