Chapter 2. Forensic Analysis
Eoghan Casey and Curtis W. Rose

Contents

Introduction21
Applying the Scientific Method to Digital Forensics23
Uses of Digital Forensic Analysis26
Data Gathering and Observation32
Hypothesis Formation48
Evaluating Hypotheses48
Conclusions and Reporting56
Summary61
References62

Introduction

The information stored and created on computers is a double-edged sword from a forensic perspective, providing compelling evidence in a wide variety of investigations but also introducing complexity that can trip up even experienced practitioners. Digital evidence can be used to answer fundamental questions relating to a crime, including what happened when (sequencing), who interacted with whom (linkage), the origination of a particular item (evaluation of source), and who was responsible (attribution). At the same time, the complexity of computer systems requires appreciation that individual pieces of digital evidence may have multiple interpretations, and corroborating information may be vital to reaching a correct conclusion. To make the most of digital evidence, forensic practitioners need to understand, and make regular use of, the scientific method. The scientific method applied in conjunction with digital forensics methodologies and techniques enables us to adapt to differing circumstances and requirements, and to ensure that conclusions reached are solidly based in fact. Familiarity with the limitations of forensic analysis of digital evidence will help investigators and attorneys apprehend modern criminals and exculpate the innocent.
The forensic analysis process involves taking factual observations from available evidence, forming and testing possible explanations for what caused the evidence, and ultimately developing deeper understanding of a particular item of evidence or the crime as a whole. Put another way, elements of digital forensic analysis include separating particular items for individual study, determining their significance, and considering how they relate to the entire corpus of evidence. This process often involves experimentation and research, and may lead to additional information that must be synthesized into the overall process. For instance, analysis can suggest additional keywords that forensic practitioners use to find additional information that adds to the analysis process. As such, the process is cyclic, requiring multiple passes through the hypothesis formation and testing phases until a solid conclusion is reached.
In the simple case of an incriminating file on a hard drive, analysis of the contents and metadata of the file can reveal how the file came to be on the hard drive and can uncover distinctive characteristics to search all available media for related artifacts and file fragments. As another example, forensic analysis of SMS messages on a murder victim's mobile device may lead digital investigators to a prime suspect. Then, by obtaining usage details for the suspect's cell phone and analyzing the timing, location, and content of both the victim's and suspect's mobile devices immediately prior to the offense, digital investigators can place the suspect at the crime scene.
From the Case Files: Cell Phone Evidence
In late December 2005, 27-year-old Josie Phyllis Brown was reported missing in Baltimore. Digital evidence led investigators to a 22-year-old college student John Gaumer. Brown and Gaumer met on the Internet site MySpace.com, and arranged to meet for a date. On the night of her disappearance, Brown's mobile telephone records showed that she had talked to Gaumer before meeting with him, and police placed her telephone many miles from where he claimed to have left her that night. After the web of evidence converged on Gaumer in February 2006, he led police to her body and admitted to beating Brown to death after their date. Gaumer used the Internet extensively to communicate and meet potential dates. Part of the evidence against him was a digital recording of “thumping noises, shouting and brief bursts of a woman's muffled screams” apparently created when Gaumer's mobile phone inadvertently dialed Brown's. In his confession to police, Gaumer stated that he removed her nose, jaw, teeth, and most of her fingertips in an attempt to thwart identification of her body, and that he later sent an e-mail to her account to make it appear that he did not know she was dead (McMenamin, 2007).
More generally, forensic analysis involves objectively and critically assessing digital evidence to gain an understanding of and reach conclusions about the crime. This process can involve evaluating the source of digital objects, exploring unfamiliar file formats to extract usable information, developing timelines to identify sequences and patterns in time of events, performing functional analysis to ascertain what was possible and impossible, and relational analysis to determine the relationships and interaction between components of a crime. In essence, forensic analysts attempt to answer the fundamental questions in an investigation of what happened, where, when, how, who was involved, and why. In addition, forensic analysts may be directed to address specific questions relevant to the investigation, or to develop a list of other potential sources of evidence like e-mail accounts and removable storage media.
Practitioner's Tip: Thinking Outside the Box
Although forensic protocols can help provide a standardized process, and keyword searches can help focus on important items and minimize the dataset, many digital investigations will require the forensic practitioner to explore the cybertrail, apply the scientific method, seek peer review, reach a conclusion, express an opinion, and prepare for expert testimony and presentation in a court of law. New versions of operating systems, software applications, and hardware platforms are constantly being released, including new generations of mobile devices. As such, it is clear that digital forensics is an ongoing and evolving scientific discipline. Procedures and protocols are not intended to limit a forensic analyst, but rather act as guidelines to help ensure consistency. Forensic analysts may detect and pursue something of relevance that even the most comprehensive protocol may not have anticipated.
This chapter focuses on important aspects of analyzing digital evidence to help investigators reconstruct an offense and assess the strength of their conclusions. By focusing on the use of digital evidence to reconstruct actions taken in furtherance of a crime, this chapter demonstrates how digital evidence that is properly interpreted can be used to apprehend offenders, gain insight into their intent, assess alibis and statements, authenticate documents, and much more. It is assumed that evidence has been preserved in a forensically sound manner. For background and technical coverage of how forensic science is applied to computers and networks, see Casey (2004).
A fictional digital forensic investigation scenario is used throughout this chapter to demonstrate key points. The scenario background is as follows.
Investigative Scenario

Part 1: Background
A suspected domestic terrorist code named “Roman” was observed purchasing explosive materials and investigators believe that he is involved in planning an attack in Baltimore, Maryland. We have been asked to perform a forensic analysis of his laptop to determine the target of the attack and information that may lead to the identification of others involved in the terrorist plot. This is purely a fictional case scenario developed for instructional purposes.

Applying the Scientific Method to Digital Forensics

Forensic analysis of digital evidence depends on the case context and largely relies on the knowledge, experience, expertise, thoroughness, and in some cases the curiosity of the practitioner performing the work. Although every forensic analysis will have differing aspects based on the dataset, objectives, resources, and other factors, the underlying process remains fundamentally the same.
1. Gather information and make observations. This phase is sometime referred to as forensic examination, and involves verifying the integrity and authenticity of the evidence, performing a survey of all evidence to determine how to proceed most effectively, and doing some preprocessing to salvage deleted data, handle special files, filter out irrelevant data, and extract embedded metadata. This phase may include keyword searching to focus on certain items, and a preliminary review of system configuration and usage. This phase need not be limited to digital evidence, and can be augmented by interviews, witness statements, and other materials or intelligence.
2. Form a hypothesis to explain observations. While forensic practitioners are gathering information about the crime under investigation, we develop possible explanations for what we are seeing in the digital evidence. Although such conjecture is often influenced by the knowledge and experience of a forensic practitioner, we must guard against preconceived notions that are based on personal prejudice rather than facts.
3. Evaluate the hypothesis. Various predictions will flow naturally from any hypothesis (if the hypothesis is true, then we would expect to find X in the evidence), and it is our job as forensic practitioners to determine whether such expectations are borne out by the evidence. The success of a forensic analysis hinges on how thoroughly an initial hypothesis is attacked. Therefore, it is crucial to consider other plausible explanations and include tests that attempt to disprove the hypothesis (if the hypothesis is false, then we would expect to find Y). If experiments and observations do not support the initial hypothesis, we revise our hypothesis and perform further tests.
4. Draw conclusions and communicate findings. Once a likely explanation of events relating to a crime has been established, forensic practitioners must convey their work to decision makers.
Observe that the scientific method is cyclic, potentially requiring forensic analysts to repeat these steps until a conclusion can be made. If experiments disprove the initial hypothesis, a new one must be formed and evaluated. Even when some experiments support the hypothesis, new information often emerges that must be considered and tested to determine whether the hypothesis still holds.
Scientific Method
There are variations in how the scientific method is described but the overall principles and goals are the same: to reach an objective conclusion in a repeatable manner. The terminology used in this book is not intended to be definitive or exclusive, and is provided simply to demonstrate how the scientific method is applied to digital forensic analysis.
The scientific method provides the final bulwark against incorrect conclusions. Simply trying to validate a theory increases the chance of error—the tendency is for the analysis to be skewed in favor of the hypothesis. This is why the most effective investigators suppress their personal biases and hunches, and seek evidence and perform experiments to disprove their working theory. Experimentation is actually a natural part of analyzing digital evidence. Given the variety and complexity of hardware and software, it is not feasible for a forensic analyst to know everything about every software and hardware configuration. As a result it is often necessary to perform controlled experiments to learn more about a given computer system or program. For instance, one approach is to pose the questions, “Was it possible to perform a given action using the subject computer, and if so, what evidence of this action is left behind on the system?” Suppositions about what digital evidence reveals in a particular case may be tested by restoring a duplicate copy of a subject system onto similar hardware, effectively creating a clone that can be operated to study the effects of various actions. Similarly, it may be necessary to perform experiments on a certain computer program to distinguish between actions that are automated by the program versus those performed by a user action.
Practitioner's Tip: Documentation, Documentation, Documentation
Documentation is a critical part of each step—note every action you take and any changes that result from your actions. The aim is not only to give others an understanding of what occurred but also to enable others to reproduce your results. In cases involving a large number of computers, it is common practice to develop a review protocol for multiple forensic practitioners to follow. This type of protocol describes the sequence of steps each individual should perform and what output is expected, thus increasing the chances that consistent results will be obtained from all systems. Maintaining a record of your work and findings also helps avoid the unenviable position of remembering that you found something interesting but not being able to find it again. Therefore, during the forensic analysis process, it is advisable to extract key findings and organize these items in a folder (either digital or physical) to make it easier to reference them when reviewing the case, writing a report, or testifying in court.
Keep in mind that there is uncertainty in all observations, and every opinion rendered by a forensic practitioner has a statistical basis. Although the scientific method is designed to uncover the truth, we generally have only a limited amount of information about what occurred at a digital crime scene. Therefore, it is important that forensic practitioners qualify the results of their analysis to clearly convey what level of confidence we have in a certain conclusion. The C-Scale (Certainty Scale) provides a method for conveying certainty when referring to digital evidence and to qualify conclusions appropriately (Casey, 2002). Some forensic practitioners use a less formal system of degrees of likelihood that can be used in both the affirmative and negative sense: (1) almost definitely, (2) most probably, (3) probably, (4) very possibly, and (5) possibly.

Tool Validation

One of the critical elements of the entire forensic analysis process hinges on practitioners’ knowledge of the capabilities, limitations, and restrictions of their tools.
It is not feasible to calibrate digital forensic tools in the same way as equipment for analyzing DNA and other scientific evidence, because there are too many variables; each case has different data structures to interpret and unique problems to solve. The next best option is to test tools using a known data set to ensure that they can perform basic functions correctly like read partition tables and files systems, recover deleted files, and find keywords. The Computer Forensic Tool Testing group at the National Institute of Standards and Technology (www.cftt.nist.gov/) is conducting thorough tests of certain features of major forensic tools. However, there are more tools and capabilities than any one group can test, and forensic analysts generally are advised to perform some validation themselves of the specific tools and features on which they rely in their work.
The Digital (Computer) Forensics Tool Testing images project (http://dftt.sourceforge.net/) provides a limited test set for this purpose, and the Computer Forensic Reference Data Sets project (www.cfreds.nist.gov/) has forensic images that can be useful for tool testing. In addition to validating the basic functionality of forensic tools, some organizations develop their own test data with features that they commonly encounter in cases like Microsoft Office documents, Lotus Notes and Outlook e-mail, unsearchable PDF files, and foreign language characters. In special cases, it may be necessary to create a particular exemplar file containing known data, and check to see that the tool interprets and displays the information of interest correctly.
Even after performing a basic validation of a particular tool, experienced forensic analysts take a “trust but verify” approach to important findings. In some circumstances the validation process may be as straightforward as viewing data in a hex viewer, and in other situations it may be necessary to repeat the analysis using another forensic tool to ensure the same results are obtained. Most C programmers do not have one single book on their shelf as a reference guide. If they specialize in C programming, over time they have probably amassed a small reference library of books covering various aspects of the language. No single book covers every possible aspect of the C programming language; similarly, no single digital forensic utility provides the capabilities of performing every possible element of an analysis. Reliance on a single application platform will significantly hinder the review and subsequent analysis of digital evidence.

Uses of Digital Forensic Analysis

Forensic analysis of digital evidence can play a significant role in a wide range of cases, in some cases leading investigators to the culprit. Some examples of this and other uses of digital forensics are provided here as context for the technical materials in this chapter and book as a whole.

Attribution

Digital forensic analysis can play a direct role in identifying and apprehending offenders, helping investigators establish linkages between people and their online activities. In the Bind Torture Kill (BTK) serial killer case, forensic analysis of a floppy diskette that was sent to a television station by the offender led investigators to the church where Dennis Rader was council president. However, attributing computer activities to a particular individual can be challenging. For instance, logs showing that a particular Internet account was used to commit a crime do not prove that the owner of that account was responsible since someone else could have used the individual's account. Even when dealing with a specific computer and a known suspect, some investigative and forensic steps may be required to place the person at the keyboard and confirm that the activities on the computer were most likely those of the suspect. For instance, personal communications and access to online banking/ e-commerce accounts can make it difficult for the person to deny responsibility for the illegal activities on the computer around the same time. Alternate sources of information like credit card purchase records, key card access logs, or CCTV footage may confirm the person in the vicinity during the time in question. When combined with traditional investigative techniques, digital evidence can provide the necessary clues to track down criminals.
From the Case Files: Apprehending a Serial Killer
A lead developed during a serial homicide investigation in St. Louis when a reporter received a paper letter from the killer. The letter contained a map of a specific area with a handwritten X to indicate where another body could be found. After investigators found a skeleton in that area, they inspected the letter more closely for ways to link it to the killer. The FBI determined that the map in the letter was from Expedia.com and immediately contacted administrators of the site to determine if there was any useful digital evidence. The web server logs on Expedia.com showed only one IP address (65.227.106.78) had accessed the map around May 21, the date the letter was postmarked. The ISP responsible for this IP address was able to provide the account information and telephone number that had been used to make the connection in question. Both the dialup account and telephone number used to make this connection belonged to Maury Travis (Robinson, 2002).
In short, the act of downloading the online map that was included in the letter left traces on the Expedia web server, on Travis's ISP, and on his personal computer. Investigators arrested Travis and found incriminating evidence in his home, including a torture chamber and a videotape of himself torturing and raping a number of women, and apparently strangling one victim. Travis committed suicide while in custody and the full extent of his crimes may never be known.
Using evidence from multiple independent sources to corroborate each other and develop an accurate picture of events can help develop a strong association between an individual and computer activities. This type of reconstruction can involve traditional investigative techniques, such as stakeouts.
From the Case Files: Physical and Digital Surveillance
A man accused of possessing child pornography argued that all evidence found in his home should be suppressed because investigators had not provided sufficient probable cause in their search warrant to conclude that it was in fact he, and not an imposter, who was using his Internet account to traffic in child pornography (U.S. v. Grant, 2000). During their investigation into an online child exploitation group, investigators determined that one member of the group had connected to the Internet using a dialup account registered to Grant. Upon further investigation, they found that Grant also had a high-speed Internet connection from his home that was used as an FTP server—the type of file-transfer server required for membership in the child exploitation group.
Coincidentally, while tapping a telephone not associated with Grant in relation to another child pornography case, investigators observed that one of the participants in a secret online chat room was connected via Grant's dialup account. Contemporaneous surveillance of the defendant's home revealed that his and his wife's cars were both parked outside their residence at the time. The court felt that there was enough corroborating evidence to establish a solid circumstantial connection between the defendant and the crime to support probable cause for the search warrant.
Attributing a crime to an individual becomes even more difficult when a crime is committed via an open wireless access point or from a publicly accessible computer, such as at an Internet cafe or public library terminal. In one extortion case, investigators followed the main suspects and observed one of them use a library computer from which incriminating e-mails had been sent (Howell, 2004; Khamsi, 2005).

Assessing Alibis and Statements

Offenders and victims may mislead investigators intentionally or inadvertently, claiming that something occurred or that they were somewhere at a particular time. By cross-referencing such information with the digital traces left behind by a person's activities, digital evidence may be found to support or refute a statement or alibi. In one homicide investigation, the prime suspect claimed that he was out of town at the time of the crime. Although his computer suffered from a Y2K bug that rendered most of the date-time stamps on his computer useless, e-mail messages sent and received by the suspect showed that he was at home when the murder occurred, contrary to his original statement. Caught in a lie, the suspect admitted to the crime.
From the Case Files: Cell Phone Location
Data relating to mobile telephones were instrumental in the conviction of Ian Huntley for the murder of Holly Wells and Jessica Chapman in the United Kingdom. The last communication from Jessica's mobile phone was sent to a cell tower several miles away in Burwell rather than a local tower in Soham (BBC, 2003). The police provided the mobile telephone specialist with a map of the route they thought the girls would have taken, and the specialist determined that the only place on that route where the phone could have connected to the cell tower in Burwell was from inside or just outside Huntley's house (Summers, 2003). In addition, Huntley's alibi was that he was with his friend Maxine Carr on the night the girls went missing but Carr's mobile phone records indicated that she was out of town at the time.
Investigators should not rely on one piece of digital evidence when examining an alibi—they should look for an associated cybertrail. On many computers it requires minimal skills to change the clock or the creation time of a file. Also, people can program a computer to perform an action, like sending an e-mail message, at a specific time. In many cases, scheduling events does not require any programming skill—it is a simple feature of the operating system. Similarly, IP addresses can be changed and concealed, allowing individuals to pretend that they are connected to a network from another location. In addition, the location information associated with mobile telephones is not exact and does not place an individual at a specific place. As noted earlier, it can also be difficult to prove who was using the mobile telephone at a specific time, particularly when telephones or SIM cards are shared among members of a group or family.

Determining Intent

An individual's computer use can reveal innermost thoughts at a particular moment in time. Clear evidence of intent such as an offender's diary or planning of an offense may be found on a computer.
From the Case File: United States v. Duncan
Joseph Edward Duncan III pled guilty in December 2007 to 10 federal counts including murder, torture, and kidnapping. During a forensic review of his laptop, a forensic analyst identified what initially appeared to be an unused tab "Sheet 2" in an encrypted Excel spreadsheet named Book1.xls. Further analysis revealed the contents of this spreadsheet, which showed a mathematically weighted decision matrix that Duncan had generated to calculate the risks associated with taking certain actions relating to his crimes. During the capital sentencing hearing, this spreadsheet was introduced as Government Exhibit 59, and was used as the foundation for proving that the defendant acted with substantial planning and premeditation. In August 2008, Duncan was sentenced to death.
In three separate cases, Internet searches on suspects’ computers revealed their intent to commit murder:
▪ Neil Entwistle was sentence to life in prison for killing his wife and baby daughter. Internet history on his computer included a Google search “how to kill with a knife.”
▪ William Guthrie was convicted in 2000 and sentenced to life in prison for killing his wife, who was found drowned in a bathtub with a toxic level of the prescription drug Temazepam in her body. Guthrie lost multiple appeals to exclude Internet searches for “household accidents,” “bathtub accidents,” and various prescription drugs, including Temazepam.
▪ Prosecutors upgraded the charge against Robert Durall from second-degree to first-degree murder based on Internet searches found on his computer with key words including “kill + spouse,” “accidental + deaths,” “smothering,” and “murder” (Johnson, 2000).
Forensic analysis of computers can reveal other behavior that can be very useful for determining intent. For instance, evidence of clock tampering may enable a forensic practitioner to conclude that the computer owner intentionally backdated a digital document. As another example, the use of disk cleaning or encryption programs on a computer can be used to demonstrate a computer owner's conscious decision to destroy or conceal incriminating digital evidence. However, these same actions may have innocent explanations and must be considered in context before reaching a definitive conclusion.

Evaluation of Source

As introduced in the previous chapter, forensic analysts are commonly asked to provide some insight into the origins of a particular item of digital evidence. As detailed in Chapter 1, a piece of evidence may have been: 1) produced by the source; 2) a segment of the source; 3) altered by the source; 4) a point in space.
In addition to determining the origin of an e-mail message using IP addresses, different file formats have characteristics that may be associated with their source. As shown earlier, Microsoft Office documents contain embedded information, such as printer names, directory locations, names of authors, and creation/modification date-time stamps, that can be useful for determining their source.
Practitioner's Tip: Useful Characteristics of Evidence
A class characteristic is a general feature shared with similar items such as Kodak digital cameras that embed the make and model names in the photographs they take. An individual characteristic is a unique feature specific to a particular thing, place, person, or action. For example, a scratch on a camera lens that appears in photographs it takes, a distinct monument in the background of a photograph, or the defendant's face appearing in a photograph are all individual characteristics that may help investigators associate the photograph with its source—that is, a particular camera, location, or person.
Comparing an item of evidence to an exemplar can reveal investigatively useful class characteristics or even individual characteristics.
These embedded characteristics can be used to associate a piece of evidence with a specific computer. Earlier versions of Microsoft Office also embedded a unique identifier in files, called a Globally Unique Identifier (GUID), which can be used to identify the computer that was used to create a given document (Leach & Salz, 1998). More subtle evaluations of source involve the association of data fragments with a particular originating file, or determining if a given computer was used to alter a piece of evidence.
When a suspect's computer contains photographs relating to a crime, it may not be safe to assume that the suspect created those photographs. It is possible that the files were copied from another system or downloaded from the Internet. Forensic analysis of the photographs may be necessary to extract class characteristics that are consistent with the suspect's digital camera or flatbed scanner. The scanner may have a scratch or flaw that appears in the photographs, or the files may contain information that was embedded by the digital camera such as the make and model of the camera, and the date and time the photograph was taken. This embedded metadata could be used to demonstrate that a photograph was likely taken using a suspect's camera rather than downloaded from the Internet. This is particularly important during investigations involving child pornography because it is desirable to locate the original victims and protect them from further abuse. There is a body of research that concentrates on identifying the specific camera that was used to take a given photograph (Alles et al., 2009 and Kurosawa et al., 2009).

Digital Document Authentication

The author of a document and the date it was created can be significant. It is relatively straightforward to change a computer's clock to give the impression that a contract or suicide note was created on an earlier date. Such staging can make it more difficult to determine who wrote a document and when it was created. However, there are various approaches that forensic analysts can use to authenticate a digital document.
Forensic analysts can use date-time stamps on files and in log files to determine the provenance of a document such as a suicide note even when the digital crime scene is staged. For instance, it is possible to detect staging and document falsification by looking for chronological inconsistencies in log files and file date-time stamps. Nuances in the way computers maintain different date-time stamps can help forensic analysts reconstruct aspects of the creation and modification of a document. In addition, certain types of files, such as Microsoft Word, contain embedded metadata that can be useful for authenticating a document as detailed in Chapter 5, “Windows Forensic Analysis.” This embedded metadata may include the last printed date and the last 10 filenames and authors.
From the Case Files: An Honest Mistake
A man was accused of backdating a document to cover up alleged environmental violations. Forensic analysis of his computer and e-mail, as well as the e-mail of his attorney, all combined to show that the document had not been fabricated. They had simply used a prior document as a template and had forgotten to update the date typed at the top of the page.
The arrangement of data on storage media (a.k.a. digital stratigraphy) can provide supporting evidence in this kind of forensic analysis. For instance, when a forensic analyst finds a questioned document that was purportedly created in January 2005 lying on top of a deleted document that was created in April 2005, staging should be suspected since the newer file should not be overwritten by an older one. Although the usefulness of digital stratigraphy for document authentication can be undermined by some disk optimization programs that reposition data on a hard drive, it can also be aided by the process. In one case, the suspect defragmented his hard drive prior to fabricating a document. The forensic analyst determined that the defragmentation process had been executed in 2003, causing all data on the disk to be reorganized onto a particular portion of the disk. The questioned documents that were purportedly created in 1999 were the only files on the system that were not neatly arranged in this area of the disk, which added weight to the conclusion that the questioned documents actually were created after the defragmentation process had been executed in 2003 (Friedberg, 2003).

Data Gathering and Observation

After verifying the integrity of the digital evidence, forensic practitioners perform an initial survey to gain an overview of the entire body of evidence, including capacity, partitions (including identification and reconstruction of deleted partitions), allocated and unallocated space, and encryption. Then the evidence is preprocessed to salvage deleted data, and translate and filter as needed to expose the most useful information and eliminate irrelevant data. Organization is an implicit part of this phase, resulting in a reduced set of data grouped into logical categories like e-mail, documents, Internet history, reconstructed web pages, Instant Messaging chat logs, logon records, and network logs.
The decision to eliminate or retain certain data for forensic analysis may be based on external data attributes like MD5 values used to identify known child pornography or to exclude known operating system and application files. It may also be possible to narrow the focus to a particular time period or to certain types of digital evidence relevant to the case. However, keep in mind that offenders might have concealed evidence, so care must be taken when filtering data. Something as simple as video segments having their extensions changed from .MOV to .EXE could result in an unwary examiner inadvertently filtering out incriminating evidence. Therefore, it is advisable to identify file extension/signature mismatches and process them separately to determine what data they contain. There is even greater risk of missing important evidence when encryption or steganography are used to hide incriminating evidence within other files.
From the Case Files: United States v. Duncan
One of the home computers of convicted serial killer Joseph Edward Duncan III contained an encrypted PGPdisk container named Readme.txt. A limited cursory inspection of the dataset may have missed this simple attempt by the suspect to hide data, but a review of signature mismatches immediately brought this item to the attention of the examiner.
Depending on the forensic software utilized, certain data such as encrypted files, unusual archive compression, or Lotus Notes e-mail may need to be extracted for specialized processing. A simple example is a suspected compromised server where log files are archived as .tar.gz or .bz2. If the examiner's software does not automatically expand such files, they would need to be preprocessed prior to searching for a suspect IP address. This issue is covered further in the section “Special Files” later in this chapter.
Practitioner's Tip: Limited Resources
Many digital forensic laboratories have limited resources and are suffering from a backlog of cases. To deal with this problem and ensure that evidence is processed in a timely manner, some labs have adopted a tiered strategy for performing forensic processing, with three levels: (1) triage forensic inspection, (2) survey forensic examination, and (3) in-depth forensic analysis (Casey et al., 2009). If the triage forensic inspection reveals that the computer contains potentially relevant digital evidence, the computer can be assigned to a more experienced forensic practitioner for further levels of processing. Specialized tools are being developed to automate routine aspects for each level of processing. The FBI uses a preview tool called ImageScan to review all graphics files on a computer quickly without altering the original evidence. The Ontario Provincial Police developed a tool called C4P for a similar purpose (www.e-crime.on.ca). Triage-Lab is another tool used to automate triage forensic inspections of computers in various kinds of investigations (www.adfsolutions.com). In addition to keyword searching and other capabilities, triage tools like these can automatically identify previously unknown child pornographic images by utilizing image analysis technology, rather than just relying on MD5 hashes of known images.
The success of this approach depends on the laboratory establishing consistent methodologies for each level, and thresholds to guide the decision for use of different levels of forensic processing. In addition, proper training is needed to ensure that those performing the work at any level are not blinkered by protocols and procedures, and that they will recognize important evidence or indicators that require further forensic analysis. The use of encryption and data hiding can render cursory inspections and keyword searches of evidentiary media effectively useless.

Salvaging Deleted Data

An important aspect of the forensic analysis process is to salvage all data from storage media and convert unreadable data into a readable form. Although data can be hidden on a drive in many ways and it is not feasible to look for all of them in all cases, examiners should be able to identify the major sources of data or at least be able to recognize large amounts of missing data. For instance, if the combined size of all visible partitions on a drive is much smaller than the capacity of the drive, this may be an indication that a partition is not being detected. Similarly, if a large amount of data cannot be classified or there are many files of a known type that are unusually large, this may be an indication that some form of data hiding or encryption is being used. The following sections cover the main areas on storage media where useful data may be found.

Deleted Files and Folders

Criminals often take steps to conceal their crimes, and deleted data can often contain the most incriminating digital evidence. Therefore, one of the most fruitful data salvaging processes is to recover files and folders that have been deleted. When dealing with FAT or NTFS file systems, most tools can recover deleted files but not all can recover deleted folders that are no longer referenced by the file system. It is useful to know if and how different tools recover and present information about deleted files and folders.
Notably, automated file and folder recovery tools make assumptions that are not always correct. For instance, when recovering deleted files, many tools take the starting cluster and file size from a folder entry, and assign the next free clusters to the file sequentially. The underlying assumption in this process breaks down when the starting cluster of one deleted file is followed by free clusters that belonged to a different deleted file. So, automated tools can generate correct or incorrect results depending on the assumptions they make and the particular situation. Furthermore, if two deleted directory entries point to the same cluster, it can take some effort to determine which filename and associated date-time stamps referenced that cluster most recently. Some automated file recovery tools distinguish between directory entries that have been deleted versus those that have been deleted and overwritten. However, care must be taken not to assume that files with newer date-time stamps accessed the associated clusters more recently. There are sufficient nuances to file date-time stamps that an apparently newer file could be created before the apparently old one.
Figure 2.1 provides an example of an apparently recoverable deleted file. Closer inspection of the data that is displayed for this file reveals that it is not the actual original contents of the file.
B9780123742674000021/gr1.jpg is missing
Figure 2.1
Example of incorrect data in recoverable deleted file.
These problems are compounded when more aggressive salvaging techniques are used. Some forensic analysis tools have a powerful feature that scours a disk for deleted folders on FAT and NTFS systems. For instance, X-Ways provides a “Thorough” salvaging capability and EnCase has a “Recover Folders” feature. The resulting salvaged file system information may enable forensic analysts to recovered data that was associated with deleted files that are no longer referenced by the current file system. However, different implementations of this salvaging process can lead to inconsistent results between different tools, or even different versions of the same tool. Many existing forensic tools combine salvaged file system details with the existing file system, and this mixing of two separate file system states often leads to more conflicts of the type described in the previous section. The conflicts arise when a new file has reused the clusters that were previously allocated to a salvaged file. To guard against mistakes and misinterpretations, it is critically important that forensic analysts conceptually separate these two system states, thinking of the salvaged file system information as separate and overlaid on top of the existing file systems.
For the simplest conflicts, both the current and salvaged file system have file system metadata pointing to same area on disk, generally providing forensic analysts with sufficient information to resolve the conflict. More difficult conflicts arise when the space allocated to a salvaged file has been overwritten by newer data but file system details about the newer file are not recoverable. In this situation, the diligent forensic analyst will determine that the file content is not consistent with the salvaged file system details. This inconsistency may be as simple as a salvaged Microsoft Word document pointing to an area of the disk that contains a JPEG graphics file. However, some inconsistencies are more difficult to detect, and require a more thorough comparison between the recovered data and the salvaged file system information. In more complicated situations, multiple salvaged filenames point to the same area of the disk, creating additional levels of complexity when trying to reconstruct activities on a computer system. Therefore, forensic analysts must take additional steps to determine whether the data that appears to have been allocated to a salvaged file in fact was recovered properly and accurately.
From the Case Files: Disambiguation of Deleted Files
This example clearly illustrates the potential problems of deleted file recovery in an Internet child pornography case.
…a JPG file was recovered from cluster 195,018 and two file entries were found pointing to it. The first of these indicated that a file named tn_pbb0915.jpg was written to this cluster at 22:16:06.30 on 10th October 2001 and it was 3051 bytes in length. The second entry however, indicated that a file named 3e.jpg had been written to the cluster at 00:24:08.75 on 14th January 2002 and it was 6497 bytes in length. The fact that the drive had been defragmented meant that it was not possible to make the simple assumption that the recovered JPG data was the later file. Even without defragmentation, ascribing the image to the later file entry was still weak because as both file entries were marked as deleted, it was a distinct possibility that the image data had been written after the 14th January 2002 and its attendant file entry had been lost. However, research into the internal structure of JPG files revealed that it is possible to calculate the original length of the file in bytes. The recovered data indicated an original file length of 6497 bytes, providing a much stronger inferential link to the second file entry. (Bates, 2002)
When a few deleted files or folders are critical to a case, forensic analysts should examine them closely for inconsistencies, and seek corroborating evidence from other areas of the computer system or connected networks. The same caveats apply to deleted items in physical memory of computers and mobile devices. Forensic tools are emerging that capture the full contents of memory from various devices and attempt to reconstruct the data structures containing files, processes, call logs, SMS messages, and other information. Given the variety of data structures, mistakes may be made when parsing physical memory dumps and attempting to recover deleted items.
Documentation relating to this recovery process, such as an inventory of the recovered files and a description of how they were salvaged, should be maintained to enable others to assess what was recovered. Given the variations between tools and the potential for error, it is advisable to compare the results from one tool using another. Such a comparison can be made by comparing the inventories of undeleted files from both tools for any differences.

File Carving

Recall that, on storage media, the space that is available to store new data is called unallocated space. This area on a disk is important from an investigative standpoint because it often contains significant amounts of data from deleted files.
File carving tools like Foremost, Scalpel, DataLifter, and PhotoRec scour unallocated space for characteristics of certain file types in an effort to salvage deleted files. This salvaging process generally produces a large percentage of incomplete and corrupt files, because file carving tools rarely know the size of the original files, and the deleted files may be fragmented or partially overwritten. If the approximate size of the original files is known, forensic analysts can adjust a parameter in file carving tools to set the maximum size of the salvaged files to increase the number of successfully salvaged files. When specific files are of interest, like deleted NT Event Logs, file carving tools can be customized with the associated file signature to salvage these file types (Murphey, 2007).
Practitioner's Tip: Different Tools View Unallocated Space Differently
Although most tools for examining storage media have the ability to extract unallocated space for separate processing, their approaches are not necessarily consistent. For instance, when EnCase recovers deleted files, it no longer considers the associated data to be in unallocated space whereas some other tools do, effectively accounting for the data twice. For instance, on the hard drive used in the investigative scenario for this chapter, the amount of unallocated space reported by EnCase is 16,606,420,992 bytes whereas other forensic tools like X-Ways report it as 16,607,297,536 bytes. The difference of 876,544 bytes does not correspond directly to the amount of data in recoverable deleted files. In some circumstances, having a forensic tool like EnCase recategorize recovered data may reduce the amount of redundant data through which a forensic practitioner has to wade. However, failure to realize that this recategorization has occurred can caused forensic practitioners to reach incorrect conclusions. For instance, as noted in the previous section, there is a chance that some unallocated clusters may be assigned to the incorrect file. It can be more effective to carve files out of unallocated space utilizing a tool that takes a stricter definition of unallocated space. If the undelete and file carving processes produce the same files, these duplicates can be eliminated.
Some forensic utilities break large files such as unallocated and swap space into smaller pieces to facilitate processing such as file carving and indexing. If an examiner exports and processes these segments of unallocated space individually with standalone file carving utilities, it is possible that, depending on where the boundaries are, portions of salvaged items may be missing.
Keep in mind that most file carving methods work on the assumption that a file is stored in contiguous clusters. The advantage of performing file carving on extracted unallocated space rather than on a full forensic image is that the data on disk may not have been arranged in consecutive clusters but may become consecutive when extracted into a single file. Also keep in mind that files salvaged using this technique do not have file names or date-time stamps associated with them so the examiner needs to assign them names in a systematic way.
Researchers are developing more sophisticated techniques to salvage fragmented deleted files in response to DFRWS Forensic Challenges (www.dfrws.org). Currently, these advanced salvaging methods work for only certain file types like PDF and ZIP files (Cohen, 2007).

Handling Special Files

There are certain files that will not be immediately accessible to keyword searching. In addition to encrypted and password protected files, certain file formats store text in binary or proprietary formats. These “special” files include compressed archives, encoded attachments in e-mail messages, and encrypted and password protected files.
Another very common example is Adobe PDF documents that have been “secured” to prevent extraction of text, and TIFF fax documents. Keyword searches on these of course will be useless. If there is a large quantity of such unsearchable files that are relevant to a case, more than can be reviewed manually, the typical approach is to use optical character recognition (OCR) to convert them to text, thus rendering them searchable. Attention must be paid to ensure that mistakes are not introduced by the OCR process.
A criminal investigation may center around kickbacks on contracts, and forensic analysts may focus their attention on Microsoft Office documents and other files that are keyword searchable. However, the smoking gun evidence may actually be in TIFF e-mail attachments, JPG items in “My Scans,” or received fax items. An effective identification and preprocessing procedure process will identify such items whereas just performing keyword would fail.
Practitioner's Tip: Uncompressing Files
Provided compressed files are not password protected or corrupted, they can be uncompressed with relative ease. However, there are many varieties of compression, and if your forensic tool does support a particular kind that you encounter, you can export the files, uncompress them using a specialized utility for that purpose, and add the uncompressed files to the case.
Practitioner's Tip: Deleted E-mail Fragments
Be aware that Outlook e-mail is stored on disk using a simple form of encoding. Therefore, when searching for deleted e-mail associated with a particular address, forensic analysts select the appropriate decoding mechanism. EnCase provides this in a “code page” called “Outlook encryption” to search for such encoded e-mail addresses and text.
MIME encoding adds an additional layer of encoding to e-mail attachments. An alternate approach to searching for e-mail messages is to use a tool that understands the specific file format and makes it accessible for keyword searching. FTK can interpret and index an Outlook PST file as shown in Figure 2.2, giving forensic analysts efficient access to e-mail messages and many attachments. EnCase can also interpret some of these proprietary formats using the View File Structure feature. An added advantage of using this type of specialized tool is that they support analysis of metadata within e-mail. For instance, a search can be restricted to a date range of interest. When using such specialized tools for processing digital evidence, it is important to understand their inner workings in order to avoid mistakes and misinterpretations. For instance, exporting items found in e-mail using certain tools may not preserve the parent–child relationship between messages and attachments, which can be important in certain situations. Common examples of the pitfalls of processing e-mail are covered in Chapter 3, “Electronic Discovery,” with a specific example relating to dtSearch.
B9780123742674000021/gr2.jpg is missing
Figure 2.2
FTK used to extract e-mail messages and the contents of attachments such as images in a Zip archive shown here.
Another approach to viewing proprietary formats, such as America Online (AOL) or Lotus Notes, is to restore them to a disk and view them via the native client application. In some cases it is possible to recover messages that have been deleted but have not been purged from e-mail containers.
When special files are corrupt, it may be possible to repair the damage using specially designed utilities. For example, EasyRecovery Professional from Ontrack can repair a variety of file types from Windows systems including Outlook files and Zip archives. On UNIX systems, there are tools for repairing a more limited set of files such as tarfix and fixcpio.

Encryption and Steganography

Encryption can present a significant challenge for digital forensic practitioners, particularly full disk encryption (Casey & Stellatos, 2008). Even when full disk encryption is not used or can be circumvented, additional effort is required to salvage data from password protected or encrypted files (Casey, 2002). When dealing with individually protected files, it is sometimes possible to use a hexadecimal editor like WinHex to simply remove the password within a file. There are also specialized tools that can bypass or recover passwords of various files. Currently, the most powerful and versatile tools for salvaging password protected and encrypted data are PRTK and DNA from AccessData. The Password Recovery Toolkit can recover passwords from many file types and is useful for dealing with encrypted data. Also, it is possible for a DNA network to try every key in less time by combining the power of several computers. Distributed Network Attack (DNA) can brute-force 40-bit encryption of certain file types including Adobe Acrobat and Microsoft Word and Excel. Using a cluster of approximately 100 off-the-shelf desktop computers and the necessary software, it is possible to try every possible 40-bit key in five days. Rainbow tables can be used to accelerate the password guessing process. Some vendors also have hardware decryption platforms based on implementation of field programmable gate arrays that can increase the speed of brute force attacks.
When strong encryption is used such as BestCrypt, PGP, or Windows Encrypting File System, a brute-force approach to guessing the encryption key is generally infeasible. In such cases, it may be possible to locate unencrypted versions of data in unallocated space, swap files, and other areas of the system. For instance, printer spool files on Windows and UNIX systems can contain data from files that have been deleted or encrypted. Alternatively, it may be possible to obtain an alternate decryption key. For instance some encryption programs advise users to create a recovery disk in case they forget their password. When EFS is used, Windows automatically assigns an encryption recovery agent that can decrypt messages when the original encryption key is unavailable (Microsoft, 1999). In Windows 2000, the built-in administrator account is the default recovery agent (an organization can override the default by assigning a domainwide recovery agent provided the system is part of the organization's Windows 2000 domain).
Notably, prior to Windows XP, EFS private keys were weakly protected and it was possible to gain access to encrypted data by replacing the associated NT logon password with a known value using a tool like ntpasswd and logging into a bootable/virtualized clone of the system with the new password.
When investigating a child exploitation case, it is advisable to be on the lookout for other forms of data concealment such as steganography. Forensic analysts can make educated guesses to identify files containing hidden data—the presence of steganography software and uncharacteristically large files should motivate examiners to treat these as special files that require additional processing. In such cases, it may be possible to salvage the hidden data by opening the files using the steganography software and providing a password that was obtained during the investigation. More sophisticated techniques are available for detecting hidden data. Even if encryption or steganography cannot be bypassed, documenting which files are concealing data can help an investigator, attorney, or trier-of-fact determine the intent of the defendant.

Extracting Embedded Metadata

The purpose of this step is to harvest additional metadata relating to the files of interest to support further analysis. As noted at the beginning of this chapter, embedded metadata can answer a variety of questions regarding a document, including its provenance and authenticity. Embedded metadata can also help generate important leads, pointing to other sources of digital evidence on the system or Internet. As described in Chapter 1, photographs taken by digital cameras can contain details such as the make and model of the camera, the date and time the picture was taken (according to the camera's clock), and with some models the GPS coordinates of the camera when the photograph was taken. The data in such photographs found on a computer or on the Internet can be compared with those of a digital camera seized in the defendant's home to determine if they are consistent, helping to establish a link.
Investigative Scenario

Part 2: Embedded Metadata
Review of the EXIF header data in 24 digital photographs copied into the folder CDocuments and SettingsRomanMy DocumentsMy PicturesValentines Day on the subject system on February 15, 2009, indicate they were digitized utilizing a Nikon Coolpix P4 camera as shown in Figure 2.3.
B9780123742674000021/gr3.jpg is missing
Figure 2.3
EXIF data extracted from a digital photograph using JPEGsnoop.
According to EXIF header information these images were digitized between 6:41 pm and 6:56 pm on February 14, 2009. With a maximum of a two-second discrepancy, the File System Last Written dates on the subject system correlated to the EXIF header information.
At this point it is an assumption that the suspect, Roman, took these pictures (and thus was the person “casing” the target site). In addition to fingerprints on the camera and removable media (if seized), an analyst may look for reflections (some of the images are close to the building, which has reflective glass) in an effort to identify the individual using the camera at that point in time.
There are many other sources of metadata that can be useful in digital investigations, as detailed in the technology-specific chapters later in this Handbook. The experience and judgment of the examiner must be exercised to determine what data might be available and which might be useful to the investigation.

Overview of System Configuration and Usage

After preprocessing the evidence, an initial review is performed to document information about the users of the system (e.g., user accounts, e-mail accounts, IM accounts), and configuration information like time zone, network, and wireless settings. Forensic practitioners look for items of interest in typical user storage areas (My Documents, e-mail), nontraditional or unusual storage areas (intruder storage of files in Recycle Bin, concealed files and directories, renamed file extensions, etc.), along with traditional areas of forensic interest including the Registry and log files. As part of this review process, forensic analysts try to establish an initial overview of user activities on the computer, including recent files accessed, Internet browsing history, and device connection information.
An analyst traditionally breaks down and associates activity with a specific user, and may need to repeat this process for every user account. In addition to logical document review and file system activity, this may include processing of the Internet history (Internet Explorer, Firefox, Safari, etc.), Registry (ntuser.dat), and file permissions.
Investigative Scenario

Part 3: System Configuration and Usage
The operating system was Microsoft Windows XP, Service Pack 3, (installed as SP2) December 22, 2008 at 10:10 pm. Both the Registered Owner and Registered Organization Fields contained “-”, and at the time of the forensic analysis, the assigned computer name “TEST13.” The system was configured for “Eastern Standard Time” with an offset of –5 hours from GMT. The active time bias at the time of acquisition was –4:00 offset from GMT.
The primary user account was “Roman”, with a Logon Count of 22 and a Last Logon of May 23, 2009. This user account was not protected by a password. Utilizing Access-Data's Password Recovery Tookit with associated Registry files (SAM/System) from the subject computer as input, the administrator account password was determined to be L1b3r4t0r.

User Folders of Potential Interest

Photographs of Baltimore World Trade Center office building taken on February 14, 2009 from multiple angles were found on the suspect's system. In addition, on February 15, 2009 at 2:45 pm, the folder CDocuments and SettingsRomanMy DocumentsGarmin was created as shown in Figure 2.4.
B9780123742674000021/gr4.jpg is missing
Figure 2.4
Contents of My Documents on subject system.
The document named Funds.ods shown in Figure 2.4 was created on May 23, 2009 in the My Documents folder and requires further analysis (to be continued…).
A review of all installed and uninstalled applications may provide significant information. For example, installed “covert” communications (steg), privacy software (Tor), specialized applications to destroy data (e.g., BCWipe or Evidence Eliminator), or transfer mechanisms (e.g., Winsock FTP, peer-to-peer) may dictate a much more detailed analysis in an attempt to document user activity associated with such utilities. Installed applications may also provide insight as the user's knowledge level. An example would be existence and use of hexadecimal editors, “patch” files, and low-level programming utilities such as Microsoft Assembler along with user generated source code. Specialized user generated material such as source code may require review by an expert.
From the Case Files: Suspicious Software
In one case, a software development company released a large number of employees two months prior to a major product release. Two weeks prior to release, all source code and code repositories were mysteriously deleted, and unfortunately the tape backup was one month old. During a forensic analysis of one of the company's servers, a simple UNIX script was found that logged into each corporate server as root and executed an rm * to delete all files. In another case, during an initial incident response, the examiner responding to the suspect's work area noticed several items of concern. First, the user had a workstation with specialized password “crack” software connected via a serial cable to the company's PBX phone system. Not only had the user cracked the admin password, forensic analysis confirmed later by the suspect's confession determined he had created a logic bomb that would have deleted all phone system information. This company's lifeblood was the phone system, and the destruction/reconstruction of this material would easily have represented several million in losses.
In addition to review of applications, an examiner typically performs an antivirus and malware scan. Knowing which, if any, virus programs and/or malware or remote access tools are present may be an important aspect of the case. For example, forensic analysis of malware may be necessary when a defendant uses the “Trojan defense,” claiming that all incriminating material on his computer is attributable to a remote intruder who compromised the system using a remote administration tool (a.k.a. Trojan horse program). Assessing the capabilities of malware found on the system may reveal that it could not have been used to place the incriminating files on the computer, and analyzing activities on the computer around the time in question may support the conclusion that the defendant was using the computer when the incriminating files were placed on the system.
Investigative Scenario

Part 4: Program Files of Potential Interest
Based on file system creation date-time stamps, the folder C:Program FilesMozilla Firefox was created on December 22, 2008 at 10:20 pm. This web browser maintains a history of URLs accessed and other useful information. On February 13, 2009, an installation file for Skype was created in the folder C:Documents and SettingsRomanMy Documents folder, and the file Vidalia-bundle-02.0.34-0.1.10.exe was created in the same folder minutes later. This bundle included The Onion Router (TOR), an application that utilizes a network of virtual tunnels to help improve privacy and security, and Vidalia, a graphic user interface to TOR. Both Skype and Vidalia/TOR were installed on the system on February 13, 2009.
Evidence of the existence of the file wiping utility Jetico BCWipe was detected on the subject system; however, there is no indication of recent use to overwrite data on the system. The folder C:Program FilesJeticoBCWipe was created and last accessed on December 22, 2008 at 10:22 pm, however, this folder contained no files. A reference to E:BCWIPE3.EXE was found in pagefile.sys, suggesting the source of the application was a 60GB Western Digital USB drive that was connected approximately two minutes earlier as indicated by the setupapi.log file. At the time of acquisition, the subject system had no Prefetch folder. However, a reference to BCWIPE3.exe-3484E676.pf was found in unallocated space along with references to Documents and SettingsRomanLocal SettingsTemp~BCWIPE3.TMP.
Regarding the “Funds.ods” file mentioned in the previous part of this scenario, the file extension “.ods” is associated with OpenOffice, which was not installed on the subject system. The fact that Open Office was not installed is exactly the type of thing an analyst should catch, leading to further analysis as to how the document came to be on the system. The file is actually stored as a zip archive that includes and embedded file named meta.xml that contains metadata associated with the spreadsheet. Subsequent analysis of the meta.xml indicated it was created online at http://spreadsheets.google.com as detailed later in this chapter.
Once elements of a user's activity are processed, the examiner can identify significant elements for reporting or further analysis. An example would be the user executed Google searches on “deletion utilities”, followed by “prevent undeleted”, with subsequent download and execution of such a utility to delete several company confidential documents the day of her previously unannounced resignation, but only after she connected a USB thumb drive, reviewed the confidential documents, performed a File->Save As to save them to the thumb drive.
Investigative Scenario

Part 5: User Activities of Potential Relevance
Potentially relevant user activities on the subject system from the investigative scenario are summarized here.

Removable Media Summary

On February 15, 2009 between 2:34 pm and 2:40 pm, the file setupapi.log indicated a USB Device identified as garmin__nuvi was successfully installed. On February 15, 2009 between 2:36 pm and 2:38 pm, 24 files, named DSCN3680.JPG through DSCN3703.JPG (with no number gaps in the naming scheme) were created in the CDocuments and SettingsRomanMy DocumentsMy PicturesValentines Day folder.

Internet Access Summary

Web browsing activities were reconstructed from Firefox and Internet Explorer web browser history, along with search hits in unallocated space for “url:”, “http://”, “https://”, and “file://”.
On February 15, 2009 at 2:45 pm, Firefox was used to access the account [email protected], which is a free privacy-enhanced web-based e-mail service. Five minutes later, at 2:50 pm, the user executed a Google search for “check ip address”. Subsequently the user accessed http://whatismyipaddress.com with a web page title of Lookup IP, Hide IP, Change IP, Trace IP and more…. The act of checking which IP address is visible on the Internet indicates that the user had some knowledge of computers and the Internet, and how to conceal the IP address of a computer on the Internet. This may have been an attempt to confirm that TOR was functioning correctly to conceal the user's source IP address.
On March 19, 2009 at 12:32 pm, Firefox was used to execute a Google search for “World Trade Center Baltimore building plans” with subsequent access to the file www.marylandports.com/opsalert/eBroadcast/2008/HPPwtc2008.pdf. Subsequently, at 1:18 pm, Internet Explorer and file system activity reflect access to the web page Account is Now Active at www.gunbroker.com. The content of this page in conjunction with an earlier redirect page suggests the user received a Gunbroker.com account activation e-mail at [email protected]. After logging into the Gunbroker.com web site, the user accessed the auction web page for a specific weapon: www.gunbroker.com/Auction/ViewItem.asp?Item=125130891, (SIGARMS, P229, 9MM, NIGHT SIGHTS, 13RD, 2 MAGS). The user then viewed a listing of auctions for semi-automatic guns—the reconstructed web page is displayed in Figure 2.5.
B9780123742674000021/gr5.jpg is missing
Figure 2.5
Part of a web page from the suspect's computer showing auctions of semi-automatic pistols on Gunbroker.com.
On March 19, 2009 at 1:19 pm, the user accessed a web page on Gunbroker.com to “Ask Seller A Question—Send Mail to User” for the specific auction item 125288486.
On March 20, 2009 at 12:00 pm, a Firefox 3 Bookmark was created concerning a Google search for “undetectable bomb”. Checking Mozilla Firefox in a virtualized clone of the subject system confirmed recent entries, as shown in Figure 2.6.
B9780123742674000021/gr6.jpg is missing
Figure 2.6
Remnant of web search for “undetectable bomb”.
Based on the keyword “undetectable bomb”, additional analysis was performed of the unallocated areas of the system, resulting in additional items that may represent either web pages viewed or searches conducted by the user of the system. Examples included liquid-explosives, Baltimore building design plans office, Baltimore city building records, and Baltimore building planning records. No date/time structures were identified with these records.
On May 23, 2009, between approximately 2:59 pm and 3:20 pm, the user created the Gmail account [email protected]. A total of six CreateAccount[x].htm files created during this process reflected several hidden values, some of which are visible in the reconstructed web page shown in Figure 2.7. The multiple CreateAccount[x].htm files were caused by several attempts to set the password. The most recent entered password was DFIChapter2.
B9780123742674000021/gr7.jpg is missing
Figure 2.7
Reconstructed Gmail account setup page.
On May 23, 2009 at 3:04 pm, the file C:Documents and SettingsRomanMy DocumentsMy PicturesValentinesDayDSCN3682.JPG was Last Accessed and was sent as an e-mail attachment via Outlook Express. This e-mail is shown in Figure 2.8.
B9780123742674000021/gr8.jpg is missing
Figure 2.8
E-mail message sent with digital photograph attached.

Hypothesis Formation

A hypothesis is an informed supposition to explain the observations in the data gathering phase of a forensic analysis. Even if it is difficult to come up with a hypothesis initially or this initial hypothesis is wrong, it is important to pick a place to start. The process of testing a hypothesis objectively will invariably improve a forensic analyst's understanding of the evidence, leading to continuous refinements of the hypothesis until a rational conclusion is reached.
There may be many individual hypotheses relating to different aspects of an offense, each of which must be verified independently. In a child exploitation investigation, the forensic analyst might think that incriminating photographs were produced using the suspect's digital camera and then transferred on the suspect's computer. The forensic analyst would have to test the two hypotheses that (1) the photographs were taken using a specific camera and (2) the photographs were transferred from that camera onto the suspect's computer. In an intellectual property theft investigation, the forensic analyst might think that the stolen files were copied from the suspect's computer onto removable media and then deleted from the suspect's computer. The forensic analyst would have to test the two hypotheses that (1) the stolen files were copied onto removable media and (2) they were subsequently deleted.
One of the most common mistakes that forensic analysts make when coming up with a hypothesis is to let themselves be influenced by prejudice. For instance, by starting with an assumption of guilt, a forensic analysis is already biased. An effective approach to mitigate this risk is to reverse the hypothesis. Using the child exploitation example in the previous paragraph, the hypotheses to be tested could be (1) the photographs were not taken using the specific camera and (2) the photographs were not transferred from that camera onto the suspect's computer. To test these hypotheses, a forensic analyst might look for evidence that the photographs were taken by someone else and downloaded from the Internet. When there is no evidence to support this explanation, or any other reasonable alternate explanation for the presence of the incriminating photographs on the suspect's system, and analysis of the camera, photographs, and computer all indicate that the photographs came from the camera onto the computer, this is a much stronger result.

Evaluating Hypotheses

Forensic practitioners are regularly presented with questions that require relatively straightforward analysis of the evidence. For instance, in order to determine whether incriminating files were downloaded from the Internet or copied onto the system from removable media, a forensic analyst might test the download speed of the subject system versus transfer rates of files copied from a CD, DVD, or removable mass storage device. Running controlled tests with a specific set of files using similar or exact computer and network setup may show that files were copied from a DVD in 60 seconds, from a USB device in 30 seconds, and downloaded via the Internet in 10 seconds. Based on a series of such tests combined with other evidence on the system, a forensic analyst may be able to express an opinion that the incriminating files were downloaded onto the system from the Internet.
In addition, forensic practitioners may encounter files that are not directly processed by their forensic suite, and research fails to identify any utility to facilitate review. In such cases the forensic analyst may need to improvise, perform experiments, and develop their own analysis methods and techniques, guided the entire time by the scientific method.
From the Case File: Disproving Witness Statements
In one case, the offender claimed that he could not remember the password protecting his encryption key because he had changed it recently. By experimenting with the same encryption program on a test system, the forensic analyst observed that changing the password updated the last modified date of the file containing the encryption key. An examination of the file containing the suspect's encryption key indicated that it had not been altered recently as the suspect claimed. Faced with this information, the suspect admitted that he had lied about changing the password.
Forensic practitioners may have to navigate various challenges and uncharted territory as part of their analysis. Evidence dynamics can make crime reconstruction using digital data more difficult, as described in Chapter 1. In some cases, the direct evidence may not be present but the forensic practitioner may be able to identify “forensic residue” or “intrusion residue.” These are traces left by user actions or intruder actions, such as the execution of software that may no longer be present on the computer; however, such traces or residue can be used to determine what occurred. This is analogous to a poison that dissipates and is no longer detectable in a victim's body, but the result of the poison is the body's creation of some type of residue such as a specific chemical, protein, or enzyme that is detected in the victim's body. Despite the absence of the poison (which may exist in the body for only a short period of time, like a malicious binary that securely deletes itself after two weeks), the residue or the side effect of its use would be the forensic residue that allows a forensic pathologist to determine that that particular poison was used.

Interpretation of Digital Evidence

Every observation and measurement has some degree of uncertainly, and it is a forensic practitioner's job to get as close to the truth as possible. There are some common pitfalls of which forensic analysts must be aware in order to avoid reaching the wrong conclusions.
From the Case Files: Forensic Residue
A user noticed that an unauthorized $30,000 transfer from her account had occurred. No malware was identified on the system; however, the examiner documented intrusion residue of a buffer overflow by examining Dr. Watson log files. The log entry also provided the name of a suspicious binary, and a corresponding file system entry was identified that documented creation of a suspected piece of malware; however, it was deleted and unrecoverable. The malicious software was no longer on the system; however, the forensic and intrusion residue in this instance was an entry in the Dr. Watson log showing the existence and execution of the malware.
In this case, the forensic residue gave the examiner a starting point that not only facilitated the review, but revealed additional related evidence that might have otherwise gone unnoticed. Although the executable was no longer on the system, Prefetch files confirmed that the suspected piece of malware had been executed on the subject system. Correlating the user's web browsing history confirmed the source of compromise, and subsequent analysis allowed the examiner to identify a suspicious .INI file in the Windowssystem32 folder. This file was determined to be a keystroke log file; and as the file was constantly changing, System Restore points were created. Subsequent forensic analysis of the reconstructed keystroke log files from System Restore points confirmed the username and password for the bank account in fact were compromised due to keystroke logging software on the user's system. Subsequent capture and analysis of the malicious software via a link obtained from the user's Internet Explorer history confirmed an embedded IP address (confirmed by the companies’ firewall logs) where the log files were transferred to Eastern Europe via port 80. In many such cases, the forensic residue may provide the critical (and potentially otherwise unavailable) evidence.
As noted in Chapter 1, forensic analysts generally see only a representation of the actual digital evidence they are reviewing. The raw data is translated through multiple layers of abstraction that can misrepresent the underlying data or miss important details. Figure 2.9 shows file system information extracted from a physical memory dump of a Motorola Z3 mobile device using XACT. The JPG file in the “picture” folder selected on the left has been associated with non-JPG data shown on the right. Furthermore, a manual examination of the device shows that there are additional digital photographs in this folder that are not displayed using the forensic tool.
B9780123742674000021/gr9.jpg is missing
Figure 2.9
Memory contents from a Motorola Z3 cell phone viewed using XACT shows incorrect data associated with a digital photograph.
Some of the most detrimental errors and omissions occur when forensic tools incorrectly parse file system structures, because this information forms the foundation for many aspects of forensic analysis.
As another example of misinterpretations introduced by forensic software, some tools attempt to reconstruct remnants of web-based e-mail messages from unallocated space. This process can result in erroneous combinations of data fragments, giving the impression that someone sent a message that never existed. To avoid reaching conclusions or making false accusations based on incorrect information, it is necessary to verify important findings at a low level to confirm they exist and are being accurately represented by the forensic tool.
In addition, forensic analysts must consider the possibility that critical file date-time stamps may have been altered or are inaccurate. In a number of cases, mistakes in forensic analysis have arisen from differences in time zones and daylight savings.
From the Case Files: In the Wrong Time Zone
In one child abuse case, an expert hired by the defense to examine the defendant's computer concluded that it had been used to access the Internet during the first six hours after it was in seized by police. The expert's report indicated that there was substantial evidence of the defendant's computer being altered while it was in police custody, including access to Hotmail login pages and a possible child pornography site. It transpired that the defense expert had not taken the difference in time zones into account when converting the date-time stamps in the Internet Explorer index.dat files (Foster, 2004).
In another case involving time zone complications, the suspect flew from Chelyabinsk to Seattle. While in Seattle, the suspect accessed remote hosts on the Internet from the laptop he brought with him before he and his associate were apprehended. The suspect challenged some of the data; having conducted his own review of the dataset, he believed it indicated he was framed by the undercover agents for some of the activity on the system when in fact he simply had failed to take into account the time zone difference. Once presented with the findings of an independent forensic analysis performed as a result of his complaint, he immediately recognized his fundamental mistake.
Digital evidence should always be interpreted in context. When reviewing the image content of web browser cache folders, it is a common mistake to take the existence of the images as something of more value then they may actually represent. In one case, an inexperienced forensic practitioner noticed several “terrorist related” images. This information was submitted in an affidavit and utilized to support requests for additional search warrants. Unfortunately, the forensic practitioner did not take into account the context of the images. They were all Temporary Internet Files associated with access to CNN.com.
Investigative Scenario

Part 6: Interpretation of Web Browsing Artifacts
Following are some images from the Internet Explorer cache. Knowing that the individual has reviewed weapons sites, conducted searches on terms such as liquid explosives and undetectable bombs, one might see the image of the Coast Guard ship and make an assumption that the user may also be interested in targeting it. Also, the images of Central America and Canada may cause the belief that the user was looking at map points in these areas as shown in Figure 2.10.
B9780123742674000021/gr10.jpg is missing
Figure 2.10
Graphics files in the Temporary Internet Cache.
By reviewing the user's Internet history, we know the user visited Google Maps and entered coordinates. By recreating the web page from the cache contents as shown in Figure 2.11, or conducting a test on an operationally authorized computer to recreate the circumstances, an analyst will recognize that the image of the Coast Guard ship was displayed automatically.
B9780123742674000021/gr11.jpg is missing
Figure 2.11
Reconstructed web page.
No Internet history from Internet Explorer or Firefox revealed any specific user access to the image of the Coast Guard ship. Furthermore, the map images of Canada and Central America that looked potentially valuable were simply the result of accessing the default http://maps.google.com web page, which loaded various map segments.
As another example, the mere presence of an incriminating file on a person's computer may not be sufficient to demonstrate guilt. Forensic analysis may reveal strong evidence that the file was placed on the system by a virus, intruder, or via a web browser vulnerability without the user's knowledge. An analysis of the file, its location, security vulnerabilities, artifacts of system usage, and other contextual clues may help determine how a file came to be on a given system.
Similarly a file with a creation date that is after its last modified date may be incorrectly interpreted as evidence that the system clock was backdated. In fact, the last written date of a file does not necessarily imply that the file was modified on the computer where it is found. Copying a file onto a computer from removable media or another system on a network may not change the last written date, resulting in a file with a modified date prior to its creation date.
Practitioner's Tip: Reconstructing Web Pages
Another common process is to recreate web pages visited by the user of the computer. As images and cache content are frequently deleted, there is potential to manually recreate a web page that depicts incorrect information. An example might be a web page with content that was deleted previously, which included files named image01.jpg and image02.jpg. Another web page visited more recently, which happens to be stored in the same Internet Explorer history folder, may reference the exact same filenames. If the previous web page was recoverable and reconstructed (and the previous image files overwritten), reconstruction of the page may very well include images that were not associated with that actual page. Presented as fact without proper qualification, this information could be misleading. Considering that most forensic workstations are not connected to the Internet, and assuming that the content then was the same as it is now, it may be possible to reconstruct a page utilizing a workstation connected to the Internet, but there are many concerns with this process as well. In many cases, online resources like the Internet Archives (www.archive.org) have been utilized to help confirm the previous existence and general type of content of web sites.
There are many other nuances to digital evidence caused by the intricacies of computer operations that can cause confusion or misinterpretation, and the same holds true for networks. The Internet Protocol (IP) address in an e-mail header may lead investigators to a particular computer, but this does not necessarily establish that the owner of that computer sent the message. Given the minor amount of effort required to conceal one's identity on the Internet, criminals usually take some action to thwart apprehension. This may be as simple as using a library computer or as sophisticated as inserting someone else's IP address into the e-mail header, requiring investigators to take additional steps to identify the culprit.
To mitigate the risks of evidence being missed or misinterpreted, experienced forensic analysts employ a variety of techniques, including comparing the results of multiple tools, validating important findings through contextual reviews and low level examination, and analyzing corroborating evidence for inconsistencies. For instance, when dealing with date-time stamps of files, look out for inconsistencies in other related, independent sources of information processed during the data gathering phase like embedded metadata, Internet history, and Registry entries. Also, as discussed in Chapter 9, “Network Analysis,” it may be possible to correlate date-time stamps relating to downloaded files with network logs, thus not only validating the findings but also helping to reconstruct the cybertrail leading from a crime scene back to the offender.
Practitioner's Tip: Studying a Digital Clone
An effective approach to verifying that you are interpreting particular digital evidence correctly is to create a digital clone of the subject system and inspect the evidence as it is seen through the device itself. For instance, booting a forensic duplicate of a computer through utilities such as LiveView may allow you to view important details in their native context. In one case, this type of functional analysis revealed that the desktop of the defendant's computer had a specialized theme with a skull and crossbones icon for My Computer and a Swastika for the Recycle Bin icon. In some cases, specialized applications and associated files (e.g., CAD/CAM files) on the subject system may prevent native review of files on the forensic workstation, in which case a LiveView session may provide a review capability otherwise unavailable. The same concept applies to mobile devices by viewing acquired evidence in a software emulator, or restoring it onto a test device of the same make, model, and firmware.

Exploring Unfamiliar File Formats

Because of the rapid development of new software applications and updates to existing programs, digital forensic analysts are frequently faced with new file types. In some instances, the purpose of the file may be deduced from its context and the content may be readily interpreted.
Investigative Scenario

Part 7: Forensic Analysis of SatNav Artifact
On February 15, 2009 at 2:58 pm, the file GarminDevice.xml was created, which included text indicating the device was a Garmin nuvi, model 3386111263 with registration and unlock codes XYZABC and MLJ6XYZABC, respectively. Around the same time, the file current.gpx was created, which included XML text entries documenting the following stored GPS locations:
▪ Home, Residence, PhoneNumber 14105554523, wpt lat=39.29544, lon=-76.612045
▪ Meet Spot, Residence, PhoneNumber 14105554523, wpt lat=39.289761, lon=-76.612222
▪ Target (annotated with a blue Flag Symbol), wpt lat=39.286130, lon=-76.609936
On February 15, 2009 at 3:00 pm, the user accessed file C:/Documents and Settings/Roman/My Documents/Garmin/gpx/current.gpx. This may indicate that the user was aware of and specifically accessed this file. This is supported by use of the Target coordinates in subsequent communications described later in this chapter.
In the unknown areas, an examiner may need to review all possible associated files, filtered by relevant dates/times, and develop his or her own processes to facilitate review. An example of this from the investigative scenario developed for this chapter is recognizing that some Skype usage information on the suspect's system was stored in the SQLite database main.db, which appeared to map all of the Skype chatsync subfolders that contain data associated with various Skype activities as described further, next. Although a strings command obtained some of the information from the main.db SQLList database file, more usable information was obtained after export by utilizing the SQLite command-line program (www.sqlite.org/download.html) as shown here.
Sqlite3.exe main.db
>.tables
AccountsChatMembersConversationsParticipants
AlertsChatsDbMetaSMSes
CallMembersContactGroupsLegacyMessagesTransfers
CallsContactsMessagesVoicemails
Inspection of these tables will help identify which .DAT files contain relevant data. However, an initial forensic analysis can focus on extraction and review of the material. Example commands for processing the Messages, Transfers, and Calls tables are as follows:
Sqlite>.mode csv
sqlite> .output Messages.csv;
sqlite> select * from Messages;
sqlite> .output transfers.csv
sqlite> select * from Transfers;
sqlite> .output Calls.csv;
sqlite> select * from Calls;
Date-time stamps are exported as Unix numeric values in UTC that can be converted using a utility like DCode (www.digital-detective.co.uk/) or Perl command line:
perl -e "print scalar(gmtime(1243102641))"
Sat May 23 18:17:21 2009
Knowledge of SQLite can also be useful for analyzing the use of Firefox and Google, and may provide access to deleted records (Pereira, 2008).
Even when a file appears to be in a familiar format, it can contain information that requires deeper analysis. In one case, forensic analysis incorrectly concluded that a Microsoft Excel spreadsheet contained no data of interest, not realizing that the default Sheet2 and Sheet3 contained additional data. Keep in mind that printing spreadsheets, which is a common form of production for
Investigative Scenario

Part 8: Skype Chat Log
Skype was used on the subject system for phone calls and Instant Messaging. The last dialed number listed in the Skype config.xml file was 18775425299, which is associated with Night Galaxy, Inc. (www.nightvisionplanet.com), specializing in night vision equipment. In addition, a call was made to 1-866-727-1401, which is associated with the gun sale web site One Click Shooting (www.oneclickshooting.com).
On May 23, 2009 at 2:17 pm, the user engaged in Skype chat with user js-526177 (John Smith) between 2:17 and 2:26 pm. The session was reconstructed from the associated Skype database files using information generated from queries of the main.db SQLite database shown in Table 2.1.
Table 2.1 Skype Chat Log Extracted from main.db File Using SQLite Tool
Unix Numeric ValueDate/Time (Converted)UserNameMessage
1243102641Sat, 23 May 2009 14:17:21 -0400bmoreagentbmoreagentBmore agent here
1243102672Sat, 23 May 2009 14:17:52 -0400js-526177John SmithOperational status?
1243102695Sat, 23 May 2009 14:18:15 -0400bmoreagentbmoreagentTarget selected and all plans in place.
1243102741Sat, 23 May 2009 14:19:01 -0400js-526177John SmithPlease e-mail the target confirmation details to [email protected]. This account won't be checked again after today.
1243102812Sat, 23 May 2009 14:20:12 -0400bmoreagentbmoreagentWill do. All that is needed for execution is final approval and funding.
1243102980Sat, 23 May 2009 14:23:00 -0400bmoreagentbmoreagentHere is a photograph of target location (coordinates lat =“39.286130” lon =“-76.609936”)
1243103004Sat, 23 May 2009 14:23:24 -0400bmoreagentbmoreagentsent file &quot;DSCN3684.JPG&quot;<files alt=“”><file size=“1641245” index=“0”>DSCN3684.JPG</file></files>
1243103084Sat, 23 May 2009 14:24:44 -0400js-526177John SmithAction authorized and approved. Western Union code 170236723-00348. Use the ID card we previously coordinated. Also, you'll need to provide the password “Be3Ready2Serve” to pickup the cash.
1243103190Sat, 23 May 2009 14:26:30 -0400js-526177John SmithReceived image. Target acknowledged.
Another approach to examining this type of information, and validating the completeness and accuracy of the data, is to use virtualization to boot a clone of the subject system and access it as the user would. In this scenario, the Skype chat log was viewed in a virtualized functional reconstruction of the suspect's system as shown in Figure 2.12.
B9780123742674000021/gr12.jpg is missing
Figure 2.12
Skype chat log viewed in a virtualized functional reconstruction of the subject system.
During the Skype chat, on May 23, 2009 at 2:21 pm, the user again accessed the file C:/Documents and Settings/Roman/My Documents/Garmin/gpx/current.gpx.
The Skype configuration file shared.xml contained the text <ContraProbeResults>12.167.154.29:57921 </contraProbe Results>, which is registered with the Emerging Technology Center, 1101 E 33rd St, Baltimore, MD 21218. This information indicates that the suspect connected to the Internet from this location, providing investigators with a potential lead for further information.
review, does not automatically print all sheets unless the application is specifically instructed to print the entire worksheet.
In more complicated situations, when the purpose and meaning of a file is unknown, it may be necessary to perform experiments with the software that created the file. By running the program through controlled tests and observing the effects on the file in question, it may be possible to figure out how to extract usable information from the evidentiary file and/or associated application memory.

Conclusions and Reporting

The most brilliant forensic analysis can be for naught if it is not communicated clearly to decision makers such as attorneys, members of a jury, or executives in a company. In addition to providing the factual basis for all conclusions, it is advisable to summarize key results at the beginning and clearly restate them at the end of a presentation or report. This approach will provide busy, less technical decision makers with the most critical information they need up front, rather than burying them in technical details.
When communicating the results of forensics analysis, let the evidence speak for itself as much as possible, and do not leap to conclusions. Every conclusion should be solidly supported by the evidence in sufficient detail to enable another forensic analyst to repeat the analysis. Since there is always more that
Investigative Scenario

Part 9: Google Document
On May 23, 2009 at 3:09 pm, the user Roman accessed http://spreadsheets.google.com, resulting in the creation of a ccc[1].htm Temporary Internet File, which referenced Funds. At this time, the file C:Documents and SettingsRomanMy DocumentsFunds.ods was created, last written, and last accessed.
The Funds.ods file actually was stored as a Zip archive, and extraction and review of the embedded meta.xml component identified the generator as Google Spreadsheets. Further inspection of the document statistic metadata revealed the Number of Sheets as 3, and Number of Cells as 5. The review of the document statistical information helped confirm there were no “hidden” cells such as white text on white background buried somewhere in the document (e.g., BB:1000). The content of the document was as follows:
Sheet1“Funds Confirmed”
Sheet2“Western Union code170236723-00348”
Sheet3“PasswordBe3Ready2Serve”
Note that the information was divided between multiple worksheets within the file, so looking at only the first one would result in missed information.
can be done in a digital forensic analysis, it is prudent to leave room for further analysis by making a statement to the effect of “Further review and analysis of any of this information is available upon request.”
Forensic analysts often generate a timeline of key findings to help them identify patterns and organize findings to provide a useful summary for litigators. This timeline can be in a tabular or visual form. Figure 2.13 shows a portion of the timeline in a spreadsheet created for the investigative scenario developed for this chapter.
B9780123742674000021/gr13.jpg is missing
Figure 2.13
Timeline of events relating to the investigative scenario developed for this chapter, organized chronologically using Microsoft Excel.
The forensic analyst may also generate a link analysis and association matrix to provide decision makers with a better understanding of important events and interactions between people involved in a crime. For example, Figure 2.14 provides a simple link diagram.
B9780123742674000021/gr14.jpg is missing
Figure 2.14
Link diagram of fictional murder showing communications between prime suspects with time progressing from left to right.
Some link analysis tools can import e-mail and other digital data to help investigators identify patterns and relationships. In some circumstances, it is also appropriate to summarize potential leads and other sources of evidence that may help investigators develop their case.
Investigative Scenario

Part 10: Summary of Forensic Analysis
The seized computer contained minimal and selective use, with relevant activity ranging from approximately February 13, 2009 to May 24, 2009. A timeline of important events is provided in Figure 2.15.
B9780123742674000021/gr15.jpg is missing
Figure 2.15
Viseo timeline diagram of key events in chapter scenario.
The user implemented privacy protection utilities like TOR, and there is further evidence of use of the “wiping” utility BCWipe. Neither BCWipe nor sanitization of Firefox 3 web browsing history was executed immediately prior to acquisition, indicating that the user of the laptop may not have had an opportunity, desire, or knowledge to destroy the data prior to its seizure by the investigative agency.
User activity on the system was extremely limited, possibly indicating a special-use system. However user Internet history revealed activity related to the review of weapons, and searches such as “liquid explosives” and “undetectable bomb”. Combined with research of the Baltimore Inner Harbor and World Trade Center building, an analyst may reach the conclusion that the user was involved in some aspect of a potential domestic terrorist plot.
Numerous potential investigative leads were developed during the limited forensic analysis. Many of these findings would not have been found using simple keyword searches that unfortunately dictate many forensic analyses. Examples include reconstruction of Skype chats, critical Firefox 3 activity, and embedded data in files associated with a GPS device containing the user's Home coordinates and a Skype XML file with IP address assigned to the computer, leading to another location used by the suspect. Furthermore, forensic analysis of Internet activity combined with document metadata from the file meta.xml contained within the Funds.odb Open Office file enabled the examiner to confirm the Funds.odb spreadsheet document was generated online at http://spreadsheets.google.com.
At the beginning of this chapter, we mentioned that our task in the scenario was to determine the target of the attack and identify information that may lead to the identification of others involved in this terrorist cell.
Forensic analysis revealed that a user of the subject computer used privacy protection software, visited weapons related web sites, called night vision device vendors using Skype, conducted searches on terms such as “liquid explosives” and undetectable bomb”, researched the Baltimore Inner Harbor World Trade Center, utilized various e-mail accounts, and engaged in a Skype communication where an image of the WTC was exchanged, a funds transfer was discussed, the target was acknowledged, and final authorization for the operation was confirmed.
Additionally, the forensic analysis identified several additional potential sources of evidence: the USB devices connected to the subject system, the user's and John Smith's Skype accounts, Hushmail account, Gmail account (which includes online created and stored documents), Garmin nuvi GPS device, Nikon Coolpix Digital Camera and storage media, the Gunbroker.com and Western Union accounts, IP addresses, and stored GPS locations.

Summary

Digital evidence can help answer many questions in an investigation ranging from the whereabouts of a victim at a given time, to the state of mind of the offender. Therefore, evidence on computers and networks should be included whenever feasible in crime reconstructions. At the same time, care must be taken when interpreting the abstracted behavioral evidence that is stored on computers. People use technology in creative ways that can complicate the forensic analysis process, particularly when attempts are made to conceal digital evidence. Computers also have many subsystems that interact in ways that can complicate the forensic analysis process. In all cases, given the malleability and multivalent nature of digital evidence, it is necessary to seek corroborating evidence from multiple independent sources. The risk of missing or misinterpreting important details highlights the importance of utilizing the scientific method to reach objective conclusions that are solidly based in the evidence.
References
Alles, E.J.; Geradts, Z.J.; Veenman, C. J, Source camera identification for heavily JPEG compressed low resolution still images, Journal of Forensic Sciences 54 (3) (2009) 628638.
Casey, E, Practical approaches to recovering encrypted digital evidence, International Journal of Digital Evidence 1 (3) (2002); Fall 2002.
Casey, E., Error, uncertainty and loss in digital evidence, International Journal of Digital Evidence 1 (2) (2002).
Casey, E.; Stellatos, G., The impact of full disk encryption on digital forensics, ACM SIGOPS Operating Systems Review 42 (3) (2008).
Casey, E.; Ferraro, M.; Nguyen, L., Investigation delayed is justice denied: proposals for expediting forensic examinations of digital evidence, Journal of Forensic Science (2009); Fall 2009.
Cohen, M., Advance carving techniques, Digital Investigation 4 (3–4) (2007) 119128.
Kurosawa, K.; Kuroki, K.; Akiba, N, Individual camera identification using correlation of fixed patter noise in image sensors, Journal of Forensic Sciences (2009).
McMenamin, J, Gaumer convicted of rape, murder: Prosecutors seeking death penalty for UMBC student, who met victim online, Baltimore Sun (2007).
Murphey, J., Automated Windows event log forensics, Digital Forensics Research Workshop (2007).
Pereira, M.T., Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records, Digital Investigation (2008).

*This chapter extends Eoghan Casey's Reconstructing Digital Evidence in Crime Reconstruction (Chisum W. J. & Turvey B).
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset