To fully understand the extracted data as presented by NetAnalysis, it is important to understand the type of data held in each column (or field). In this section, we will examine each column header and identify what type of data is stored in that field.
The type field in history files reflects the HTTP scheme or protocol for the selected record. For cache and cookie records, the type is updated to indicate the type of entry (e.g. cache/cookie). For download and other files, the type is updated to indicate the type of entry. This allows the examiner to quickly differentiate between history, cache, cookie and other record types.
If NetAnalysis identifies corruption when processing a record during import, the type indicator will show “corrupt”. You are likely to see some corrupt or partial records from data recovered by HstEx.
The tag field is a user set field which indicates whether the record has been tagged by the forensic examiner. A tag can be set or unset at any point to assist with reviewing the data. There is also an option on the Searching menu to jump back and forth through the tagged records (Searching » Find Next Tagged Record [F2], and Searching » Find Previous Tagged Record [Shift+F2]).
Last Visited [UTC]
There are a number of different date/time fields in NetAnalysis. This particular field shows the last visit date/time in UTC (Universal Coordinated Time). Not all date/time fields are available for every browser type.
Last Visited [Local]
This field shows the local time for the last visit; however, this value is dependent on the accuracy of the time zone settings which must be set prior to importing any data. You must check the time zone settings for the suspect system to ensure the local time is accurate. This value is calculated from the UTC field as explained above.
The time zone settings must be set to the same as the suspect system and not the time zone of the forensic examiner's workstation (see Time Zone Configuration for further information). All local timestamps are presented as local from the perspective of the suspect system time zone locale.
The hits field represents the count of visits or hits and is not always present in a cache or history record (it is browser dependent).
The user field is only present in Internet Explorer data, and on Windows NT based operating systems represents the user name of the account which was logged on. This data is not always present in cache entries. The string data will sometimes be presented in a different case from the actual account username.
The URL field represents the Uniform Resource Locator and is a string value which specifies where a known resource is located and the mechanism for retrieving it. If for whatever reason the URL is missing, the text ‘!< URL MISSING >!’ will be placed in the field, as shown in Figure 1.
The host field identifies the host that holds the resource. For example: www.example.com. The host is extracted from the URL.
The page title field represents the title tag set by the web developer in the HTML code when the web page was created. The title can be seen in the browser title bar when the user visits a particular page. This information is usually present in History data.
The absolute path field contains the path information that the server uses to resolve requests for information. Typically this is the path to the desired information on the server's file system; although it can also indicate the application or script the server must run to provide the information. The path information does not include the scheme, host name, or query portion of the URL.
The query field contains any query information included in the URL. Query information is separated from the path information by a question mark (?) and continues to the end of the URL. The query information returned includes the leading question mark. An example query string can be seen below.
|Example Query String|
The fragment field shows any text following a fragment marker (#) in the URL, including the fragment marker itself. Table 2 shows the full URL with a fragment marker string.
|Example URL with Fragment Marker String||Fragment Marker String|
The port field defines the protocol port used for contacting the server referenced in the URL.
This field is currently not used and is reserved for future use.
This field can either contain information extracted from a URL, or from data saved to a sign-on database. When the field represents the value from a URL, it relates to the user name portion from the URL in the format: ‘UserName:Password’. If the data relates to a user name from a sign-on database, the string will be encrypted. NetAnalysis does not support the decryption of sign-on user names at this time.
This field can either contain information extracted from a URL, or from data saved to a sign-on database. When the field represents the value from a URL, it relates to the password portion from the URL in the format: ‘UserName:Password’. If the data relates to a password from a sign-on database, the string will be encrypted. NetAnalysis does not support the decryption of sign-on passwords at this time.
URL redirection (also called URL forwarding) is a technique on the World Wide Web for making a web page available under many URLs. If a page is arrived at as a result of redirection (Internet Explorer will only show Server Side Redirects, i.e. where the server returns a 300 HTTP response code) this field shows where the browser was redirected to. The URL column will show where the browser was redirected from.
This field represents a URL to a valid RSS feed.
When a user clicks on a hyperlink within an HTML page, the web browser sends a request to the corresponding web server for the new page. As part of the request header, the browser also sends URL information relating to the page containing the link. This URL is called the referring URL.
The referrer field is very interesting from a forensic point of view as it shows the URL from which the visit originated. For example, Mozilla Firefox records this information for each record. It is therefore relatively easy to track the actions of a user from page to page.
This field shows the path (relative to the local machine) where the user has selected to save a downloaded file.
This field shows any sub-folders that may be present when identifying the location of a cached file. This field is used for Internet Explorer, Firefox v4+ and Opera v10.5+ cache.
This field shows the name of the file containing a cached resource or object. In a download record, this field will show the name of the downloaded file.
This field shows the file extension of the cached (or downloaded) resource from the “Cache File” field. This column was added to make it easier for examiners to identify and filter particular file extensions.
This field relates to the original length of a cached or downloaded item in bytes.
This field indicates whether a cached item exists in the recovered cache data. As the data is imported, the local cache path is identified and a test made to see if the resource exists. If it does, the item will be available for review or export.
If a cached item or object does not exist (or the record is not a cached item) the menu items relating to exporting the item (or rebuilding a page) will be disabled.
This field also indicates the existence of page content data in Google Chrome ‘History Index’ files.
We do not check for the existence of downloaded files as this data may not be present during the import of browser related files.
This field holds the HTTP response data which has been collected by the browser during the download of a resource object. Different browsers store different portions of the HTTP response and not all fields may be present.
Cache Entry Type Flag
This field is only used for Microsoft Internet Explorer and shows the flags that were set for a particular cached entry. They can be:Normal, Cookie, History, Edited, TrackOffline, TrackOnline, Sticky and Sparse.
This field shows the cached object MIME type.
This field shows the length of the cached object, in bytes, and is read from the HTTP response object. With a download record, this field reflects the length of the downloaded data.
This field shows the HTTP content encoding scheme. This is covered in Section 14 of RFC 2616 which covers Header Field Definitions.
This field is only used for Microsoft Internet Explorer and relates to the time zone active bias at the time the visit was made. In the Daily INDEX.DAT file, there are two dates stored, one in local time and one in UTC. Examination of these dates can show the offset from UTC. As NetAnalysis imports Internet Explorer data, it checks the bias difference between the Last Visited UTC/Local times and adds it to this column. NetAnalysis can also detect when the active bias parameters are outside the import time settings and will flag this issue to the examiner in the summary screen shown when the data has finished being imported.
Date First Visited [UTC]
This field shows the first visit to the URL. This field is only available with certain browser data types.
Date Expiration [UTC]
This field shows the expiration date for a cached object. HTTP supports caching so that content can be stored locally by the browser and reused when required. Of course, some types of data such as stock prices and weather forecasts are frequently changed and it is important that the browser does not display stale versions of these resources.
Browser caching is controlled by the use of the Cache-Control, Last-Modified and Expires response headers.
Date Last Modified [UTC]
This field shows the last modified date for a cached object. As with the “Date Expiration” field above, the web server can return a Last-Modified date as part of the HTTP response headers.
Date Index Created [UTC]
This field is used only in Microsoft Internet Explorer and is recovered from Weekly INDEX.DAT records. It reflects the date/time value when the INDEX.DAT file was created.
Date Added [UTC]
This field shows the date a cached object was added to the cache.
Date Last Synch [UTC]
This field shows the date a cached object was last synchronised.
This field shows the full path of the source file from which the record was recovered. If the source is a HstEx file, this field will show the original source that HstEx recovered from (e.g. an e01 image or physical device).
This field shows where the data was found within the source file. The offset can be displayed in a number of different formats depending on the source type. If the source is a physical device or an image representing a physical device, it will show the Physical Sector and Sector Offset (e.g. PS: 9058032 SO:384). If the source is file based, such as a binary dump, it will show the File Offset of the data from the start of the file (e.g. FO: 483273123). It does not always make sense to identify the exact location of data within a file by an offset; for example, if the data is recovered from a database it would make sense to show the database record index. Some other file types (e.g. Apple Safari binary PLIST) store the record data in different locations within the file, and the file offset will not assist in validating the recovered data. In these cases, we provide the record number or record Index. This is displayed as either an Index or ID.
This field identifies the type of record. For example the record may be one of the following: History, Cookie, Cache, Download etc.
This field represents any version information which has been identified during the extraction process. For example, many cache entries store a version number which can help identify the original browser version.
This field relates to Internet Explorer only and reflects the type of record in the INDEX.DAT file. Possible entries include: URL, REDR and LEAK. Table 12 explains the purpose of each type.
This is a standard URL record for Internet Explorer which is not a redirect or a LEAK.
This type of record relates to a Server Side Redirect. This record contains a string relating to the URL which caused the redirection.
If the data is still available, NetAnalysis can identify the record containing the date/time information and URL the browser was redirected to.
This type of record relates to a cache or cookie item that Microsoft Internet Explorer was unsuccessful in removing. This may have been due to the file being locked or in use when the attempt was made.
This record would have originally been a URL record that had subsequently been updated to LEAK status to indicate it could safely be removed at a later stage. LEAK records are often incomplete and may not show the full original URL.
The status field contains further information relating to a particular record, which may be available from the original file, and has no corresponding NetAnalysis workspace column. It can also display information such as flagging partially corrupt records.
The bookmark field is set by the forensic examiner and contains a string field that can be used to identify or describe a record. The bookmark string appears in the Advanced Report and is commonly used to annotate particular records when they are of evidential value to your case.
When a record of interest is found, the bookmarking function can be used to highlight and comment each individual record. Any bookmarked records will show a bookmark icon before the start of the URL. In Figure 39, the bottom record has been bookmarked.
This field represent a Unique Reference Number and is allocated by NetAnalysis during the import process. It can be used to easily identify a particular entry in a workspace. When a cached item is exported or a cached page rebuilt, this Unique Reference Number is used to reference the exported file. Any exported resource will have the same URN as its corresponding record in the NetAnalysis Workspace. If you order the records in the workspace by URN, you will see the order in which they were imported.