It helps to have a policy clearly defining acceptable usage and defining the company's investigative abilities in a corporate setting. Writing a corporate policy for Internet usage should involve IT, Security, HR, and Legal to be successful. Ideally, the acceptable usage policy is presented to the employee at hiring or orientation, and the employee is made to sign a statement that he has received, read, understood , and agreed to abide by the guidelines. If possible, an annual refresh of the guidelines and re- acknowledgement should be obtained from all employees as well.

Acceptable usage policies cover much more than Internet activity, but they tend to arise frequently in legal matters (for example, lawsuits for wrongful dismissal) based on this particular type of investigation. Specifically to support forensic Internet investigations, an acceptable usage policy should state:

• Internet usage must follow not only the relevant Internet Acceptable Usage policies but also all other corporate policies (for example, the Code of Conduct). Activity violating these policies is expressly forbidden.

• The company has the right to monitor and log all Internet activities conducted using company resources.

• It is the exclusive responsibility of the CSIR team to lead Acceptable Usage investigations. It could also be HR or another body. The point is to ensure that individuals do not investigate their neighbors without approval.

• Failure to follow any piece of the policy may result in disciplinary action, including termination.

If one terminates an employee for violation of an acceptable usage policy, the employee will need to show that:

• The employee had a policy in place prohibiting the actions taken by the employee.

• The employee was aware of the policy.

• The policy is enforced consistently at the organization.

The third area is one of the more difficult to prove. If the policy is overly strict (no non-business use of the Internet), it may be easy for the employee to show that other individuals had violated it as well. If it is overly lenient (limited personal use of the Internet is permitted), it may be difficult to prove excessive usage or inappropriate usage in a particular instance.

Favorites

The first place to start a web investigation is the Favorites folder. The Favorites folder contains URLs of websites saved by the user. Links to frequently visited pages are likely to be stored by the user in this folder, and the explicit storing of these links indicates intent. In addition to the preceding location, perform a search for the Favorites folder and any deleted copies elsewhere on the disk. For users who move between computers, this folder is frequently copied to other locations on the disk. Users looking to cover their tracks will likewise frequently delete this folder.

When examining the Favorites folder, an Internet connection may be required. The folder should be copied to an examination machine with a connection, and all of the URLs viewed independently. As shown in Figure 12-1, the folder contains the name of the link as well as the Date Modified, which reflects the date the link was actually added to the Favorites folder. The Favorites folder may also contain subfolders used to organize links. These should be investigated as well.

Figure 12-1: Favorites folder contents

The specific link names displayed in the folder default to the contents of the <title> tag in the HTML on the page. This may not accurately reflect the contents and is user-alterable. To view the actual link, right-click on the individual document and select Web Document. As shown in Figure 12-2, the link titled Cooking Lessons actually goes to a much different website. As noted previously, any suspicious sites should be viewed from a forensic machine. Sites that sound harmless may contain redirects or content not evident from their URLs (http://www.whitehouse.com being the canonical example).

Figure 12-2: Properties of a favorite link

While viewing the properties, also note any sites with "Make this page available offline" checked. These sites may have entire copies of the page content stored on the drive for offline browsing, a definite plus for the forensic analyst.

One final note on Favorites: Even if a site sounds innocuous and viewing the site reveals nothing of interest, there is one more location to check. Under %SYSTEMROOT%\System32\Drivers\Etc is a file called Hosts. The Hosts file, shown in Figure 12-3, is used by Windows to resolve web hostnames before checking DNS. Because of this, it is useful for testing and system optimization but can also be used to hide the tracks of potentially incriminating web activity. Note the entry for http://www.disney.com. Instead of resolving to the Disney website, any URLs with http://www.disney.com will resolve to the IP address in the Hosts file, which is not the expected location. In one investigation I headed, a user was complaining of pornography appearing when she visited Yahoo!, Google, and other common sites. It turned out that co-workers had redirected the site names in the Hosts file as a practical joke.

Figure 12-3: Malicious Hosts file entry

Favorites can be exported to a local HTML file as well. By default, the file name exported is http://www.Bookmarks.htm. A search for this file on the drive may turn up another copy of the Favorites folder for analysis.

History

After checking the Favorites folder, the History folders are the next location of interest. The History folders are best viewed with a tool such as NetAnalysis, shown in Figure 12-4, which will consolidate the results but can be viewed directly as well through the Windows Explorer Interface.

Figure 12-4: NetAnalysis output

Like NetAnalysis Pasco, a platform-independent freeware tool provides retrieval capabilities, but it lacks some of the more advanced features and GUI of NetAnalysis. Figure 12-5 shows a Pasco sample output.

Figure 12-5: Pasco output

The History folder contains a list of sites visited during the previous web browsing sessions, organized by the time of the visit. As with the Cookies and Cache directories, the URLs of these sites and usage details are stored in a file called Index.dat. The Index.dat file is located in the root of the History directory (or under the History. IE# subdirectory for Windows NT/2000/2003/XP), with subdirectories for each day's history. If the History is set to be collected for more than one week, there are additional subdirectories for the previous weeks' histories. These files are labeled MSHistMMYYYYDDMMYYYYDDMM. The first MMYYYY is the month that the records are relevant for. The second DDMMYYYY is the start period for that directory's records. The third DDMM is the date at which the records stop. Thus, a file with the name MSHist012004011220040119 would contain the URL viewing history for January, 2004. The start date of the history stored in that folder would be January 12, 2004, and the non-inclusive end date January 19, 2004.

The main index.dat file contains a record of all URL's visited during the History period. This is used for AutoComplete on the address bar and for visited link highlighting. When one begins typing "www" and a list of sites starting with "www" appears in the address bar, this is the file used. The sites that appear when the address bar dropdown list box is used are URLs that one explicitly typed in and stored in the registry. The subfolder index.dat files contain basic information on the sites viewed during their respective periods.

Each index.dat file is composed of three parts :

• Header. Contains the size of the file, in hex, followed by a NULL (00h) terminated string.

• Hash table. These contain pointers to other directories with Internet Explorer stored content. For the Temporary Internet Files directory, these are the hash values that contain the names of the subdirectories.

• Activity records. The URL type of activity contains the fields shown in Table 12-1.

Figure 12-6 shows the actual hexadecimal output of a URL record. Note the Windows user name of the accessing party as well (Chad M.S. Steel) before the URL itself.

Figure 12-6: WinHex view of URL records

Because of a flaw in how Internet Explorer cleans its History file, deleted records without Hash table entries may still exist. As a result, even if the target cleans out his or her History using the Internet Explorer Clear History function, there is still potential information in these files for forensic analysis. NetAnalysis recovers these entries, and Pasco will as well with the -d option.

Cache

Internet Explorer stores local copies of recently visited sites for quick retrieval. These are located in the Temporary Internet Files hierarchy. As with the URL History, these directories contain Index.dat files that hold the names and URLs associated with each of the individual files.

The individual files themselves (including images as well as the actual HTML file) are located under Content. IE5, within individual subfolders (named with eight-character hash names). The Index.dat file under Content. IE5 contains the table linking the cache entries to these subfolders through hash tables. These subfolders are cleared when the user selects Delete Files within Internet Explorer and may need to be recovered using file recovery techniques detailed in Chapter 10.

The Index.dat file may be analyzed using NetAnalysis or Pasco as noted previously in the History section. Some examiners prefer to analyze all Internet activity at one time. I generally separate the analysis of the different entries. The reasoning behind this is as follows. The History folder contains URL's that were visited at a given point in time. While it may be possible to reconstruct what the user viewed using the Way Back Machine, for sites with frequently changing content (for example, news sites) it may be difficult to pin down exactly what the user saw. The Temporary Internet Files, however, have the capability to display the actual content from the cache that the user in question viewed.

To facilitate actual page reconstruction, the analyst can view the Index.dat file and determine what files are associated with a given URL, as well as where they are located in the cache. These files can be copied to a temporary directory and viewed with a browser that is not connected to the Internet. If the computer is connected, the browser may follow absolute URL's which will download the latest version of images from the servernot necessarily the version the suspect viewed at the time. If disconnected, absolute image links will not appear when opening the HTML file in Internet Explorer, although relative image links ( IMG tags within the HTML that reference file locations relative to the current HTML page location) will still appear if the images are in the same directory.

Images that cannot be found will appear as empty boxes with a red X through them. By right-clicking on the image and selecting properties, the analyst can view the directory structure where the original image was located as well as the image file name. By locating the file name in the Index.dat results and recreating the directory structure locally, the image can be copied to the appropriate location and the web page viewed as it was by the suspect.

Additionally, for cases that rely heavily on visual presentation (the screenshot of an actual web page can be of greater impact to a jury than a list of file contents) the temporary files can be copied to a local web server (still disconnected and running on the forensic machine), and the images and HTML files placed in the appropriate directories as noted previously. By putting entries into the HOSTS file for the hostname from the URL (for example, http://www.illegalimages.com) with an IP address of 127.0.0.1, even absolute links can be viewed locally. While configuring the forensic environment to better simulate the user's environment and allow the display of the page properly is a valid technique, altering the evidence itself (that is, changing the IMG tags in the HTML) to facilitate the viewing of content is not forensically sound.

The techniques noted previously rely on the use of the Index.dat file to identify content of interest. The same techniques can also be used in reverse. If viewing all of the images on a drive, or alternatively doing keyword searches, web pages or files that were downloaded from the Internet may be uncovered. By looking up these file names in the Index.dat file, proof of download can be obtained. From an image standpoint, if an image file that matches the appearance of a file in Temporary Internet Files has been saved elsewhere, an MD5 hash can be performed to validate they are the same file. A date comparison between the viewing date and date the file was saved under a different name can provide evidence to this end as well.

The presence of a single image file or even web page does not necessarily indicate that an individual willingly visited the site. If possible, it should be confirmed that the link to an image or webpage was neither part of a FRAME tag nor part of an image from an IMG link on a different site. Additionally, it should be confirmed that the site was not brought up as either a pop-up or redirect. This can be confirmed by a basic temporal analysis. Look at sites viewed immediately prior to the site in question and confirm they have no content which would unintentionally load the content in question.

Cookies

Cookies are stored on a computer when a suspect views an Internet site that uses them for tracking. There are two types of cookies: session and persistent. Session cookies used to tracking individual browsing sessions and are stored in memory. These are lost when the browser is closed, although remnants may remain in memory or the swap file. Persistent cookies are written to disk and stored as text files in the previously mentioned Cookies directory. Persistent cookies are used between browsing sessions to maintain state (for example, when a person visits http://www.Amazon.com and her shopping cart still contains the items she placed there a few days earlier, Amazon is identifying the user through a cookie).

Cookies not only identify locations visited, but may indicate activities performed there as well as provide information such as user names and passwords to the analyst. They are restricted to an individual host (for example, you do not want Barnes and Noble to see what is in your Amazon shopping cart) and have set expiration dates. There are no restrictions on what a website may write to a cookie in terms of text. As a result, any number of items useful to the examiner may be present. The general format of a cookie is to include a series of records under a filer called username@sitename.txt. Each record contains the following fields:

• Key. The name of the variable stored in the record.

• Value. The stored value of the key.

• Host. The name of the host from which the record was written.

• Secure. True or false depending on whether the cookie was downloaded via SSL.

• Modified Date. The date the value was last modified. May indicate the last site visit.

• Expiration Date. The date the cookie is no longer valid.

The actual information is encoded by default, so the use of a cookie viewer is required. NetAnalysis has the function built in, and the same company also provides a freeware cookie viewer. The Value itself may be encrypted. This is highly dependent on the server application. Occasionally, user names and passwords can be uncovered from cookies, although a more likely scenario is the uncovering of complementary information to an investigation. The following example shows the contents of a Mapquest cookie:

1) COOKIE FILE: cms99999@mapquest[1].txt

Cookie Record   0
Key:            mqs_p
Value:          401e7a61-00046-0014e-cdbcf391 
Host:           mapquest.com/
Secure:         False
Modified Date:  Mon, 02 Feb 2004 16:27:13 GMT
Expiry Date:    Sat, 31 Dec 2005 00:00:00 GMT

Cookie Record   1
Key:            locationhistory
Value:          {419472 -876564 ADDRESS {1060 W Addison St} Chicago IL
60613-4566 {COOK COUNTY} US {}} {388952 -770365 ADDRESS {1600
Pennsylvania Ave} Washington DC {} {} US {}}
Host:           mapquest.com/
Secure:         False
Modified Date:  Mon, 02 Feb 2004 16:33:09 GMT
Expiry Date:    Sat, 31 Dec 2005 00:00:00 GMT

As illustrated previously, Mapquest stores the actual addresses entered as saved location, useful in determining if a subject mapped out a given address involved in a crime.

Even if information is encoded in a cookie file, many times that file can be used to perform a masquerade attack. This can be useful for the forensic examiner to see what a suspect had in terms of contents on a given website (for example, whether the http://www.Amazon.com shopping cart contained books on lockpicking). To do this:

1. Delete all cookies, history, and temporary Internet files from the forensics examination machine.

2. Identify the cookies of interest on the suspect machine.

3. Copy the cookies to the Cookies directory on the examination machine.

4. Navigate to the websites in question.

For sites that store user names and passwords (even encrypted ones) or session identifiers in the cookie, this will make it appear to the server that the analyst is the suspect. If necessary, use a tool like Cookie Editor to change the expiration date if it has already passed.

In addition to the preceding locations, there may be other information of interest to the examiner in the registry. These locations are detailed as follows:

• AutoComplete and Intelliforms. When a user types information into a form field, Internet Explorer by default offers to remember that information to speed up future typing. This information is stored encrypted in the registry under HKCU\Software\Microsoft\Internet Explorer\Intelliforms. As with many Microsoft encryption implementations , there are weaknesses and the AutoComplete information can be viewed with the appropriate software, such as Windows Secret Explorer from LastBit. Everything from names and addresses to email addresses and passwords can be found here if AutoComplete is being used.

• TypedURLs. When a specific URL is typed into the address bar (as opposed to clicking on a link), it is stored in the registry in a separate location from the general History information under HKCU\Software\Microsoft\Internet Explorer\TypedURLs. The TypedURLs key contains a list of the most recently typed URLs, which can not only provide another view into browsing history but also can show intent (it is much harder to accidentally type a full URL in than it is to click a misleading link in an email message or webpage).

Firefox

Produced as an offshoot of the Mozilla project (itself an offshoot of Netscape), Firefox has grown in popularity at an exponential rate. Although the browser itself is substantially different both architecturally and visually from its Netscape ancestor , the forensic analysis is similar as Firefox uses the same basic file formats. As with Internet Explorer, the analysis can be broken up into Favorites, History, Cache, and Cookie analysis.

Unlike Internet Explorer, Firefox uses file-based configurations in lieu of registry-based configurations, primarily for cross-platform compatibility. Firefox data is stored locally under the Documents and Settings context for a particular user, within the key:

\Documents and Settings\profile name\Application
Data\Mozilla\Firefox\Profiles\firefox generated profile name\

All of the relevant forensic files will be present in this hierarchy.

Favorites

Favorites in Firefox are called bookmarks and, as with Internet Explorer, indicate web or local locations that an individual has actively chosen to save. The bookmarks are stored in an HTML file called http://www.bookmarks.html (a book-marks.bak file is created when last accessed as well), which contains information on toolbar bookmarks, quick search bookmarks, and menu bookmarks.

Toolbar bookmarks are links actually placed on the toolbar as buttons . The most frequently used sites are likely to be present in this section, titled Bookmarks Toolbar Folder. Quick search bookmarks are links to search engines directly from the address bar. Search engines added to the default list may show a favorite search tool. Menu-based bookmarks are in all other folders (or no folder at all) and indicate locations that are accessible through the Bookmarks dropdown list box. These likewise indicate locations that are likely to be frequently accessed or of enough interest to note.

The http://www.bookmarks.html file can be analyzed in three ways: as HTML, as plaintext, or through the Bookmark Manager included in Firefox.

Analyzing the http://www.bookmarks.html file as HTML is the simplest but least effective way to view the information contained therein. The file can be opened in any web browser. A copy of a http://www.bookmarks.html file opened in Internet Explorer had to do it for irony is shown in Figure 12-7; there are links on the Bookmarks toolbar folder to Browser Statistics and Yahoo! in addition to the default Firefox links.

Figure 12-7: The http://www.bookmarks.html file viewed as a web page

Although it provides reasonable visualization of links, the browser-based analysis does not show the included metadata on link MAC times and does not provide details on where links actually go, only the name given to the links.

Viewing the http://www.bookmarks.html file in a text viewer such as Wordpad or an HTML editor is likewise possible. Firefox stores bookmarked sites in the following format:

<A HREF="http://siteURL.com" ADD_DATE="###" LAST_VISIT="###"
LAST_MODIFIED="###" ID="Firefox generated ">Site Name</A><DD>Site
Description

The listed dates are in Unix time (the number of seconds since 1/1/1970). The actual sites are sorted by directory, and if a particular datapoint is not available (for example, the bookmark was never modified), it will not be shown. ADD_DATE is the time the entry was bookmarked, the LAST_VISIT date is the time Firefox was used to visit the bookmark last (by clicking on the bookmark), and LAST_MODIFIED is the time the bookmark was last changed. Site Name is the name given to the bookmark that is displayed in the menu. Site Description is the longer text describing details about the site. Site Name is taken from the TITLE tag by default, and Site Description left blank. Here is a sample entry taken from a visit to IP address 10.60.216.128:

<A HREF="http://10.60.216.128" ADD_DATE="1106687067"
LAST_MODIFIED="1106687083" ID="rdf:#$CujRC2">My Homepage</A>

The most effective way to view the bookmarks file is using a clean version of Firefox. Select Manage Bookmarks File Import and import the http://www.bookmarks.html file onto the machine. The bookmarks will be displayed in a hierarchical fashion. Next, select View Show Columns and add the three date columns . The resultant display, shown in Figure 12-8, has the advantage of both visual representation and completeness of information from both of the preceding options.

Figure 12-8: http://www.bookmarks.html in Bookmark Manager

History

As with bookmarks, history information from Firefox is stored in a plaintext file titled history.dat. By default, the history.dat file contains the previous nine days history information, including the sites visited, what was typed, and the time visited. Although the file is viewable with an ASCII viewer, it suffers from the same issues as the http://www.bookmarks.html file. It is not easily interpretable by direct viewing. Fortunately, NetAnalysis parses these files in a similar fashion to Internet Explorer History files. An example of a history.dat file viewed with NetAnalysis is shown in Figure 12-9.

Figure 12-9: The history.dat file viewed with NetAnalysis

Unlike Internet Explorer, Firefox indicates whether the URL was typed into the address bar or clicked in the Typed field. Also, the dates noted are not in the local computer format. The date format is DD/MM/YYYY and the time format is UTC.

Cache

A local version of all files accessed by Firefox is created to speed up the browsing process. The cache content is located in the Cache subdirectory under the Firefox profile, in a series of binary files. The cache files contain not only the contents of HTML, image, and other files but also the specific HTTP headers that were part of the initial request. As such, the exact time of a particular request can be obtained. An additional field stored the number of fetches to the cache, useful in showing repeated visits.

The cache files are not easily viewable (although text searches and scripts that carve out image files can be run against them), but Firefox includes a builtin viewing capability. To view the scripts in a forensics case:

1. Install Firefox on the analysis machine.

2. Delete the Cache directory.

3. Copy the contents of the Cache directory on the suspect's machine to the analysis machine's Cache directory.

4. Disconnect the analysis machine from the network.

5. Open Firefox on the analysis machine and type about:cache in the address bar.

The built-in viewer will show all of the cache entries, along with their creation time and modified times. Clicking an entry will reveal the HTTP headers associated with it, and a link to the entry itself. Figure 12-10 shows an example of a cache file viewed in Firefox.

Figure 12-10: Firefox disk cache

Cookies

Firefox stores persistent cookies in a single file instead of discrete files. This has one primary advantage for the examiner: the consolidation of information. When reviewing cookies, individual files do not need to be accessed or searched, and the cookies file can be copied to another machine.

Cookies in Firefox are stored in the ASCII file cookies.txt. Because the file is ASCII, it can be viewed directly by a standard text editor. Also, like cache files, cookie files can be transported to an analysis machine for viewing in Firefox. To view cookies this way:

1. Install Firefox on the analysis machine.

2. Delete the cookies.txt file.

3. Copy the cookies.txt file from the suspect's machine to the analysis machine's Firefox profile directory.

4. Disconnect the analysis machine from the network.

5. Open Firefox on the analysis machine and select Tools Options from the menu bar.

6. Select the Privacy icon, and then expand the Cookies section and click View Cookies.

Using the Cookie Manager decodes the appropriate cookie fields and allows the examiner to view individual cookie contents. In the example shown in Figure 12-11, the contents of a MapQuest cookie reveal the location typed by the suspect.

Figure 12-11: Cookie contents

Passwords

Firefox allows users to store passwords for a given site in an encrypted fashion in a file titled signons.txt. The encryption for signons.txt is by default based on keys included in the file key3.db. By copying both of these files to the Firefox directory on the analysis machine, the investigator will be able to read the user names and passwords from the suspect's system. To read the passwords:

1. Install Firefox on the analysis machine.

2. Delete the signons.txt file (if present) and the key3.db file.

3. Copy the key3.db and signons.txt files from the suspect's machine to the analysis machine's Firefox profile directory.

4. Disconnect the analysis machine from the network.

5. Open Firefox on the analysis machine and select Tools Options from the menu bar.

6. Select the Privacy icon, and then expand the Saved Passwords section and click View Saved Passwords.

7. Click the Show Passwords button to view the passwords.

   The passwords will be automatically decrypted and shown in plaintext.

   Note	Firefox also has a feature that further encrypts the file using a master password supplied every session by the user, creating a vault technology. Keystroke logging or similar techniques may be required to obtain the master password if that feature is used. It generally is not.

Downloads

Downloads in Firefox are managed by the Download Manager. The file prefs.js contains the location of the folder where downloads are saved under the key browser.download.defaultFolder. By default, any programs downloaded will be copied to that directory.

The download data is stored in the downloads.rdf file in plaintext format. Included are the date and time of the download, the download state (one if successful), the location of the saved file, and the original location from which it was downloaded. The downloads.rdf file can be copied to the analysis machine to view download info through the Download Manager (Tools Downloads), but for this particular scenario viewing the file directly with Wordpad provides easier access to the details. A sample entry for a download of the tool Filemon from Sysinternals is as follows:

<RDF:Description
RDF:about="D:\DOCUME~1\CHADMS~1.STE\LOCALS~1\TEMP\NTFILMON.ZIP"
                   NC:Name="NTFILMON.ZIP"
                   NC:Transferred="92KB of 92KB">
    <NC:URL
RDF:resource="http://www.sysinternals.com/files/NTFILMON.ZIP"/>
    <NC:File
RDF:resource="D:\DOCUME~1\CHADMS~1.STE\LOCALS~1\TEMP\NTFILMON.ZIP"/>
    <NC:DateStarted NC:parseType="Date">Thu Mar 31 12:34:06 Eastern
Standard Time 2005 +482032</NC:DateStarted>
    >NC:DateEnded NC:parseType="Date">Thu Mar 31 12:34:06 Eastern
Standard Time 2005 +502060</NC:DateEnded>
    <NC:DownloadState NC:parseType="Integer">1</NC:DownloadState>
    <NC:ProgressPercent NC:parseType="Integer">100</NC:ProgressPercent>
    </RDF:Description>

Toolbar History

Toolbars are growing in popularity for their ability to block pop-ups and enhance searching functionality. These toolbars can store search history, and do so in the registry. The Google toolbar stores the search results history at HKCU\Software\Google\NavClient\1.1\History.

Network, Proxy, and DNS History

Depending on the configuration of the network, log files may not all be stored on the local computer. Many companies use proxying, and relevant logs may be available from the proxy servers. Additionally, Cisco Netflow logs (or their equivalent from other manufacturers) may be available from the network routers. Finally, every web request that has a hostname requires a DNS lookup. If DNS logging is enabled this may provide further sources of information on web activity. The analysis of network activity is a complex topic and beyond the scope of this book. Check out the general forensics books mentioned in the individual chapter resources for further information.