When using third party image mounting tools to perform the forensic examination of NTFS file systems, it is extremely important to understand NTFS Junction Points so that you don’t find yourself making a critical mistake during your analysis. An issue has been identified with third party image mounting software where NTFS junction points are hard linked to folders on the forensic investigator’s own hard disk. If you use software to process a file system (such as NetAnalysis® or Anti-Virus software) and the file system is mounted with junction points, the Operating System on the forensic workstation may point the software to folders which are not contained within the suspect volume. This leads to the extremely serious situation, where the investigator may inadvertently process their own file system.

This is possible with the following Operating Systems and filesystems:

Operating / File System
Microsoft Windows Vista with NTFS volumes (and server Operating Systems)
Microsoft Windows 7 with NTFS volumes (and server Operating Systems)
Microsoft Windows 8 with NTFS volumes (and server Operating Systems)

Symbolic Links

Windows 2000 and higher supports directory symbolic links, where a directory serves as a symbolic link to another directory on the computer. By using junction points, you can graft a target folder onto another NTFS folder or “mount” a volume onto an NTFS junction point. Junction points are transparent to software applications.

An NTFS symbolic link (symlink) is a file system object in the NTFS file system that points to another file system object. The object being pointed to is called the target. Symbolic links should be transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with POSIX operating systems, and were introduced with the modifications made to the NTFS file system with Windows Vista. Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. Additionally, the NTFS symbolic link implementation provides full support for cross file system links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.

Unlike an NTFS junction point, a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross file system links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.

Junction Points

In Windows Vista, Windows Server 2008 and Windows 8, the default locations for user data and system data have changed. For example, user data that was previously stored in the %SystemDrive%\Documents and Settings directory is now stored in the %SystemDrive%\Users directory. For backward compatibility, the old locations have junction points that point to the new locations. For example, C:\Documents and Settings is now a junction point that points to C:\Users. Backup applications must be capable of backing up and restoring junction points. These junction points can be identified as follows:

  • They also have their access control lists (ACLs) set to deny read access to everyone.

Applications that call out a specific path can traverse these junction points if they have the required permissions. However, attempts to enumerate the contents of the junction points will result in failures. It is important that backup applications do not traverse these junction points, or attempt to backup data under them, for two reasons:

  • Doing so can cause the backup application to back up the same data more than once.
  • It can also lead to cycles (circular references).

Some mounting tools do not respect these permissions and therefore allow software applications to follow the links. As the links are hard coded into the file system, they can point to actual folder locations on the forensic workstation.

Per-User Junctions and System Junctions

The junction points that are used to provide file and registry virtualisation in Windows Vista, Windows Server 2008 and Windows 8 can be divided into two classes: per-user junctions and system junctions.

Per-user junctions are created inside each individual user’s profile to provide backward compatibility for user applications. The junction point at C:\Users\[username]\My Documents that points to C:\Users\[username]\Documents is an example of a per-user junction. Per-user junctions are created by the Profile service when the user’s profile is created.

The other junctions are system junctions that do not reside under the Users\[username] directory. Examples of system junctions include:

  • Documents and Settings
  • Junctions within the All Users, Public, and Default User profiles

Examining Junction Points

The following image shows a volume containing junction points. You can also see the corresponding hard link.

Even though, this volume is mounted as F, accessing the folder F:\Users\All Users opens the link and presents the files from C:\ProgramData as if they were actually contained within F:\Users\All Users.




Introduction to Blade® v1.9

We are pleased to announce the release of Blade v1.9.

Digital Detective Software - Blade Professional - Forensic Data Recovery


This release of Blade® brings a number of fixes and some great new features.  This is the first release of Blade® to have evaluation capabilities which allow the user to test and evaluate our software for 30  days. When Blade is installed on a workstation for the first time (and a valid USB dongle licence is not inserted) the software will function in evaluation mode.

The following list contains a summary of the new features:

  • Support for Advanced Forensic Format (AFF®)
  • Hiberfil.sys converter – supports XP, Vista, Windows 7 32 and 64bit
  • Accurate hiberfil.sys memory mapping, not just Xpress block decompression
  • Hiberfil.sys slack recovery
  • Codepage setting for enhanced multi-language support
  • SQLite database recovery
  • 30  Day evaluation version of Blade® Professional
  • New recovery profile parameters for more advanced and accurate data recovery
  • Support for Logicube Forensic Dossier®
  • Support for OMA DRM Content Format for Discrete Media Profile (DCF)

We have also been working on the data recovery engines to make them more efficient and much faster than before. The searching speed has been significantly increased.

Release Information

For further information, please see the following:


A frequent question when dealing with browser forensics is ‘Does the Hit Count value mean that the user visited site ‘x’, on ‘y’ occasions?’ Most browsers record a ‘Hit Count’ value in one or more of the files they use to track browser activity, and it is important that an analyst understands any potential pitfalls associated with the accuracy, or otherwise, of this value.

We recently received a support request from an analyst who was analysing Internet Explorer data. They had found a record relating to a Bing Images search, which showed a hit count of 911. The particular search string was significant, and very damning had it actually been used 911 times. The analyst wanted to know if the hit count value could be relied upon.

The following experiment was carried out in order to establish how this surprisingly high hit count value could have been generated. In order to obtain a data set which contained as little extraneous data as possible, a brand new VMWare virtual machine was created. The machine was setup from the Microsoft Windows XP SP3 installation disc, which installed Internet Explorer v 6.0.2900.5512.xpsp.080413-2111 by default. Two user accounts were created on the machine – one to be used as an Admin account, for installing software etc; and the other to be used as the ‘browsing’ account. This separation of the accounts further assisted with minimising the possibility of any unwanted data being present within the ‘browsing’ account. Using the Admin account, the version of Internet Explorer in use on the virtual machine was upgraded to IE v 8.0.6001.18702. The ‘browsing’ account was then used for the first time. Starting Internet Explorer immediately directed the user to the MSN homepage. The address ‘’ was typed into the address bar, which led to the Bing search engine homepage. The ‘Images’ tab was clicked. This Auto Suggested a search criterion of ‘Beautiful Britain’, as can be seen in the figure below:



Figure 1

The term ‘aston martin’ was then typed into the search box, as shown below:


Figure 2

None of the images were clicked or zoomed, nor was the result screen scrolled. Internet Explorer was closed, and the browsing account logged off. The Admin account was used to extract the browser data for processing in NetAnalysis. The below image shows some of the results. Both of these entries are from Master History INDEX.DAT files:


Figure 3


As can be seen, both entries show a hit count of 5. Both of these pages were visited only once, so it is immediately apparent that the hit count value maintained by Internet Explorer may not be an accurate count of how many times a particular page has been visited. However, this still did not explain how Internet Explorer had produced a hit count of 911.

The virtual machine was started again, and the browsing account logged on. The previous steps were repeated; typing ‘’ into the URL bar; visiting the Bing homepage; and clicking on the ‘Images’ tab. Once again, Bing Auto Suggested the search criterion of ‘Beautiful Britain’, and displayed the same thumbnail results page. The search criterion ‘aston martin’ was again typed into the search box and the same thumbnail results page was produced. None of the images were clicked or zoomed. The results page was scrolled using the side scroll bar, which generated more thumbnails as it went. Internet Explorer was closed, and the browsing account logged off. The Admin account was used to extract the browser data for processing in NetAnalysis. The below image shows some of the results. Both of these entries are again from Master History INDEX.DAT files:



Figure 4

As can be seen, the ‘Beautiful Britain’ search now has a hit count of 13 – it is not at all clear how Internet Explorer determined this figure. Moreover, the ‘aston martin’ search now shows a hit count of 511. This page was not visited 511 times, nor were 511 of the thumbnail images clicked. The contents of the INDEX.DAT for the local cache folders (Content.IE5) were checked to see how many records were held relating to thumbnails that had been cached. The results were as follows:


Figure 5

So it does not even appear that there are 511 thumbnails held in the local cache. The result page was scrolled quickly, so the user did not see a large proportion of the thumbnail images.

In conclusion, it is apparent that the ‘Hit Count’ maintained by Internet Explorer cannot be relied upon. Although this experiment involved a quite specific process relating solely to image searches carried out on one particular search engine, the disparity between results and reality makes it clear that unquestioning acceptance of what Internet Explorer is recording as a ‘Hit Count’ could lead to significant errors if presented in evidence.

To complete the experiment, two further identical Virtual Machines were created. On one, the Google Chrome browser (v 15.0.874.106 m) was installed and used. On the other, the Mozilla Firefox browser (v 8.0) was installed and used. The same steps were repeated: typing ‘’ into the URL bar; visiting the Bing homepage; and clicking on the ‘Images’ tab. The results from these processes are shown below:



Figure 6




Figure 7

It is apparent that both of these browsers seem to maintain a more accurate ‘Hit Count’.

Internet Explorer Data

As forensic examiners will be aware, Microsoft Internet Explorer stores cached data within randomly assigned folders. This behaviour was designed to prevent Internet data being stored in predictable locations on the local system in order to foil a number of attack types. Prior to the release of Internet Explorer v9.0.2, cookies were an exception to this behaviour and their location was insufficiently random in many cases.

Cookie Files

Generally, for Vista and Windows 7, cookie files are stored in the location shown below:


The cookie filename format was the user’s login name, the @ symbol and then a partial hostname for the domain of the cookie.

Cookie Files with Standard Name

With sufficient information about a user’s environment, an attacker might have been able to establish the location of any given cookie and use this information in an attack.

Random Cookie Filenames

To mitigate the threat, Internet Explorer 9.0.2 now names the cookie files using a randomly-generated alphanumeric string. Older cookies are not renamed during the upgrade, but are instead renamed as soon as any update to the cookie data occurs. The image below shows an updated cookie folder containing the new files.

Random Cookie Names

This change will have no impact on dealing with the examination of cookie data; however. it will no longer be possible to identify which domain a cookie belongs to from just the file name.

NetAnalysis showing Random Cookie Names

NetAnalysis showing Random Cookie Names

Introduction to Userdata

Internet Explorer 8+ user data persistence is a function which allows online forms to save a small file to the system with information about values entered in a particular form.  This allows the user to retrieve a half filled web based form when they revisit.

Persistence creates new opportunities for website authors.  Information that persists beyond a single page without support from the server, or within the finite scope of cookies, can increase the speed of navigation and content authoring.

The folder structure where the data is actually stored is very much like the standard Internet Explorer cache folder structure. Inside the cache folder you will find the files containing data attributed to the associated website.

{user}\AppData\Roaming\Microsoft\Internet Explorer\UserData\

To demonstrate how this works, we have created a page which allows you to save a string to the local drive.

Once you have saved some string data using the above page, open the UserData INDEX.DAT file in NetAnalysis and review the entries.  Selecting F8 will bring up the search/filter dialogue.  Change the field name to ‘Type’ and enter ‘userdata’ in the filter text box.  When this is executed, you should find an entry as shown below:

If you navigate to the corresponding folder, you will find an XML file which contains the string you entered into the website.  This is shown below.

Introduction to Blade® v1.8

This release of Blade has a number of new features and improvements.  We have added 8 new Data Recovery Profiles to the Global Recovery Database, as well as releasing some new Professional Modules.  We have released a new 3GP/MPEG-4/ISO Base Media Format Intelli-Carve® Recovery Profile for the recovery of MP4/3GP video files.  This is particularly useful for those of you involved in the forensic examination and recovery of data from cell/mobile phone hex dumps or memory cards.

User Interface

We have made some minor updates to the user interface of Blade to make it easier to identify Global, Personal and Intelli-Carve® Recovery Profiles.  As you can see from screen below, different types of recovery profiles are represented by different icons.

Digital Detective Blade v1.8 Professional

Select Profile Categories

We have added the option to select recovery categories as well as individual recovery profiles.  This option is available from the Tools menu; select the category you wish to recover (e.g. common graphic types) and this will auto-select the profiles from that category.  To clear all of the selected profiles, simply select Clear from the Categories menu or press F5.  We have not added an option to select all profiles as it would not be practical to attempt to recover every supported file type (this would not make sense from a forensic perspective).

Unique Output Session Folders

In previous versions of Blade, if you attempted to extract data into a folder that had already been used, Blade would report that the folder was not empty and not permit the folder to be used; this can be a torment for examiners if they wish to keep all of the extracted data together.  To solve the issue, Blade now creates a session folder for every extraction.  This means that multiple passes across the same data source can be kept neatly together within a single folder.

Cancel / Partial Recovery Option

We have added this feature at the request of a number of our users.  Sometimes it is difficult to get your personal recovery profiles working correctly, particularly if they use complicated regular expressions.  Having to wait until the whole disk or image is processed to find out if they have worked correctly is extremely time consuming.  We have now added an option to perform a partial recovery on pressing cancel during the search phase (pass one).  If data headers have been identified during the search phase, Blade will prompt the user to recover that data.

In addition, we have added an option to automatically open the export folder once the extraction has completed.  This allows you to quickly open the folder and start examining the recovered data.

Recovery Profiles

We have made a number of changes to the Recovery Profiles to add additional functionality.  Figure 2 shows the new Personal Profile screen.

In the File Header section, we have added a new field for the number of bytes to the Start of the File (Bytes to SOF).  This value can be positive or negative and represents where the start of the file is in relation to the File Header Signature.  This takes into account data where there is a recognisable pattern or structure x bytes into the file, but no static header exists.


We have added a secondary File Landmark Section for additional data validation.  We have put this to good use for the recovery of Microsoft Office 2007 documents.

And finally, we have added a new field to take into account length adjustments for data types which contain length markers.  In the Data Length section, you can see the Length Marker Adjustment field.  This value can also be positive or negative.  We have put this into good use with AVI files where is a UInt32 length marker at offset 0x04.  This marker provides the length of the data following the header but does not take into account the four bytes containing the length marker or the header itself.  This meant that the AVI files recovered were 8 bytes too short.  Now you can add a length marker adjustment to add the missing 8 bytes back on to the file.

3GP/MPEG-4/ISO Base Media Format

ISO base media file format defines a general structure for time-based multimedia files such as video and audio.  It is used as the basis for other media file formats (e.g. container formats MP4 and 3GP).  ISO base media file format was specified as ISO/IEC 14496-12 (MPEG-4 Part 12).

Blade now contains an Intelli-Carve profile® which reads and validates the recovered data prior to writing it out.  In addition, Blade also recovers the metadata from each file and can write it out to a CSV log.  This is particularly useful for recovering date/time information from video data where the video has been recovered from unallocated clusters.  To set the metadata extraction options, right click on the recovery profile.

Blade also identifies the type of media file and appends the correct file extension.  The table below contains a list of file extensions which are supported.

3GP/MPEG4/ISO Base Media Format Specification Extensions
3gp, 3g2, dvb, f4v, f4p, f4a, f4b, jp2, jpm, jpx, m4v, m4p, m4a, m4b, mj2, mqv and mov

INFO2 Record Extraction and Deconstruction

We have added a new Professional Recovery Module for the recovery and deconstruction of INFO2 records (Recycle Recovery for Vista/Windows 7 in final QA and testing and will be released in Blade v1.9).  This recovery module has a number of output options.  The profile recovers INFO2 records relating to deleted files and writes the various fields out to a number of different formats.  The capture below shows the options which are available for this module.

Blade Forensic Data Recovery INFO2 Extraction Properties

The INFO2 extractor is bundled as part of the Link File Recovery module and is available to all Blade Professional users.  This module fully supports Unicode data.

Cryptographic Hashing

We have also added a hashing module which will work with a number of sources including forensic images (note: if you wish to MD5/SHA1 hash the content of an EnCase® e01 image, please use the e01 Conversion Module which has an option to hash the internal data from an EnCase® image and check it against the embedded hash without having to convert the image).

Supported Cryptogtaphic Hashing Algorithms
MD5, SHA1, SHA256, SHA384, SHA512 and RIPEMD160

To select the required hashing algorithms, right click on the module, select module properties and tick the required values.  Select the required source file or image (e.g. segmented image file *.001) and then an export folder which will contain the hashing report.

Further Information

Introduction to NetAnalysis® v1.52

Digital Detective is pleased to announce the release of NetAnalysis® v1.52 (and HstEx v3.6).  The release of this version has been eagerly awaited, so we are glad to say the wait is finally over.

NetAnalysis® v1.52 adds a number of new features and fixes some minor bugs.  Some of the major new features released in this version are the ability to export and rebuild the entire cache for each browser in a single process, new support for all versions of Google Chrome, support for Apple Safari Cache.db files and the ability to import recovered Apple Safari binary plist files recovered by HstEx® v3.6.

Export and Rebuild Cached Data

On 24th October 2002, we introduced the ability to rebuild and export cached pages to NetAnalysis v1.25. Over the years, this functionality has been extremely helpful in providing the necessary evidence in a whole host of forensic investigations.

In v1.52, we have responded to your requests and added the ability to extract and rebuild all of the cached content in one single process. This new functionality can be accessed from the Tools menu as shown below:

In addition to rebuilding and writing out the cached pages, NetAnalysis® exports all of the individual cached files and groups them by file type. This allows the contents of the cache to be quickly reviewed for evidence. The output also includes a full audit for each rebuilt web page and contains relative paths to allow the export folder to be archived to external media. You can also click on the hyperlinks within the audit log to access the cached content.

USB Licence Dongle Support

As some of you may be aware, our Blade® data recovery product is licensed via a USB licence dongle.  We are now offering the option to licence NetAnalysis/HstEx with a USB licence dongle.  The USB licence dongle provides you with much greater flexibility over a licence key file (which is restricted to one licence key per machine) as the USB dongle can be easily moved from machine to machine.  This is not permitted with a licence key file which is restricted to a single workstation.Existing licence key file holders can purchase a USB licence dongle upgrade through our store.  Please see the following link for further information on USB Dongle Licences.

TSV / CSV Exporting

Our support for exporting to TSV (tabbed separated values) and CSV (comma separated values) files has been completely re-written and enhanced. We now include the field column headers in the output and have added a progress bar for the export process. The export engines are also considerably faster than in previous versions.

It is also possible to switch off or hide any columns you do not need or to change the column order prior to exporting. This ensures the output format is in the same order as the grid columns. The export engine will also only output the current filtered records. The HTML export function will be updated in a future release.

Restricting Import Date Range

This is a new feature which was requested by some of our colleagues working within the corporate environment. In some investigations, they may only be permitted to import data within a certain date range. By selecting to restrict the import range, any data outside the target date range is not added to the workspace.

This functionality can be found by selecting Options from the Tools menu and selecting Restrict Data Range (as shown below).


F2 Find Next Tagged Record

This new function was added as a result of a request from a forensic examiner. During an investigation, it may be necessary to tag certain records of interest and then review the activity on either side of each record. This can be achieved by tagging the required records and then pressing F5 to remove all filters. Selecting F2 (or Searching » Find Next Tagged Record) will move the record pointer to the next tagged record allowing you to examine that record and the data surrounding it.

HstEx® v3.6 – Recovering Apple Safari History Binary Plist

NetAnalysis® now has the ability to import Apple Safari History binary plists recovered by HstEx® v3.6.

The Apple Safari browser stores Internet history records in an Apple Property List (plist). With the earlier versions of the Safari browser (version varies depending on operating system), this file was in XML format. In later versions, Apple switched to using a proprietary binary plist format. NetAnalysis supports both XML and binary plist files and now supports the recovery of this data direct from a forensic image or write protected physical/logical device.

The data is recovered by HstEx® and output in the form of *.hstx files. These files can then be loaded directly into NetAnalysis® v1.52. As of the publication of this article, NetAnalysis® and HstEx® are the only forensic tools capable of recovering this data.

Further Information


Some of you will have noticed that from NetAnalysis® v1.50 there have been numerous new date and time columns added. These new timestamps were identified during months of research and development and are now included with the latest release. The image below shows some of the new fields from Internet Explorer. This article will look at each of the new columns and explain what they mean.


Last Visited [UTC]

This column should be self explanatory. It is the timestamp which reflects the last known recorded visit to a webpage (or object) in Coordinated Universal Time (UTC). Normally, this timestamp is extracted directly from the source record and not changed in any way by the time zone information set in NetAnalysis. With the exception of Internet Explorer Weekly INDEX.DAT records, all other records have their timestamps saved as UTC values. Weekly records are stored as local times and therefore have to be converted to UTC to fill this column.

Last Visited [Local]

This column contains the timestamp which reflects the last known recorded visit to a webpage (or object) in Local time. This timestamp is calculated by using the data from the Last Visited [UTC] column and converting it to Local time using the time zone information set in NetAnalysis prior to extraction (with the exception of Daily INDEX.DAT records which is already stored in Local time).

Date Expiration [UTC]

This column contains a timestamp (in UTC) which reflects the date and time when the object or record is no longer regarded as valid by the browser. For example, in History records, you will see that the expiration time is set according to the amount of days the browser is set to keep history records, whilst the cache expiration time can be set by the web developer and is delivered to the browser during the HTTP response. This column reflects the ExpireTime field in the INTERNET_CACHE_ENTRY_INFO Structure.

Date Last Modified [UTC]

This column contains a timestamp (in UTC) which reflects the date and time the webpage (or object) was last modified (last written). This information is passed back to the browser as part of the HTTP response. Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time.

Date Index Created [UTC]

This column contains a timestamp (in UTC) which reflects the date and time the Weekly INDEX.DAT file from Internet Explorer was created.

Date Last Synch [UTC]

This column contains a timestamp (in UTC) which reflects the last date and time at which an object was checked for freshness with the origin server. LastSyncTime is initially set as the time at which an object is added to the cache, and is updated every time the browser verifies freshness of the object with the server.

Date First Visited [UTC]

This column contains a timestamp (in UTC) which is available during the extracting of Netscape and Firefox v1-2 History. It reflects the first date and time at which a web page (or object) was visited.

Date Added [UTC]

This column contains a timestamp (in UTC) which is available during the extracting of Netscape, Firefox and Mozilla bookmark files. It reflects the date and time at which an entry was added to the bookmark file.

Further Information

For a breakdown of NetAnalysis® v2 Date/Time fields, please see a breakdown of the grid columns: NetAnalysis® v2 Grid Columns.


The Internet Explorer disk cache is a storage folder for temporary Internet files that are written to the hard disk when a user views page from the Internet.Internet Explorer uses a persistent cache and therefore has to download all of the content of a page (such as graphics, sound files or video) before it can be rendered and displayed to the user.Even when the cache is set to zero percent, Internet Explorer requires a persistent cache for the current session. The persistent cache requires 4 MB or 1 percent of the logical drive size, whichever is greater.

Disk Cache Storage Location

The disk cache location varies across operating systems and can usually be found in the following default locations:

Digital Detective NetAnalysis Cache Location Windows 98

Figure 1

Digital Detective NetAnalysis Cache Location Windows 2K and XP

Figure 2

Digital Detective NetAnalysis Cache Location Windows Vista and 7

Figure 3

To identify the correct location of the cache for each user, the registry hive for the particular user must be examined. You cannot rely upon the live cache folder being in the default location. Figure 4 shows the registry key containing the cache folder location. Users have been known to move their cache location in an attempt to hide browsing activity.

Digital Detective NetAnalysis Cache Examination Shell Folder Location

Figure 4

The “User Shell Folders” subkey stores the paths to Windows Explorer folders for each user of the computer. The entries in this subkey can appear in both the “Shell Folders” subkey and the “User Shell Folders” and in both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. The entries that appear in user “User Shell Folders” take precedence over those in “Shell Folders”. The entries that appear in HKEY_CURRENT_USER take precedence over those in HKEY_LOCAL_MACHINE.

Temporary Internet Files Folder Structure

Within the Temporary Internet Files folder, you will find a Content.IE5 folder.  This folder is the main disk cache for Internet Explorer.  Outlook Express also writes data to this location as is explained later in this article.Inside the Content.IE5 folder, you will find a minimum of 4 cache folders.  The file names for these cache folders comprise of 8 random characters.  When further cache space is required, Internet Explorer will add additional folders in multiples of 4.  Figure 5 shows the layout of a typical Internet Explorer disk cache.

Digital Detective Windows Forensic Analysis Microsoft Internet Explorer Cache Folders

Figure 5

Content.IE5 INDEX.DAT File

The cache INDEX.DAT file is a database of cache entries.  It holds information relating to individual cached items so that the browser can check whether the resource needs to be updated (eTag) and information relating to the location of the cached item.  It also stores the HTTP (Hypertext Transfer Protocol) response header for the resource.At the start of the INDEX.DAT file, you will find a zero based array holding the names of the cache folders.  Each individual URL record contains an index value which refers to a specific folder in the array.  This allows Internet Explorer to correctly identify the location of a cached item.  This can be seen in Figure 6 below.

Digital Detective NetAnalysis INDEX.DAT Forensic Analysis

Figure 6

As files are saved to the cache, Internet Explorer uses a specific naming convention as shown in Figure 7.  The only exception to this rule is when data is written to this location by Outlook Express.

Digital Detective Forensic Analysis of Internet Explorer Cache Naming Convention

Figure 7

As pages and resources are cached, they can easily end up in different folders. Internet Explorer attempts to keep the volume of data and number of cached items across each cache folder as level as possible. As Internet Explorer writes files to the cache folders, it checks to see if a file with the same name already exists.  This is frequently the case when web developers do not use imaginative or descriptive names for their files.  If the file already exists within the folder, Internet Explorer will increment the counter.  If no file exists, the counter portion of the file name is set to 1. Files with the same naming structure within a cache folder do not necessarily belong to the same web site.  Also, multiple visits to the same web site can easily result in files with similar naming conventions being spread across all the cache folders.  Cached resources can also become orphaned when the INDEX.DAT entry is not written to disk (such as when Internet Explorer crashes before the entries are written).  Figure 8 shows a typical cache folder.  There are two files within this folder which would have had the original name “images.jpg”.  Internet Explorer has renamed them “images[1].jpg” and “images[2].jpg”.

Digital Detective Internet Explorer Forensic Cache Analysis Folder Structure

Figure 8

Outlook Express Email Client

Microsoft Outlook Express also uses the Content.IE5 folder as a temporary cache.  When a user selects an email message within the client, Outlook Express reads the data from the corresponding DBX file and caches the components of the email so that it can be rendered on screen for the user as an email message. The structure of the DBX files is such that the email message is broken down into blocks and has to be rebuilt before it can be rendered.  If the message contains any attachments, they are stored in Base64 format and stored within the file.  The attachments also have to be extracted, decoded and cached prior to rendering on screen.As the message is rebuilt, Outlook Express saves the different elements of the message to the disk cache as a temporary file.  The naming convention is different to Internet Explorer.  In the past, some forensic examiners have not been aware of this and have incorrectly attributed data in the cache to a visit to a web page when it in fact was there as the result of viewing an email message. The file structure is shown in Figure 9.  The asterisk values represent hexadecimal digits.  Figure 9 also contains some example file names.

Digital Detective Forensic Analysis of Internet Explorer Cache Outlook Express Temporary File Naming Convention

Figure 9


Microsoft Internet Explorer maintains a number of INDEX.DAT files to record visits to web sites as well as to maintain cache and cookie data.  In this article, we will look at the Daily and Weekly files.

Daily INDEX.DAT Entries

The Daily INDEX.DAT file maintains a Daily record of visited pages.  This INDEX.DAT file has an unusual HOST record entry which helps the investigator analyse the pattern of visits to a particular web site.

The HOST record entry is used by Internet Explorer to display the hierarchical history structure when showing the user which web sites have been visited.  Each record contains a number of timestamps with the important data being stored in a FILETIME structure.  This timestamp structure contains a 64-bit value representing the number of 100-nanosecond intervals since 1st January 1601 (UTC).  The Digital Detective DCode utility can be used to convert these and other timestamp formats.

On the first daily visit to a particular web site, Internet Explorer creates a HOST entry in the INDEX.DAT record.  In effect, this entry represents the first visit to a particular HOST on specific day.  With further visits to the same web site, the HOST entry remains unchanged.  Examining the entries for the Daily INDEX.DAT will show when a web site was first and last visited during the period.  Figure 1 below shows an example of this when using the HOST filter view in NetAnalysis® v1 to look for visits to the Digital Detective web site.


Figure 1

Daily INDEX.DAT Timestamps

The Last Visited timestamp information is stored as two 64-bit FILETIMES located at offset 0x08 and 0x10 (Decimal 8,16).  They are stored as UTC and Local time values.  As there is no requirement to alter these timestamps, they are presented in an unaltered state in NetAnalysis® v1 as the “Last Visited [UTC]” and “Last Visited [Local]” columns.  Figure 2 and 3 summarise these timestamp values.


Figure 2


Figure 3

Establishing the Time Zone ActiveBias

As the URL records contain UTC and Local timestamps, it is possible to establish the Time Zone ActiveBias by establishing the time difference between both timestamps.  We discussed in a previous article on manually establish the system Time Zone settings.  The calculated ActiveBias information is represented in NetAnalysis® v1 by the ActiveBias column as shown in Figure 4.


Figure 4

NetAnalysis further uses this information to confirm the selected Time Zone is correct.  If the Time Zone ActiveBias is in conflict with the Time Zone setting in NetAnalysis®, the resulting timestamps may not be represented accurately.  The calculated ActiveBias is logged to the Audit Log as shown in Figure 5.


Figure 5

If NetAnalysis® detects that the Time Zone settings for the current forensic investigation are not correct, a warning dialogue will be shown immediately after the data has been imported.  Figure 4 shows the warning dialogue.


Figure 4

Examination of the ActiveBias column will show which entries are in conflict with the Time Zone Settings.

Weekly INDEX.DAT Entries

At the commencement of a new browsing week, the content from the Daily INDEX.DAT files is archived into a single Weekly INDEX.DAT file.  The actual timestamp information within the binary file changes for this file type when compared to the other files.

When the Weekly INDEX.DAT file is generated, the file created timestamp is saved at offset 0x10 of every URL record.  This is different to the other INDEX.DAT records as this location usually represents the Last Visited UTC Timestamp.  Many applications (including some software which claim to be for forensic purposes) get this wrong and misrepresent this timestamp as the “Last Visited Date”.

This timestamp is in FILETIME format and is saved as a UTC value.  This timestamp is presented within NetAnalysis in the “Date Index Created [UTC]” column.

The last visited timestamp is saved at offset 0x08 within the record as a LOCAL timestamp.  This is unusual, as FILETIME timestamps are normally saved as UTC values and the other INDEX.DAT files all contain a Last Visited timestamp with a UTC value.  With this timestamp, NetAnalysis takes the unaltered LOCAL time and saves it to the “Last Visited [Local]” column.  Unfortunately, the Last Visited UTC FILETIME value which was present in the Daily INDEX.DAT is not saved within the record and therefore has to be converted from a Local timestamp.

To calculate the UTC timestamp for the “Last Visited [UTC]” column, NetAnalysis takes the LOCAL timestamp at record offset 0x08 and converts it to UTC.  This conversion is calculated using the Time Zone value set in NetAnalysis prior to importing any data.  In doing so, dynamic daylight settings are also taken into account (as well as any year on year differences).

If a Weekly record is imported with the “No Time Zone Date/Time Adjustment” setting activated, NetAnalysis will show the LOCAL Last Visited timestamp but will not attempt to calculate the UTC timestamp.  In this case, the “Last Visited [UTC]” column will remain empty.  The “Last Visited [Local]” timestamp for Weekly entries is not changed or affected by NetAnalysis Time Zone settings.  It is left in an unaltered state.

Weekly INDEX.DAT Timestamps

The timestamp representation in NetAnalysis is shown in Figure 5 and 6 below.


Figure 5


Figure 6

Useful Links