Monday, July 23, 2012

Attacking WebCacheV24 with EseDbViewer


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. 

7 comments:

  1. great information, but I cannot open the WebCache file in EseDBViewer. I right click the file, set this program as the one I want it to open, but nothing happens. I see no containers and no information. Thoughts?

    ReplyDelete
  2. It's a little strange how you have to open it, as esedbviewer does not allow you to select "all files" or ".dat files" as an option. However from within esedbviewer, when attempting to open your file, navigate to where you have exported the WebCache file and simply begin typing the name of it into the dialog box under file name. It should be recognized in the drop down and let you select it to open.

    ReplyDelete
  3. in Windows 8.1 this directory isn't existent

    Do you have any idea where the WebCacheV24.dat now is?

    Perhaps in the cloud?

    ReplyDelete
  4. I'm examining the WebCacheV01.dat file and am seeing local file references. Example:

    Visited: username@file: ///C:/Users/username/Desktop/directory/Screenshot%20.png

    Does this mean files were uploaded from this directory to a web site via this web browser?

    ReplyDelete
    Replies
    1. I can answer my own question. Yes it does.

      From BrowsingHistoryView

      file:///C:/users/dale/appdata/local/temp/...a.bunch.of.hex.numbers Dropbox 2017-01-31 6:17:16 PM 1 Chrome Dale Default 143 0

      Delete
  5. Hi Ethan - I hope you are well and all is OK. I have a question please... I am working on a case where the user has deployed Bing search engine, mostly the inbuilt images tab. He has history entries where the text string includes search?=q. he states that he has not typed any of these search terms and they are nothing to do with him. I think the only times you get this text string is when you type a search or use a suggested search or embedded link... basically it requires physical user interaction to produce the search?=q - this does not occur automatically or get generally cached to history as part of the page... Am I right or can you advise me please... I know this is cheeky but i have a deadline of 12th Jan 2018... cheers - Mark

    ReplyDelete
  6. Great article.Thank you for sharing.But I still troubling about how to parse webcache.dat in hex.Would you like to do me a favor?Or I would like to use esentutl.exe.-

    ReplyDelete