Web Browser Forensics, Part 2
by Keith J. Jones, Rohyt Belani
Reviewing part one
Welcome to part two of the Web Browser Forensics series. In part one, we began investigating the intrusion of the Docustodian document management server hosting a law firm's data. The server appeared to have been compromised by a group of hackers who were using it as a repository for their MP3s, MPEGs, and pirated software.
In part one, we also performed a review of the Internet Explorer history and cached files on the system used by Joe Schmo, the primary suspect of the intrusion. Analysis of the web browsing history revealed Internet searches for license cracks and hacking books; however, all this malicious activity appeared to have been performed while Joe was on vacation with his family in Florida.
In part two we now set out to determine who used Joe's machine while he was on vacation. We will proceed by examining further investigative leads that involve performing an in-depth review of the web activity of all other browsers installed on Joe's hard drive.
Further investigation of Joe's system revealed that the only other web browser installed was Mozilla Firefox. Viewing Firefox cached files is not as straightforward as viewing IE cached files, simply because there is a lack of tools that provide an easy way to reconstruct the cache files. As we discussed in the last article, most tools like FTK, IE History, and Web Historian, are able to reconstruct the history files for Mozilla based web browsers, but they do not associate the locally cached content to the web activity. This implies that we have the dates and times of web browsing activity, but cannot view the actual content of that activity, yet.
Let's begin the investigation by reviewing the Firefox cache on Joe Schmo's system. The directory is located at the following path:
There are three types of files in this directory:
We will examine each of these files in order to reconstruct Firefox's cached data.
Cache Map file
The Cache Map file is named "_CACHE_MAP_" and is the main file used to reconstruct Firefox's cached activity. The Cache Map file has a very basic structure. There is a header for the file followed by "buckets" which contain the mapping information to the cached data, as illustrated in Figure 2.
There are 32 buckets in this file. Within each bucket, there are 256 records inside each bucket. That means we have 8,192 records in the Cache Map file.
Each record contains the information for one instance of cache data. A record contains four 32-bit integers:
There are two methods Firefox uses to save the cache data. Firefox either saves the information inside a Cache Block File or creates a separate file. The hash number is used to name the separate file if that is how a specific cache instance was saved. The other two fields we will use to reconstruct the cache data are the "data location" and the "metadata location." Each instance of cache data has metadata information and the cache content.
If you take the "metadata location" field and "bitwise AND" it with 0x30000000 and then left shift the result 28 bits, you will have a number between zero and three. If the result is a zero, the cache metadata is saved in a separate file. If the result is one, two, or three, the cache metadata is embedded in a cache block file. The same algorithm using the data location as the input will identify similar information for the cache content.
Cache Block files
There are three cache block files named "_CACHE_00N_," where "N" is a number from one to three. Cache block files contain cache content and metadata information for each instance of cache activity. This structure of the cache block files presents a problem for most computer forensic tools attempting to reconstruct cache content during an investigation. However, we are aware of this structure and will extract the data in order to continue our investigation.
After the Cache Block File has been identified using the methodology presented above, we only need to know where the data is located in which appropriate Cache Block File. The start block is calculated by "bitwise ANDing" the metadata location/data location with 0x00FFFFFF. Next, we must calculate the number of contiguous blocks comprising the cache metadata/data. The size is calculated by "bitwise ANDing" the metadata location/data location with 0x03000000 and right shifting the result 24 bits. Now, we need to know how large the blocks are for a particular cache block file. Mozilla browsers define the block size by left shifting the number 256 by the following number of bits: subtract one from the cache block file number and then multiply the result by two. Therefore, when N=1 the block size is 256 bytes. When N=2, the block size is 512 bytes. When N=3, the block size is 1,024 bytes.
Lastly, we have to account for a bitmap header in the cache block file. The bitmap header is defined as 4,096 bytes long. The blocks in the cache block files begin immediately after the bitmap header. Using the algorithms presented above, we are able to extract the metadata and cache content for each record found in the cache map file.
Separate Cache Data files
If the cache content or metadata is too large to be embedded in the Cache Block files, the information is saved into a separate Cache Data file. The file names are identified by the following format:
<HASH NUMBER><TYPE><GENERATION NUMBER>
The hash number is available from the Cache Map file. The "Type" is either 'd', for cache content, or 'm' for cache metadata. The "Generation Number" is an integer that is identified by "bitwise ANDing" the metadata location/data location with 0x000000FF.
Reconstructing the Cache Data
The one tool that facilitates Firefox cache reconstruction is Cache View. Cache View, a shareware tool, provides access to the cached files of several types of browsers, including Firefox. For each cached page, Cache View provides the URL from which the page was retrieved, the name of the cached file as stored on the local system, the file size, file type, the time it was last modified, the download date and its expiry (if applicable). This information is the cache metadata that we discussed earlier. An example is shown below in Figure 3.
By default, Cache View presents the files from the browser caches of the system on which it is running. In our case, as is the case with most forensics investigations, all investigative activity is performed on a forensics workstation, which is separate from the actual evidence media. Thus, we need to import the cached files of the browsers from a copy of the evidence medium onto the forensics workstation. In the case of Firefox, it means importing the following folder:
Once the folder is stored at a known location on the forensics workstation, Cache View can be instructed to retrieve files from it, rather than the browser caches of the forensics workstation. This is shown below in Figure 4.
Figure 4: Pointing Cache View to a copy of the Firefox cache folder of the evidence medium, that is resident on the forensic workstation.
A zipped version of the Firefox Cache folder from Joe Schmo's system, used for example purposes in this article, can be downloaded from this link.
After importing the cache folder into Cache View you should be presented with a view similar to that shown in Figure 5, below.
As seen in Figure 5, the files are categorized by the domain names from which they were retrieved. By clicking the
So who is Ted Wilson and how did he gain access to Joe Schmo's system? Conversations with personnel at the law firm indicated that Ted was the intern employed to cover for Joe Schmo when he was on vacation.
The last nail in the coffin
If the extracted Hotmail message wasn't evidence enough, perusal of the evidence media revealed a file called
This file presented a last access time stamp of 07:32PM on March 11, 2005. An excerpt from
A brief review of the file shown above provides further incriminating evidence against Ted Wilson. The comments preceding the actual logic indicate the author of the program and provide insight into the malicious intent of the code. A detailed review of the source code indicated that the Docustodian licensing service was susceptible to a replay attack. Every time a new instance of a licensed client was executed, the Docustodian client and the licensing server exchanged the same set of six packets. Further, the Docustodian client, rather than the licensing server, provided final approval on the legitimacy of the connection. The suspect took advantage of this fact by tricking the Docustodian client into believing that
This second article in the two-part series described tools and techniques to reconstruct files cached by Mozilla Firefox browsers. It is important to note that by merely visiting Joe's cache directory, we would have missed a number of important cache files that were embedded in Cache Block Files. Not even a simple keyword search would have identified the email message presented in Figure 9 because it was compressed inside the block file. Using a tool such as Cache View, we were able to reconstruct the relevant cache information from Mozilla Firefox.
All of the evidence examined in this two part series existed in web history and cache files. By simply examining the evidence associated with web browser caches, we were able to solve the mystery of unauthorized access to the Docustodian server.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.