Fast innovation cycles make securing a system against all vulnerabilities virtually impossible. If an attack succeeds, taking certain steps can at least uncover the actions of the criminals to preserve evidence or to harden the system against repeat attacks.

To investigate how a postmortem analysis proceeds (see the "IT Forensics" box), we'll look at the following sample scenario: On his lunch break, an office clerk uses his colleague's computer, without the consent of his neighbor, to order several books under this neighbor's Amazon account and at his neighbor's expense. To conceal his actions, the attacker then shuts down the computer. How could you prove this crime took place?

On the basis of this scenario, researchers mutually define general and scenario-specific requirements for a collection of forensic tools [2] that allow them to compare the relevant toolkits.

The general requirements for a tool collection include search and filter functions for restricting the relevant data. Additionally, the forensics tools need to provide a way to combine data, thereby allowing processes to be reproduced and relationships between different data sources identified. Other requirements relate to input and output logging and the ability to integrate different image file types.

The scenario-specific requirements include support for finding and processing browser artifacts or undesirable changes to the underlying services or their configurations. The browser and its external components could be infected by malware; for example, the attacker could have changed the network configuration so that the user was unintentionally working with a manipulated name server.

Forensic Investigation

In a professional forensic investigation, investigators base their approach on models. In this article, we use the Secure-Analysis-Present model (see the "SAP Model" box).

We examined the victim system to reconstruct the browser session with the forensic tool collections under comparison here. In the Secure Phase, we first backed up the hard disk using the dcfldd tool, a version of the GNU dd tools, extended to include forensic features. Integrity was ensured by a hash function generated by md5deep. (However, assuring integrity was not the focus of the investigation. In production use, an investigator would typically give preference to SHA.)

The analysis was performed on a forensic workstation in a virtualized environment (VMware vSphere ESXi). Only active open source projects were compared that are suitable for postmortem analysis of a Windows 7 system. Furthermore, tool selection was based on the popularity of the tool collections (Table 1). The investigators also considered the extent to which the default installations of tool collections were suitable for the given scenario. For better comparison, no additional packages were installed retroactively. Instead of looking at all the tools in Table 1, we focused on OSForensics, Autopsy, and CAINE, which all stood out positively.

OSForensics

OSForensics [3] is a Windows tool by PassMark Software for live forensics and postmortem analysis. For this comparison, we looked at version 1.2 (build 1003); version 2.0 has been released in the meantime (build 1003). Forensic duplication is implemented as an additional virtual disk in read-only mode.

Data can be filtered by keyword, time stamp, last activities, registry keys, and access credentials stored in the browser. Internally, the tool offers file, hex, string, and text views. However, files can also be viewed using external programs and linked.

After the investigation, a case report can be generated with case/investigator names, exported files, attachments, notes, email, and links with or without JavaScript as a .html file. Also, a template is available for logging the chain of forensic evidence.

OSForensics returned various scenario-specific results: The keyword search for the victim's email address (Figure 1) led to F:\Users\Sandy\AppData\Local\Microsoft\Windows\TemporaryInternetFiles\Low\Content.IE5\BYO5TPM7\display[1].html. Opening this link in IE takes the investigator to the Amazon purchase confirmation. The keyword search for the title of the purchased book led to victimsystem:\Users\Sandy\AppData\Local\Microsoft\Windows\TemporaryInternetFiles\Low\Content.IE5\S6OU8I07\view-upsell[1].html, which is the Amazon shopping cart.

Figure 1: Results of the search for the victim's email address (OSForensics).

The Images category returned results from the temporary Internet files shown in Figure 2, which match the purchased product. The registry entry under Software\Microsoft\InternetExplorer\TypedURLs contains the last URL entries from the IE address bar (Figure 3). We were able to view login actions without access credentials using the Website Passwords module, because the user did not save the credentials in the browser.

Figure 2: Pictures of the purchased item in the cache (OSForensics).

Figure 3: Registry entries (OSForensics).

The ability to identify registry files automatically is an asset to the forensic investigation. Nevertheless, expertise is needed, and a manual search for data by the forensic investigator is essential.

Autopsy

Autopsy [4] is a graphical extension of The Sleuth Kit (TSK), which was developed by Brian Carrier for Windows and Linux systems. We investigated Windows version 3.0.3; version 3.0.6 is now available.

Forensic duplication again was performed in read-only mode as an additional (virtual) disk. For case management, you can enter a name, the storage directory, a case number, and the investigator's name. Data can be managed by keyword search, matching with hash databases, viewing file residues and unallocated files, automatic filtering by file type (images, video, audio, documents), categories (bookmarks, cookies, browsing history, downloads, etc.), most recently used data, and email messages. Files can be opened in external programs or viewed internally in hex, string, result, text, and media views. Another useful function is the ability to link relevant files and add a comment for the link.

Investigators can create a final report as a .html file, an Excel spreadsheet, or a body file with a case summary, image information, and links including file names, file paths, and comments.

Autopsy returned the following scenario-specific results: The IE history was retrieved from F:\Users\Sandy\AppData\Local\Microsoft\Windows\TemporaryInternetFiles\Low\Content.IE5\index.dat and listed (Figure 4). Additionally, three cookies were found for the Amazon domain; we were able to view their contents in text form. After manual inspection of a recovered file, the keyword search for the victim's email address led to access data entered in a failed login attempt in plain text.

Figure 4: Excerpt from the history evaluation (Autopsy).

Opening the history file, F:\Users\Sandy\AppData\Local\Microsoft\Windows\TemporaryInternetFiles\Low\Content.IE5\BYO5TPM7\display[1].html, with IE showed a section from the Amazon shopping cart. The file F:\Users\Sandy\AppData\Local\Microsoft\Windows\TemporaryInternetFiles\Low\Content.IE5\BYO5TPM7\continue.html included the delivery address and the last two digits of the victim's account number; we were unable to open it with IE.

Autopsy also requires the forensic investigator to know where the data sources are located. Moreover, in this case, a manual review of potentially relevant files is essential.