This artifact has attracted my attention of late as I have
seen some very useful information here in a few recent cases. Here you find not
only browsed urls but webpage details like title (sometimes content) and timestamps.
Even data from encrypted pages (https) are stored here in plaintext, which by
default IE does not save in internet cache. I have even seen email and facebook
passwords here on occasion!
What is RecoveryStore and why is it present?
IE 8 and 9 have a tab recovery feature by virtue of which
you can restore all your tabbed browsing sessions if IE crashes, or when you
close IE and chose to save tabs on exit (so that they may be reopened automatically
when IE is started next time).
With IE8, Microsoft also introduced the concept of a ‘Travelog’ or 'Travel Log'. This is a mechanism to track urls (and associated parameters) that are fetched from a page when AJAX is used. AJAX is a technology which enables dynamic refreshes of small portions of a page without reloading the whole page. It was popularized by gmail and subsequently most webpages use it today. With AJAX, your main page url does not change, however the page contents change when your click around in the page (accessing data from other urls), this creates problems as you cannot use the browser back button to go back one click. To solve this problem (with back and forward buttons), the travelog is used to track AJAX urls. Read up more about it on MDSN here.
So where is this cached information?
The RecoveryStore can be found under
<profile>/Application Data on an XP machine and under
<profile>/AppData/Local on a Vista or Windows 7 machine under subfolder Microsoft/Internet Explorer/Recovery
Location of RecoveryStore files on a Windows 7 Machine |
Two folders are present by default, Active and LastActive.
Sometimes a couple of other folders are seen, High and Low. All folders contain
similar data, a few files with <GUID>.dat as their name and a single RecoveryStore.<GUID>.dat
file per folder. GUIDs are in the standard format {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.
Analysis of RecoveryStore files Part I
All files are in the Microsoft OLE structured storage
container format. When opened with a suitable viewer (many freeware available
for this, if you use encase, use ‘view file structure’ to mount), you find many
streams (files) within it.
There is a single RecoveryStore.<GUID>.dat file which
represents the recovery store preserving tab order and some other information.
It references the other <GUID>.dat files.
RecoveryStore.<GUID>.dat
This file contains 3 or more streams in it. If more than one
session (instances of IE) are running, then more streams will be present.
Stream Name
|
Description
|
|KjjaqfajN2c0uzgv1l4qy5nfWe
|
Contains some guids
|
FrameList
|
List of DWORDs, function unknown
|
TSxx
|
Contains guids of Tabs in Session x (ie,if TS1 then tabs in
session 1)
|
<GUID> in the filename
The GUID is actually a UUID (version 1), which is comprised
of a FILETIME like timestamp and the machine MAC address. The details of this
scheme can be referenced from RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt).
The timestamp is the first 60 bits of the UUID, and this represents the number
of 100 second nanosecond intervals since 15 October 1582. Note the only major difference
from Microsoft FILETIME values used everywhere else in windows is the starting
date which is 01 January 1601 for FILETIME.
This time is going to be the tab/recoverystore created time
and can be used to cross check the timestamp on disk for forensic validation.
These UUIDs are also found in the ‘|KjjaqfajN2c0uzgv1l4qy5nfWe’ stream in
RecoveryStore.<GUID>.dat
Example: {FD1F46CF-E6AB-11E0-9FAC-001CC0CD46AA}.dat
From this UUID, we can extract the timestamp as 01E0E6ABFD1F46CF
which decodes to 09/24/2011 12:51:58 UTC.
The last 6 bytes is the MAC address on the machine (00 1C C0
CD 46 AA), it can be from any of the network interfaces on the machine.
Timestamp Easy Conversion Process
(http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf)
An easy way of converting the timestamp without messing too
much with the math behind it is to subtract the time period between 15 October
1582 and 1 January 1601 and then using a FILETIME decoder program (like DCODE) to
do the rest. For the above example, we subtract 146BF33E42C000 (the excess time
period) from the original value to get 1CC7AB8BEDC86CF which is decoded as 09/24/2011
12:51:58 UTC.
<GUID>.dat files
Each file represents a tab in the browser. Inside each file
are 3 or more streams.
Stream Name
|
Description
|
|KjjaqfajN2c0uzgv1l4qy5nfWe
|
Contains some guids and last URL of tab
|
TravelLog
|
List of DWORDs representing each TravelLog entry
|
TLxx
|
Travelog stream (TL0, TL1, …)
|
TravelLog Stream
This stream has a complex binary format which stores many
items. The base URL, referrer url and page title are always present. Page
content, some timestamps and ajax parameters are optionally present.
I have been studying the format of the TravelLog and will
shortly publish it as Part II of this blog entry.
Update: An encase script is now available for download here to parse out travelLog info.
Update: An encase script is now available for download here to parse out travelLog info.