Internet history on Windows 8, particularly with Microsoft
Internet Explorer v10, has taken a turn from its traditions that we are all
used to. Gone are the days of
index.dat, or so it seems. That’s somewhat of a scary
statement to say, even for someone like myself who has only been around for a
couple years now.
Fortunately, I spend much of my time doing research and
development, always trying to figure out things that can help the world of
forensics. With the help of Jimmy Weg,
I’ve been able to add on to my previous research (see hyperlink for details) into WebCacheV24.dat and came
across quite a few things.
Just a few directories down from the old
<user>\appdata\local\microsoft\windows\history directory is a directory
that may be a new good friend, WebCache.
Within this folder is a file named WebCacheV24.dat. Before learning of Mark Woan’s EseDbViewer, I
parsed these files manually by their hex values. It was great fun, and I figured out a lot of
information. Most of my initial research
on this can be found on the LCDI blog, if at all interested.
However, I wanted to now take it to the next level with
EseDbViewer and verify my results against what I had previously found. First step is obvious, open up
WebCacheV24.dat into the program. On the
left side of the window is a Table Name pane:
Important information for navigating throughout the tables is
found in the Containers table. All
containers are listed numerically and display the path of the directory that is
being extracted for that specific table. The name of the type of data that is being
extracted is shown as well. For example,
in the follow picture, container 10 and 14 both are being extracted from c:\users\forensicator\appdata\local\microsoft\windows\history\history.ie5\mshist[daterange].
With an image that has much more information, there could be
upwards to 50 or more containers. With
that in mind, it’s quite obvious why the Containers table is very important to
parse through before looking into each and every container. For my purposes, I will examine containers 2,
6, 10 and 14.
Before going into the parsing, the following is my documentation
table that I created while visiting websites:
Website/URL
|
Time/Date of Visit
|
Opened IE – default page Bing.com
|
16:28 - 7/18/2012
|
NBA.com
|
16:28
|
Facebook.com
|
16:28
|
Hackintosh.com
|
16:29
|
Bing search: Asrock
|
16:30
|
Asrock.com
|
16:30
|
Z77 Extreme6 Specs
|
16:31
|
Google.com
|
16:32
|
Google search: asrock z77 extreme6 mac compatibility
|
16:32
|
Google search: best mac compatible motherboards 2012
|
16:33
|
Macbreaker.com
|
16:34
|
Google search: best mac compatible motherboards 2012
|
16:42
|
Macbreaker.com
|
16:42
|
Tonymacx86.com
|
16:43
|
Nba.com
|
17:00
|
Twitter.com
|
17:01
|
Opened IE – default page Bing.com
|
09:08 - 7/19/2012
|
Nba.com
|
09:08
|
Tonymacx86.com
|
09:15
|
Newegg.com
|
09:21
|
Tonymacx86.com
|
09:23
|
As one last note, please keep in mind that the containers I am looking at here (2,6,10,14) may change from case to case. This is why parsing the Containers table first is extremely important.
But, without further ado, here goes:
Container 2
Container 2 contains information
that looks very similar to the information that I parsed manually in the
WebCacheV24.dat file, at least in terms of its syntax. Oddly though, it’s located within users\forensicator\appdata\local\microsoft\windows\history\history.ie5,
which is the location of where the all-containing index.dat file used to be
located. Instead, now, there is a
container.dat file in this folder that (in EnCase) appears empty. Apparently not so empty after all.
The first thing that pops out in
this container is Bing searches that I performed. Pretty easy find, just takes a little
scrolling.
The next thing to do is to check
the time stamps for these and verify them.
Thanks to Jimmy Weg for pointing out that the numbers here are decimal
and need converted to hexadecimal, and then run through D-Code or a similar
tool. The time values displayed by
EseDbViewer are shown in the following image:
For the following times, I am using the values in the fifth row
down, “Visited: Forensicator@http://hackintosh.com/”
Time Entry
|
Decimal
|
Hexadecimal
|
Actual Time
|
Accessed Time
|
129871833391583038
|
1CD65BE8FA24F3E
|
Thu, 19 July 2012 09:55:39 -0500
|
Modified Time
|
129871169652117654
|
1CD652405ADD096
|
Wed, 18 July 2012 15:29:25 -0500
|
Sync Time
|
129871833391583038
|
1CD65BE8FA24F3E
|
Thu, 19 July 2012 09:55:39 -0500
|
Expiry Time
|
129893633652122884
|
1CD7992546B6504
|
Mon, 13 August 2012 15:29:25 -0500
|
When parsing through this container and the table, it is very
common to find the same value in many places for both Accessed Time and Sync
Time. There are also many instances
where the Expiry Time is listed as 0.
Strangely, though, the accessed/sync times are one hour behind what they
should actually be, in reference to the logs from earlier.
Another value from these tables that appeared off is Modified
Time. I created this virtual machine for
this testing at 16:00 on July 18th, 2012, and logged my first time
opening the browser at 16:28. Despite
this, the time for this entry is thirty (30) minutes before the creation of the
system even.
Container 6
Despite being listed as a container that should hold
history, this container seems to contain mostly cookies when initially looking
at it. Typically on a Windows Vista or
Windows 7 machine, when an index.dat file is found in
…\windows\history\low\history.ie5, it is because UAC is turned on and the
system is in Protected Mode. Using
default settings will cause these folders to be used for all cache, cookies,
and history for the internet security zone and restricted security zone.
With that being said, this particular container
still contained information mainly relating to cookies, as shown below:
Container 10
Container 10 holds url history that is more common
from what we’ve seen before. It is
broken down though by date and week periods, similar to how MSHIST files
work. Container 10, in this instance,
held the web browsing history for the date range of 07-18-2012 to 07-19-2012.
The information in the
following table pertains to the time values for the top row, 2012071820120719:
Forensicator@ Host: www.bing.com:
Time Entry
|
Decimal
|
Hexadecimal
|
Actual Time
|
Accessed Time
|
129871168894599004
|
1CD6523D886FF5C
|
Wed, 18 Jul 2012 15:28:09 -0500 UTC
|
Modified Time
|
129870916894440000
|
1CD64E92C25BA40
|
Wed, 18 Jul 2012 8:28:09 -0500 UTC
|
Sync Time
|
129871168894599004
|
1CD6523D886FF5C
|
Wed, 18 Jul 2012 15:28:09 -0500 UTC
|
Expiry Time
|
0
|
0
|
N/A
|
Once again, the confusing thing
about this is the time that is being tracked.
It references the accessed, modified, and sync time to a time all before
the system was ever booted, and accessed/sync time are again one hour behind
the time they should be.
Container 14
Container 14 holds the same content as container 10 with the
exception that it is just for a different day.
This is the same notion as what a user would get from MSHist index.dat
files that are separated by dates. Once
again, all date timestamps are still an hour off with this table.
Test Round 2
So, because my time stamps were
consistently one hour off the first time did this, I decided to test again and
again. The following table and screenshots
all come from my third round of testing, and yield the same results (timestamps
being one hour off) as the first two tests.
Time settings for the Windows 8
virtual machine:
The following table is my
documented browsing information for this test.
Website/URL
|
Time/Date of Visit
|
Opened IE – default page Bing.com
|
10:26 - 7/23/2012
|
Newegg.com
|
10:29
|
Facebook.com
|
10:37
|
Opened new IE – default page Bing.com
|
10:50
|
Woot.com
|
10:51
|
Computerforensics.champlain.edu
|
10:56
|
Nba.com
|
10:56
|
Google.com
|
10:59
|
Google Search: computer and digital forensics research topics
|
10:59
|
Forensicfocus.com
|
11:00
|
Due to there only being one day
of brief internet browsing on this machine, the Containers table only lists one
container directly linking to an MSHist directory.
The container directly linked to
MSHist, in this instance, was once again container 10. The following image shows this table, sorted
by Access Time in descending order. As
shown, it follows the same order that I documented.
For this time testing, we will use
the third timestamp down, in reference to 2012072320120724: ethanf@http://www.newegg.com/.
Time Entry
|
Decimal
|
Hexadecimal
|
Actual Time
|
Accessed Time
|
129875273668344960
|
1CD68DF901BBC80
|
Mon, 23 July 2012 09:29:26 -0500
|
Modified Time
|
129875129668340000
|
1CD68BE090A0920
|
Mon, 23 July 2012 05:29:26 -0500
|
Sync Time
|
129875273668344960
|
1CD68DF901BBC80
|
Mon, 23 July 2012 09:29:26 -0500
|
Expiry Time
|
129897737668350190
|
1CD7D4DDED950EE
|
Sat, 18 August 2012 09:29:26 -0500
|
Once again, the timestamps from
this are one hour behind what I documented.
Conclusions
It's great to have a lot of progress on the WebCachev24.dat files,
personally. I had been trying to parse them at the hex level for a VERY
long time. What a relief. The
frustrating part, now, is determining why it is giving me time stamps from
before the machine was even created, and why the accessed time timestamps are
all one hour off. I made sure that the
virtual machine was set to -0500 UTC, my machine was set to -0500 UTC, and
DCode set to -0500 UTC. Even still, all
my times are still coming up one hour before the time I actually accessed the
websites.
One more kink in my never ending road of turmoil with MSIEv10
history files. The other item that I haven’t
been able to check with this system yet is the NoQuota.edb
file within <user>\appdata\local\microsoft\internet explorer\Indexed DB. MSDN refers to Indexed DB as “… a W3C
Working Draft that enables you to store, search, and retrieve data on
the user's device, even when Internet
connectivity is disabled. IndexedDB is a
feature of the Web platform shared by IE10 and Metro style apps in the Windows
8 Consumer Preview.” A user also has the
ability to set a quota on the amount of data that is stored on the device
itself. These quotas, however, do not
apply to metro apps, nor did I set any quotas on this machine itself. Therefore, being able to parse this database should
give me more information relevant to internet history. As I stated in my previous blog post though,
I have been unable to run esentutl to fix the database and actually parse it.
