After completing this chapter, you should be able to
• Summarize the steps involved in searching and seizing computers, with or without a warrant, under the tenets of the Fourth Amendment and the Privacy Protection Act
• Define consent and voluntary disclosure, and discuss the scope of consent
• Describe drafting the warrant and affidavit, basic strategies for executing computer searches, and explain post-seizure issues
• Describe the Electronic Communications Privacy Act and its effect on electronic surveillance in communications networks, and the differences between content and addressing information
• Describe the role of first responder, the first responder’s toolkit, and provide an overview of how to collect and store the electronic evidence at the crime scene
• Articulate how to get the first response from laboratory forensic staff, conduct preliminary interviews, and document the crime scene
• Explain how to collect and preserve electronic evidence, how to package and transport electronic evidence in a forensically sound manner, and how to prepare a report on the crime scene
• Justify providing a checklist for the first responders, and discuss common mistakes made by first responders
• Define data acquisition and explain the various types of data acquisition systems, data acquisition formats and methods, and how to determine a best acquisition method
• Describe static and live data acquisition, how to acquire RAID disks, and define contingency planning for image acquisition
• Explain the various types of volatile information, provide an overview of volatile data collection methodology, and articulate best practices for acquisition
• List the requirements of disk imaging tools, list various data acquisition software and hardware tools, and demonstrate how to validate data acquisitions on Windows and Linux
This chapter covers activities required in order to seize potential evidence from a crime scene.
Similar activities and techniques may be used during incident response. The incident responder needs to have authorization to perform actions on the possibly compromised machine. Likewise, an incident responder needs to be careful to maintain the state of the compromised machine. Same tools; different objectives.
We’ve been playing a little fast and loose with the sequence of events that you would encounter as a digital forensics investigator (DFI). In a criminal case, the search and seizure phase will take place in several subphases. The phase we’re interested in here is obtaining the permission to search. Earlier, we talked about your arrival at the crime scene and completing your initial evaluation: You have sketched and photographed everything, labeled connections, labeled each piece of electronic equipment, and so on. With respect to authorization to search, four possible situations exist prior to your actual arrival at the crime scene. You have a warrant that covers everything, or you have no warrant at all. Here the issues are relatively straightforward. Two problematic situations arise when you have a warrant, but you’ve discovered a digital device that isn’t explicitly named in the warrant, or you don’t have a warrant and yet you and others believe that there is valuable evidence contained within a particular piece of electronic equipment. Table 5-1 illustrates these decision points.
Table 5-1 Seizing Devices With or Without a Warrant
Remember that when we’re talking about warrants, we’re specifically talking about a criminal investigation. In an enterprise investigation, a different set of rules apply. In some organizations, there is no expectation of privacy. This can arise either because of a company policy that you probably were required to sign and acknowledge, or because of a banner that is displayed as part of a logon process that indicates that anything you do can be recorded or investigated. The human resources and legal departments of your organization are much better prepared to debate the fine points of what is acceptable and what is legal.
EXAM TIP Never proceed in any investigation unless you are sure that you have proper authorization.
Let’s consider the situation where you don’t have a warrant at all. We need to go back to the Fourth Amendment to the Constitution, which states
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
The Fourth Amendment is the foundation of the idea of a right to privacy. The Supreme Court has held that a “‘search’ occurs when an expectation of privacy that society is prepared to consider reasonable is infringed.”1 If you don’t have a warrant, then you must take into account whether the search violates an assumed protection of privacy, and if it does, does the search fall under the provisions of one of the exceptions that exist when a computer is involved? If the search does not violate an assumed protection of privacy, then you have one less obstacle to overcome.
When determining if a computer search is justified, remember that computers usually are considered “closed containers” (such as a briefcase or a file cabinet or a suitcase). This means that you can seize the computer itself, but you will probably need a warrant to actually search the contents of the computer.
TIP A helpful way to determine if a search of a computer is justified is whether the search would be acceptable if you were searching a footlocker, backpack, or briefcase. If it wouldn’t be justified in those cases, you’ll need a warrant.
The courts have ruled that searches can be carried out if there is probable cause to believe that the search would provide evidence of a crime or contraband. However, the Privacy Protection Act (PPA) states that search and seizure must be authorized by the Justice Department if there is a chance that materials could be seized that are protected under the First Amendment, and the person is not suspected of participating in criminal activity for which the materials are sought. When applied to the search and seizure of digital devices, however, issues can arise if the computer is used for the publishing of protected speech, and because evidence may be commingled with other items that are protected.
There are several exceptions to the rule of privacy violation. First is the issue of consent. You can ask the suspect for consent to search their computer or other electronic device. Alternatively, you may conduct a search if someone in authority has given consent, although this consent may limit the scope of your investigation. Consent of a third party occurs when someone gives consent and is considered a partial owner or user of the digital advice. Based on the Matlock decision,3
[…] a private third party may consent to a search of property under the third party’s joint access or control. Agents may view what the third party may see without violating any reasonable expectation of privacy so long as they limit the search to the zone of the consenting third party’s common authority.4
You may also mount a search if there are “exigent circumstances.” These exigent circumstances occur under the following conditions:
• There is an immediate danger that the evidence can be destroyed.
• A threat exists that puts the police or the public in danger.
• The police are in “hot pursuit” of a suspect.
• The suspect is likely to flee before the authorities can get a search warrant.
The first circumstance is usually the most compelling when applied to computer searches because computer data is extremely perishable: Digital data can be encrypted, and whole drives can be deleted with a single command (“rm -rf /”). Electronic components can be damaged by water, heat, magnetism, or blunt objects. Information could be lost due to the lack of battery power, or because new data may overwrite old data. An interesting issue surrounding exigent circumstances is that you can seize a device because of exigent circumstances, but you may not be justified to search it later. In this instance, a DFI would need to actually obtain a search warrant.
The “plain view” doctrine holds that if something is clearly visible (sitting out in plain sight), then you are able to access that digital device without consent of the owner. Two conditions must apply, however: You must be in a lawful position to observe and access the evidence, and the fact that it is incriminating evidence must be readily apparent. You can’t use the plain view doctrine to open a container that you wouldn’t have been allowed to open otherwise.
Finally, after a lawful arrest, you can search the arrested person and search the surrounding area. The courts have generally ruled that a search incident to a lawful arrest applies to portable electronic devices, such as pagers, cell phones, personal digital assistants, and others.
Inventory searches occur after law enforcement has seized a particular digital device. Law enforcement officers routinely inventory the items they have seized. These searches are considered reasonable if the search serves a legitimate, noninvestigatory purpose (such as protecting an owner’s property when in custody), or to keep the police from danger. For this reason, searching computer disks or files is not usually covered under this exception, and a warrant is required.
Border searches have become quite contentious of late. In some instances, travelers have had electronic equipment seized and searched without their explicit permission and in the absence of a specific warrant. Although this may be something of a surprise, the courts have found that border searches are exempt from Fourth Amendment protection. This applies to U.S. citizens as well as foreign nationals.
Finally, international searches will require the participation and consent of the appropriate authorities in the country where the computer is located or where it is believed that the crime has occurred. Contacting a foreign Internet service provider (ISP), for example, might require prior permissions of the foreign government, the approval of the Department of Justice’s (DOJ’s) Office of International Affairs (OIA), and with clear indications that such contact would not be objectionable in the country in question.
Workplace searches have their own set of constraints, depending on whether the workplace is part of the private sector or the public (government) sector. Private sector searches without a warrant are usually acceptable if you’ve obtained consent from the employer or the employee who has authority over the area to be searched. In the public sector, a government employee has a reasonable expectation of privacy in their workplace, unless the searches are “work-related, justified at their inception, and permissible in scope.”5 However, searches may raise issues under the Stored Communications Act, 18 U.S.C. §§ 2701–2712 or Title III, 18 U.S.C. §§ 2510–2522. More on these later in this chapter. Take note, however, that official policy or a login banner may alleviate the expectation of privacy.
TIP If you’re acting in a security role at an organization, establishing that the employee has no reasonable expectation of privacy up front can make your life easier when it comes time to perform forensic analysis or mount an investigation. It’s better to establish this at the onset rather than try to implement this after the fact.
If you are on the scene and you have a warrant, you needed to go through several steps prior to this. In order to get the warrant, you had to appear before a judge and assert that there is probable cause to search a particular person or location and to seize certain kinds of property.
When drafting the warrant, make sure that the property to be seized is described accurately and with enough detail that the property can be distinguished from other kinds of property. A “laptop computer” might not be specific enough, while “a dark-blue MacBook Pro with a sticker on the front that says ‘Apple Rules!’” probably would uniquely identify a particular device. You can specify the property within the warrant itself, or as an attachment to the warrant. The more specific you are, the better your ability to defend against courtroom challenges based on the description of “things to be seized.”
The place to establish probable cause is in the affidavit written in support of the warrant. In the affidavit, include an explanation of your search strategy and the details of the practical and legal considerations that will govern the actual search.
There are three general strategies for performing a computer search when you have a warrant. The first strategy is when the digital device is itself contraband—such as when the computer stores child pornography or the computer itself is stolen property. The second strategy is when the digital hardware is just a storage device for the evidence of a crime, as evidenced by documents, log files, or browsing history. Last, as described by the U.S. Office of Legal Education, a computer can be an “instrumentality of the crime”4: the computer was used as a tool in carrying out the crime, such as distributing illegal materials, hacking into a company’s computers, or spying on someone without their consent.
Computer searches aren’t always about the documents stored on the computer. In some instances, the search may attempt to demonstrate that a particular individual was using the machine at a particular time or shortly thereafter to check the results, such as a bank balance. It may be necessary to indicate that no viruses or malware were present on a computer and couldn’t have performed actions on the network of which the user was unaware. Finally, the search may attempt to show that the user had knowledge of a particular subject based on browsing history or on materials downloaded and then deleted.
If you need to search various network locations, you may need multiple warrants in order to achieve this. Jurisdiction comes into play depending on if the data are stored locally, within the United States, or outside the boundaries of the United States. In the first two instances, you should try to get a warrant to search the machine where the data are stored. Things become much more complicated, however, if the data are stored remotely outside of the United States. If you didn’t know and couldn’t know that the machine was physically located outside of the United States, you may still be able to present the evidence in court.
Once we move into the area of network searches, we run full-tilt into a different set of privacy concerns.
The Electronic Communications Privacy Act (ECPA)–sometimes referred to as the Stored Communications Act (SCA) [18 U.S.C. §§ 2701–2712]–sets up regulations concerning how the government can obtain stored account information from network service providers.
EXAM TIP Know that the ECPA (18 U.S.C.) regulates what the government can obtain from network service providers.
In the case of Internet communications, ISPs provide a local connection to the Internet. One way to classify providers is whether they provide “electronic communications services” or “remote computing services.” An electronic communications service (ECS) allows its users to send or receive wire or electronic communications. A remote computing service (RCS) provides computer storage or processing services to the public via an ECS. Information stored by an ECS or an RCS is of three kinds: contents, noncontent records about the subscriber or customer, and basic subscriber and session information. Subscriber and session information contains information that you would normally associate with billing information (name, address, length of service, and payment information). Records or other information about the customer is information that is neither subscriber information nor contents. Examples of this would be e-mail addresses of people with whom the customer has communicated and account usage records. Finally, contents are the actual data (files) stored in the account. As you might suspect by now, contents can be either “electronic storage” or content stored by an RCS, where electronic storage refers to temporary storage of information about the transmission of data and not the stored content of that communication.
NOTE However, the courts have ruled that e-mail that is stored by a mail server prior to its being accessed by the recipient is “electronic storage.” Remember that this isn’t about technology; it’s about the law.
Under the SCA, providers can be compelled to disclose the contents of electronic storage and stored records. This usually means that you need a subpoena, a court order, or a search warrant. However, if the service provider doesn’t provide services to the public, then that provider can freely disclose contents and other records. For a provider of public services, if the provider is willing and able to voluntarily disclose this information, then there is no need for law enforcement to compel that disclosure.
When working with network providers, communicate often and early, and understand how that particular provider operates. As a member of law enforcement, you can order the provider to preserve existing records before actually getting the legal authority to seize those records. Nevertheless, you can’t ask a provider to preserve records that haven’t yet been created, and it may be the case that collecting these records may warn a suspect—hence, the need for often and early communication with that provider.
We’ve already mentioned the Wiretap Statute (Title III) 18 U.S.C. §§ 2510–2522 and the Pen Registers and Trap and Trace Devices of Title 18 (the pen/trap statute) 18 U.S.C. §§ 3121–3127. Recall that the pen/trap statute regulates the collection of addressing and noncontent information, while Title III regulates the collection of actual content.
The key issue that all these statutes address is the difference between content or addressing information, also called metadata. Consider monitoring telephone traffic. Addressing (metadata) information would include the calling number, the called number, and the duration of the call. The actual conversation is content. In the case of Internet communications, the source IP address, the source port, the protocol, the destination port, and the destination address would be considered addressing information; the actual data portion of the communication (the payload) would be considered content. Figure 5-1 shows the different layers of the seven-layer Open Systems Interconnection (OSI) network model that would be considered content as opposed to addressing information.
Figure 5-1 OSI protocol stack: addressing information and content
You can apply this distinction at higher levels in the protocol stack as well. When doing e-discovery on e-mail messages, header information such as the sender, the recipient, the length of the message, and the time the e-mail was sent is addressing information. The actual body of the e-mail is content, as is the subject line. Similar provisions apply for Short Message Service (SMS) messages, text chat, and others.
NOTE In a potentially landmark case ruling in September 2013, a federal judge, Judge Lucy Koh of the Northern District Court of California, “ruled that Google [the search engine enterprise] may be violating wiretap law when it scans the e-mails of non-Gmail users, allowing a lawsuit against the company to move forward.”6
Title III uses a broad brush to prohibit the interception, use, or disclosure of communications, unless a statutory exception applies. As you might expect, there are a number of statutory exceptions. One such exception is “bannering and consent.” If you present a network banner to a user upon access to the network that informs the user that using the network means they consent to having their traffic monitored, then there is no violation of Title III. The provider exception says that an employee or agent of communication services can disclose communication if the provider’s rights and properties are in jeopardy. Finally, the “extension telephone” allows a company that provides an employee with a telephone extension for remote work to monitor that line without violating Title III. Other exceptions affecting computer crime and evidence are the “computer trespasser” exception, the “inadvertently obtained criminal evidence” exception, and the “accessible to the public” exception.
If Title III is violated, then wrongfully intercepted oral and wire communication can be suppressed, but not electronic communication. Constitutional violations can have the same result. Interestingly enough, violations of the pen/trap statute provide no suppression remedy.
A major consideration for evidence is that it is authentic, which is a short way of saying that it is what it says it is. When applied to digital devices, authentic evidence is the same as authenticity with other kinds of records. A witness who testifies regarding the authenticity of computer records does not need special qualification; rather, the witness must have first hand knowledge of “what the data is and how it was obtained from the computer or whether and how the witness’s business relies upon the data.”4
Computer-generated records may require more detail, but, generally, the reliability of the computer program that generated those records can be shown by demonstrating that the users of the program depend on the records so generated in the normal course of business. Once a minimum standard of trustworthiness has been established for the computer program, the focus is on the weight of the evidence and not whether the evidence is admissible.
Let’s assume that the searching and seizing portion of the investigation completed successfully. You will still need to address several post-seizure issues. One of these issues is the return of property, as established in Rule 41(g) in the Federal Rules of Criminal Procedure (FRCP).
Seizing someone’s computer equipment may hurt that individual’s legal and legitimate business, so you won’t have infinite time to investigate. In addition, you may only have one chance to actually collect information from that device, so it’s a good idea to take what you need in the beginning because that may be your only chance.
This leads us to the question of how long you can take to examine a seized computer. In essence, there is no upper limit and no explicit limit on how long it can take to perform the search, although the Fourth Amendment does imply that the search must be performed within a “reasonable” time.
Beginnings are always difficult. Some people say that your first five seconds create an initial impression that’s difficult to shake. The same principle still applies when you arrive on the crime scene as the DFI. Getting things right from the beginning is critical to collecting the right evidence and preserving it for investigation, and mistakes that you make then will linger throughout the investigation.
Who exactly is the first responder? One candidate is the first person to arrive on the scene, who may not be a member of law enforcement. The other candidate for the role of first responder is the first DFI on the scene, who is qualified and trained in gathering electronic evidence. In the rest of this chapter, you can assume that the first responder is the first DFI on the scene. The goal of any effort prior to the arrival of the DFI is to protect the digital evidence, which means that other members of your law enforcement team or your systems and network administrators in an enterprise need to be trained on what to do and what not to do when confronted with sources of digital evidence.
The first response rule is to preserve the crime scene and the evidence, regardless of who actually discovered the incident. If we are working on an enterprise investigation, a system administrator may be one of the first people to notice that a breach or questionable activity is occurring. System administrators should be trained to contact your organization’s Computer Security Incident Response Team (CSIRT) or the Computer Emergency Response Team (CERT).
Regardless of affiliation, a first responder should perform the following tasks as suggested by NIJ:7
• Secure all electronic devices, including personal devices.
• Prevent unauthorized individuals from accessing any electronic device.
• Refuse help or assistance from any unauthorized person.
• Remove everyone from the area where evidence will be collected.
• Maintain the state of any digital device: If it’s on, leave it on; if it’s off, leave it off.
Non-law enforcement cases usually take the form of an incident response. Someone, either from the organization’s CSIRT or from senior management, will decide how to respond to this particular incident. At this time, nonforensic corporate staff may arrive to take over the scene. If an attack has occurred, it’s time to initiate an attack response, which has four phases: mitigation, notification, investigation, and resolution.8 As a DFI, we’ll be most involved in the mitigation and investigation phases. If law enforcement is going to be involved, then our job as a forensics specialist is to protect the digital evidence from destruction. If law enforcement or outside professionals won’t be involved, then it will fall to us to collect the evidence from memory and from disk in a forensically sound manner. As usual, be sure to document your actions and the results. This would be true regardless of whether we are performing as a forensics expert or as a member of an incident response team. Remember, though, that a full incident response will also involve notification of required parties or involved parties, and mitigation will fall to systems administrators and network and systems security professionals within your organization. This leads us back to the difference between a forensics investigation and incident response. Recall from our first chapters that incident response and digital forensics investigations may use the same tools, but the aims of each activity are different.
NOTE The lines between incident response, digital forensics, and malware analysis are blurred. For me, I distinguish among them as follows. If I’m determining if there has been a security breach, I’m performing incident response. If I’m collecting persistent data and transient data on a particular device, I’m performing digital forensics. If I’ve determined that the incident involved downloading malware, and I’m investigating how that malware operates, I’m doing malware analysis. You may take on all these roles in the course of the computer hacking forensics investigation.
When you arrive on the scene as a DFI, have a quick conversation with the people who first arrived on the crime scene. Assure yourself that all efforts have been made to secure the crime scene and preserve the evidence. After you’ve completed this initial conversation, take a moment to capture the details. Given what you’ve learned, review your risk analysis findings and your notes on what to look for and what to do with it… memory joggers are always beneficial, and they will help you complete your checklist. Make sure you bring the results of your risk analysis. Knowing what to do in the event you have to make choices about what evidence to collect first can save valuable seconds. Finally, a checklist like this lets you know when you’re done.
CAUTION Don’t let a checklist blind you to other possible sources of information or activities warranted due to special circumstances.
Once you’ve made sure that the evidence has been preserved, you can now begin the process of actually searching or seizing the evidence. The first step to take is to conduct preliminary interviews with people on the scene, including witnesses and possibly the suspect as well. Any adult present at the crime scene should be isolated for further questioning after recording their location at the crime scene when you arrived.
TIP It’s worth repeating: No one should be allowed to access any digital device at the crime scene except an authorized professional. Period.
Before beginning the interview, quickly review your agency’s policies regarding interviews, as well as local, state, and federal laws. Within these parameters, gather the following information:7
• Names of all users of the computers and devices.
• All computer and Internet user information.
• All login names and user account names, and all passwords, including systems administrator or application administration accounts.
• Purpose and uses of computers and devices.
• Any automated applications in use. This can include remote services that may back up and delete material from the computer or scheduled tasks on the computer itself.
• Type of Internet access (LAN, WAN, dial-up).
• Any offsite storage, including cloud accounts such as Box, Dropbox, and others.
• Internet service provider. This is especially important if you anticipate that you will need to subpoena the ISP for traffic records.
• Installed software documentation. This can aid in your investigation, especially if the software in use is specific to a particular occupation or industry.
• All e-mail accounts used locally.
• Security provisions in use. Is the device running an antivirus product (including malware detections), a local firewall, a proxy server, or other software?
• Web mail account information, both personal and business.
• Data access restrictions in place. Are certain data storage areas restricted to the computer owner?
• All instant-message screen names. Remember that many instant messaging clients also support file transfer.
• All destructive devices or software in use. Does the owner have access to programs that can wipe the disk in the computer?
• MySpace, Facebook, Tumblr, or other online social networking web site account information.
• Any other relevant information that you’ve identified as part of your preliminary investigation.
In the case of the suspect, one of the first tasks is to gain consent from the suspect for the search itself. This is especially important if there’s a piece of evidence that’s not covered by the warrant. If the suspect agrees, have them sign a consent form. Figure 5-2 is an example of such a form.
Figure 5-2 Sample consent form (Source: Searching and Seizing Computers and Obtaining Evidence in Computer Investigations (Washington, DC: DOJ, 2008), p 253.)
In the case of witnesses, make sure you ask them in a preliminary interview details about the digital equipment and its use. Was the computer turned on? Could they see what was on the screen? Was the printer active? Was the suspect using a scanner? Was the suspect removing or moving portable storage devices (USB thumb drives, USB external drives)? Make sure that you have the witness sign their description after you’ve completed the interview.
Documenting the crime scene will take several forms. I think of this as the “helicopter zoom.” First is the “30,000 foot view”; in this case, you might use a video camera to do a 360-degree view of the crime scene, or at least a series of overlapping still photographs. These should be taken from the perspective of someone entering the room. After doing that, however, create a hand-drawn sketch of the crime scene as well, both as a check on the video and as a backup should the video be unwatchable (remember the cell phone in the toilet scenario). After documenting the overall crime scene, create still photographs of each piece of digital equipment, including the tags that you’ve already placed on various cabling and external devices. At the end of this process, you should have the following:
• A 360-degree video of the crime scene, accompanied by a hand-drawn sketch of the entire crime scene with appropriate handwritten annotations
• A photograph of each individual piece of equipment, including tags and labels, again, accompanied by handwritten notes and annotations
TIP Consider creating your own forensic copy of these images and notes and storing them away in a local and a remote archive. This may mean scanning your handwritten notes and copying your videos and still photographs. Disk space is cheap, remote storage is cheap, and is much less than the cost to your investigation if this information should be lost or destroyed. Remember the old adage: The job isn’t finished until the (digital) paperwork’s done. Make sure that your materials are encrypted using strong encryption (AES-256 is a good choice), whether stored locally or remotely, and ensure that you take appropriate steps to physically secure the information.
The next step is actually collecting the evidence. If we’re lucky, all the electronic devices are powered off so you can just put them in evidence bags, label the bags appropriately, attach the appropriate chain-of-evidence forms, and head out for an early lunch. Unfortunately, things often don’t turn out that way.
As we’ve said a number of times, a best practice is to leave the device in the state that it was in when you initially discovered it. If it’s off, leave it off, and prepare the device to be collected as evidence. If the device is running, leave it running. Photograph the screen to record what was visible when you entered the crime scene.
If the machine is running, you’ll need to determine if a live acquisition is necessary. It’s probably safe to assume that in most cases a live acquisition will be necessary. The first principle to apply here is to collect the most significant volatile data first, in the order of difficulty. Table 5-2 compares volatility and the ease of retrieving the data, and assumes that this information is critical to your investigation.
Table 5-2 Volatility and Difficulty Collecting Information
This is low-hanging fruit: Get the most critical volatile data first that is easiest to collect. If it’s of low value and difficult to collect, leave it until last.
Volatile information in a computer looks like this, from most volatile to least volatile:9
• Registers and cache
• Routing tables, process tables, kernel statistics, and memory
• Temporary file systems
• Disks or other storage systems
• Remote logging and monitoring data related to the system we’re investigating
• Physical configuration and network topology
• Archival media
Temporary file systems also can be a source of valuable information. In some cases, all files on the temporary file system may be deleted automatically at system startup; in other cases, temporary files may only be deleted by an explicit user command. If you’re doing a live collection, make sure you capture the contents of the temporary file system before initiating shutdown.
Networked computers (almost everything these days) pose their own special problems. We’ll discuss this later on in this chapter.
Portable computers (everything from netbooks, laptops, smart phones, and tablets) require that you pay attention to battery life. If you need to capture live data from a portable device that is currently running on battery power, you will need to plug the machine in to an appropriate recharging device, which is why you have several different kinds of charging devices in your forensics toolkit. If the device is powered off, however, just remove the battery—this will prevent the device from being powered on later, when the loss of data from startup processing is possible.
If the device is on, then we treat the portable computer as we would a desktop system. If the machine is in sleep mode and then wakes up, record when this actually occurred. Pull the battery from the device, and then pull the power cord (if you do it in reverse order, the machine may fall back to battery power). If you can’t pull the power cord, holding down the power switch for five seconds or longer will usually power off the device.
CAUTION We are trying to prevent automated processes from running that may delete important information, which is why literally pulling the plug is appropriate. The same conditions don’t apply when working with virtualized machines, however. A normal shutdown or kill command may result in the machine automatically rebooting if configured as such (the machine requires high availability). In this case, the virtualization vendor usually provides commands that will simulate a “pull the plug/power off” scenario.
Shutdown procedures vary depending on whether you have access to the console (allowing you to possibly log on as an administrator) and the machine’s operating system. For Windows machines, the best shutdown procedure is literally pulling the plug at the wall socket. For Linux/UNIX machines, issuing the command
sync; sync; halt
will flush all unwritten data to associated storage devices or communication channels and then halt the machine. Failing access to the console with root (administrator) access, pull the plug. For Mac OS, accessing the shutdown option from the Special menu will perform a graceful shutdown; otherwise, pull the plug.
At this point, all our digital devices are shut down except for those that we wish to keep running, and we need to start bagging the evidence. Each evidence bag should have a contents list attached. We saw an example of that in a previous chapter in our sample chain-of-evidence form. One of the important elements on this list is the exhibit number. The EC-Council lists one method of creating this exhibit number10 as aaa/ddmmyy/nnnn/zz, where
• aaa are the initials of the investigator.
• ddmmyy is the date when the evidence was acquired.
• nnnn is a sequence number of exhibits seized by the investigator, starting at 0001.
• zz is the sequence number for different parts of the same exhibit. A1 might be the computer, B1 might be the keyboards, C1 the monitor, D1 an attached universal serial bus (USB) drive, and so on.
Therefore, for example, an evidence bag with the exhibit number clb/21082013/0001/A1 might be the first exhibit seized by the investigator with the initials “clb” on August 21, 2013. This bag contains the first element of one part of the associated exhibit.
Once the evidence is “bagged and tagged,” it’s time to actually transfer that evidence to the forensics laboratory (or to an evidence locker or storage room). The key to successful transport and storage of evidence is anticipating and understanding the varying conditions that will be encountered between the original location of the evidence and its final location.
Let’s reflect for a moment about what we’d consider to be a suitable storage area for digital evidence. The space would be climate controlled: neither too hot, too cold, too dry, or too damp. Evidence would be stored away from magnetic fields, in a place where it wouldn’t be bumped, jostled, kicked, or dropped. If the equipment is meant to function in a particular position, we would store it in that position (we probably wouldn’t store a printer face down, for example). We wouldn’t want a place that was very dusty (clogging ventilation hose), nor a place where the digital evidence and the containers would be exposed to direct sunlight (sunlight can do a number on plastic—think about that CD you left on your dashboard last summer).
We’ll assume that the digital equipment and its evidence was okay where we found it. Our challenge, then, is to maintain these kinds of conditions when we transport the evidence. We will need to pay attention to heat and humidity to prevent overheating or condensation. We’ll need to pack the equipment so that it will remain relatively stationary when moved (I always like to use the original packaging if it’s available). Foam peanuts, bubble wrap, or crushed newspaper can all act as padding. If possible, follow a route that minimizes potholes and speed bumps; if that isn’t possible, then drive as slowly as you can. Don’t stow the equipment in the trunk if you have equipment back there that generates electromagnetic radiation. Rendering your digital data useless in transport isn’t going to win you any friends. Treat it like you did Aunt Bluebelle’s precious tea set that she brought back from England in ’59.
The crime scene report should document the work you did when you appeared at the crime scene. The report should describe the location of the electronic devices, whether on or off, what was on the screen, who had access to the device, and so forth. The report should illustrate the crime scene using the photographs that you took as part of your initial examination.
Remember that this is a factual description of what you observed. Don’t record your questions or observations that you may have written down as notes to yourself. Stick to the facts.
Prepare a checklist in advance for first responders. Any forensics lab staff that are expected to appear at a crime scene representing the lab should have been trained on the actions and needs associated with each item on that checklist. The checklist has two functions and answers two questions: what do I do, and did I do it?
Things can go wrong even with the best of intentions. Remember that familiar statement: “Mistakes were made.” Mistakes can be made by not doing something that was required (sins of omission) or by doing something that wasn’t required (sins of commission). Consider all the steps that we’ve covered in this section, and consider the opposite. Evidence wasn’t identified, evidence wasn’t properly tagged, evidence wasn’t labeled regarding cabling, evidence wasn’t collected properly, evidence wasn’t protected properly for transport.
Don’t forget the two great laws of digital forensics: Leave the device in the same state as when you discovered it, and document everything. Common mistakes that first responders make include violating one of these cardinal rules. Volatile data were lost because a machine was either shut down or rebooted. A particular step or a particular piece of evidence wasn’t documented or was documented improperly. Potential evidence was overlooked because the individual wasn’t familiar with that particular machine. The evidence wasn’t packaged securely for transport. And so forth.
At this point in the investigation, you’ve legally obtained the digital devices that contain the electronic information that you wish to analyze. The next question is how do you actually get access to this information in such a way that you don’t render the material useless as evidence (the legal term for this is spoliation)? How can you be sure that the material you’re working with is the same as the original electronic information?
Data acquisition is the process whereby we collect data and add that to our evidence. Data duplication is simply creating a true copy of digital evidence obtained from a particular digital container. What makes this interesting is variation in the source and destination of the data. There are three options:11
• Disk-to-disk In this instance, this is a straight disk-to-disk copy. The source and destination are two separate hard disks. Obvious restrictions are that the destination drive must be at least as large as the source drive. An example of a disk-to-disk copy when using the Linux operating system (OS) would be
dd if=/dev/sda of=/dev/sdb blocksize=1024
We’ll talk about other options in Chapter 7 when we talk about conducting a forensic investigation.
• Disk-to-image In this case, a drive is copied from one computer system to an image file on another disk. This image file can be used as input to one of our digital forensics tools, or it can be mounted so that it appears as a disk drive on the local machine. One technique for doing this when using Linux OS is
dd if=/dev/usb of=/var/evidence/case123/usb1.img
• Create a sparse data copy In this instance, only a portion of the associated data that are directly associated with an investigation is copied. This can be the case when the source storage is much larger than the relevant material. One such example is acquiring data from a redundant array of independent disks (RAID) array. The actual size of the disk associated with the storage array may be on the order of terabytes or petabytes. In this case, simply making a copy of specific directories will speed up the process and ensure that the pertinent evidence is manageable.
CAUTION A copy of files from one file system to another is not a forensic copy. A forensic copy is a bit-for-bit duplicate or clone of the original storage device. A file system–level copy won’t copy deleted files, for instance, nor will it copy files used solely by the file system.
Which acquisition method is the best? All other things being equal, data should be acquired at the physical level of the disk drive—that is, a block-by-block, bit-by-bit copy of the source drive. This ensures that we see everything on the disk. A file system copy, as in the case of a sparse data copy, requires that we use the file system as an intermediary, and the file system only sees what it is meant to see. A file system copy, for example, will not copy slack space within the drive; it will only copy the number of bytes that are recorded as the file length. If the file block size is 1,024 bytes and the file length is 457, only 457 bytes will be copied to the new file.
TIP You can save yourself some pain and heartache if you ask your client as part of your initial interview what kind of computer equipment you can expect to encounter at the scene and whether or not the data need to be collected on site, or if the drives can be taken back to the lab.
Some data acquisition systems do not require the assistance of a full forensics workstation, but instead can simply copy one disk to another, often at high speed. Remember, too, that once you’ve acquired the data, you’ll want to make a copy of that copy, so now you have the original, the master copy of the original, and your working copy. This is especially important in the case where the original needs to be returned to its owner in a short time period. Making a copy of the original is a contingency plan in case the original should become corrupted. Likewise, using two different data acquisition tools to access the digital device serves as validation that all the data were collected.
Some common data acquisition mistakes are simply to forget to collect some particular evidence, or to neglect to make a copy of the copy, or to create a copy of the original that doesn’t contain all the information you need for your investigation (for example, you create a file copy that doesn’t reflect files deleted on the original). Other mistakes are12
• Shutting down before you’ve completed evidence collection. Evidence can be lost and the attacker may have altered the startup/shutdown scripts/services to destroy evidence.
• Trusting the programs on the system. Run your evidence-gathering programs from appropriately protected media.
• Running programs that modify the access time of all files on the system (e.g., tar or xcopy).
• Disconnecting or filtering from the network. As tempting as it is, this may trigger “deadman switches” that will detect that the machine is off the network and will wipe evidence.
Required features for a disk-imaging tool are best taken from the National Institute of Standards (NIST) Digital Data Acquisition Tool Test Assertions and Test Plan. This test plan is part of NIST’s Computer Forensic Tool Testing Program (CFTT), found at www.cftt.nist.gov. The test plan lists the following requirements for a disk imaging tool:
• The tool uses the specified access interface to access the digital source.
• The tool acquires the specified digital source.
• The tool executes in the specified execution environment.
• The tool creates a clone of the digital source if clone creation is specified.
• If image file creation is specified, the tool creates an image file on the specified file system type.
• The tool acquires all visible sectors from the digital source.
• The tool acquires all hidden sectors from the digital source.
• The tool accurately acquires all sectors acquired from the digital source.
• If unresolved errors occur while reading from the selected digital source, the tool notifies the user of the error type and location within the digital source.
• If unresolved errors occur while reading from the selected digital source, the tool uses a benign fill in the destination object in place of the inaccessible data.
There are multiple optional features listed for tools. In the case of data acquisition tools, 24 optional features are listed, broken out by image file, clone creation, log file creation, and acquisition of data without a write-blocker. This optional feature states, “If the tool executes in a forensically safe execution environment, the digital source is unchanged by the acquisition process.”13 This is especially important if you will need to restore the digital device and its content to the owner.
Static acquisition (sometimes called “dead” acquisition) is the process whereby the investigator creates an image of persistent storage. This could be from a disk drive taken from a particular machine, a Secure Digital (SD) card, a USB drive, a USB pen drive, or any other kind of persistent storage.
You can acquire static data by several different methods. One method is to boot the computer using a different operating system. The disks from the evidence machine will be discovered and mounted (read-only) on the acquiring machine. The acquiring OS will run entirely from memory, or from memory and a storage device (a CD-ROM or a USB storage device). Either the data copied from the disks from the evidence machine can be copied to an acquisition drive mounted on the evidence machine, or they can be transferred over a network to an acquisition machine that then writes the data to an evidence disk. We’ll see examples of this later on in this chapter.
Live data acquisition, in contrast, is gathering information from a running system. We will extract information from persistent storage, but we will also capture volatile information; that is, information that will disappear when the computer is shut down, such as the contents of memory, the state of network connections, who is logged in to the machine, and other information.
Which information should you collect first? A couple of rules of thumb come into play here. First, which information is most critical to your investigation. Second, which of these data is most volatile, that is, is most likely to change the soonest. When we combine these heuristics, we see that we need to capture the most volatile and the most critical information first, while the least volatile and least critical will have to be put off until later. The following list contains items ranked in order from most volatile to least volatile:14
• CPU, cache, and register content
• Routing table, Address Resolution Protocol (ARP) cache, process table, and kernel statistics
• Memory
• Temporary file system/swap space
• Data on hard disk
• Remotely logged data
• Data contained on archival media
Let’s consider the following example. We are investigating a running machine connected to a network. Should we collect a list of running processes first or the list of network connections? The answer is that we should consider which information has the most bearing on our case. If we believe that network information is most critical, we can collect that first. If, on the other hand, we think that the set of programs running on the computer is most critical, then we would go ahead and collect that data first.
You can use many of the standard programs on any particular OS to gather information about the state of that particular computer. Using these tools will leave their mark: Every exchange leaves a trace. Make sure that you record what you ran on the suspect machine and when, and know what changes this software will make to the underlying file system or in memory.
Don’t neglect the actual capture of the contents of memory from the suspect machine. Some machines will allow you to collect data directly, while other machines require you to use a special program (which is part of your forensics toolkit). Other software can read and interpret the contents of memory to reveal what programs were running and what connections were open, both internally and externally. Having a disk containing system tools for either Linux or Windows as part of your investigation toolkit can help you perform these collections, and running from a read-only medium can ensure that these tools aren’t infected if malware is on the suspect machine.
Disk imaging tools have one job to do: create an exact duplicate of the source device to the target. Regardless of how much we trust our tools, an abundance of caution requires us to validate our acquisition. We do that by taking advantage of algorithms that are sensitive to a one-bit difference in a particular file. As we saw in Chapter 4, several cryptographic hash functions are in use today. They include MD5 (still used, but deprecated), SHA-1 (produces a 160-bit hash values), and SHA-2, a set of functions (SHA-224, -256, -385, and -512) introduced in 2001 after a mathematical flaw was discovered in SHA-1.
Linux and Windows validation methods are very similar. In both cases, the goal is to demonstrate that the two data copies are identical. Either you can validate the data after acquisition, or you can validate as the data are actually copied. This enhancement saves a second pass through the original and the copy. Linux and Windows systems both can utilize the md5sum, sha1sum, sha256sum, and md5deep utilities, although you will need to download these files or utilize a forensics software distribution. md5deep will recursively descend a directory structure, generating a digest for each file found. Although the package is named md5deep, multiple algorithms are supported, including SHA-1 and SHA-256. In comparison mode, md5deep can accept a list of known hashes, compare them against a set of input files, and list ones that either match or do not match, depending on the nature of the set of known hashes.15 hashdeep can compute, match, and audit hash sets, and can report on matched files, missing files, moved files, or new files not found in a particular set.
The old model for acquiring data was based on a model of how disk drives worked at that time. Suffice it to say here that this model has been supplemented (and in some cases replaced) by different storage technologies. We’ll take a quick look at three of them here: RAID, solid-state devices (SSDs), and the cloud.
RAID originally was an acronym for “redundant array of inexpensive disks,” although this is usually translated nowadays as “redundant array of independent disks.” RAID structures can be created on a single workstation with multiple drives, or as an external storage system.
Acquiring RAID devices can pose problems for the investigator. If the RAID is contained within the local machine, then the problem is slightly easier, in that it’s just a matter of seizing the local machine. Even if the array is external to a particular machine, it may still be portable, in that it makes sense to actually seize the entire device.
One problem is that the larger the array and the more people are using it, the greater disruption to the enterprise. In some cases, losing the storage array may shut down the entire business. A second problem is that if you are bringing the disks back for investigation, you need to ensure that you have the appropriate software to actually reconstruct the RAID from the disks, and this may be difficult to do, especially if the RAID format is proprietary.
Solid-state devices appear to the file system like regular disk drives, but they’re not. In fact, they are more like computer memory (hence the term “flash drives”). At the physical level, they are very different. An SSD disk block can only be written to so many times before it becomes unreadable. To avoid this, the driver software will write a modified block to a new physical address, thereby spreading use across the disk surface. This freed block may be immediately zeroed out by the driver so it can be reused.
The cloud presents just two problems for digital forensics, but they are significant. One is simply finding the data. The other is retrieving it from the cloud provider. Assuming that the data are stored on a remote machine, many of the problems resolve to those associated with any remote machine. Getting network data and log data from that particular machine may be difficult, and is even more difficult if the original remote machine image has been deleted.
NOTE Information that is stored as part of the remote machine image (for example, C:\ on Windows) will be deleted once the machine image is deleted. Externally defined data can persist after the machine image has been deleted and can be reattached to a new instance of that virtual machine.
Recall the discussions required when attempting to get data from a remote provider, and consider the difficulty arising when the storage, computer, and memory resources have been returned to a common pool of reusable resources. The question of jurisdiction is further complicated because cloud providers may not actually store data on the same physical machine. The data can move from one physical machine to another in the same data center, and may even move to a second data center that is geographically removed from the first data center (even in another state or another country).
As we’ve already mentioned, the big three of digital forensics frameworks are
• Forensic Toolkit (FTK) from AccessData
• EnCase from Guardian Software
• The Sleuth Kit and Autopsy from www.sleuthkit.org (Brian Carrier’s web site)
Many other software packages are available for Windows, Linux, and Mac OS. The best software to use, however, is the software that has been validated by the NIST CFTT program.
Acquiring data on a Windows machine is a little more complicated than acquiring data from a Linux computer. If you simply need to copy a file from one disk to another, xcopy, robocopy, or Windows Explorer will suffice. If you need to create a forensic image of a disk, however, you will usually need to use a third-party software program. One such program is FTK Imager. Figure 5-3 shows the interface to the software.
Figure 5-3 FTK Imager
Notice the menu in the upper-left corner. The three options allow you to mount an existing image, add an image to an evidence file (more on this in a later chapter), and create a disk image. FTK Imager is a Windows program, so it could be run from a suspect’s computer using protected media (a write-protected USB driver, for example) or from a Windows forensics workstation with the suspect drive attached.
The Linux dd command has many capabilities. It takes its name from the old IBM mainframe job control “dd” card, short for data definition. When used in forensic data acquisition, dd can create disk-to-disk copies, disk-to-image file, or disk-to-network copies. The dcfldd command is an enhanced version of the dd command created by the Defense Computer Forensics Laboratory (DCFL). In addition to the capabilities of dd, dcfldd provides the ability to perform hashing on the fly, output data to multiple files or disks, and pipe output and log files to commands as well as files.
Capturing the contents of the master boot record (MBR) from a particular drive is relatively straightforward. Our old friend dd comes to our rescue. Let’s say we wish to capture the MBR from the raw disk on /dev/sda. The dd command to do this is
dd if=/dev/sda1 of=/tmp/mbr-sda1-20130728.bin bs=512 count=1
The netcat command has been around for a long time, as measured in Internet years. You may find it named netcat, nc, or more recently ncat, which I’ll use going forward. Although sometimes mischaracterized as a hacker tool, ncat is a useful part of any DFI’s toolkit, primarily because of its ability to act as either a client or a server. Versions of these programs are readily available for Linux, Windows, or Mac operating systems.
Consider the circumstances where you are conducting a live extraction of data from a particular computer. You know that the disk on this computer is encrypted in such a way that if the machine is shut down, the disk can’t be decrypted unless you know the appropriate user name and password, which you don’t. You want to capture the decrypted contents of the attached disk. What to do?
ncat to the rescue. On your forensics workstation (192.168.11.3), start ncat as a server listening on a free port:
forensic> ncat -l -p 24773 | dd of=/dev/sdb bs=1024
On the suspect machine, do the following:
suspect> dd if=/dev/sda bs=1024 | ncat -p 24773 192.168.11.3
The dd command will cheerfully read 1,024 bytes at a time from /dev/sda1 and send that data via a Linux pipe to a local ncat that is sending its output to the ncat process running on 192.168.11.3 and listening on port 24773. That ncat process is in turn writing the data to a hard disk identified as /dev/sdb.
ncat isn’t limited to just capturing data from persistent storage. The contents of memory can be collected by having dd read from /dev/mem or /dev/kmem on a Linux machine. (Please note, this may not be possible in more modern Linux distributions because of permission problems associated with reading from these devices. However, new tools exist to perform this function, such as volatility and memoryze.)
A number of data acquisition software tools are available for Windows, Linux, and Mac OS. We’ve already mentioned EnCase, FTK, dd, and dcfldd. Other software includes X-Way’s WinHex suite of tools. The majority of tools are hosted on machines running either the Windows OS or Linux. In some cases, you will find tools for Linux are available for the Mac. The problem that arises is that if the Mac tools haven’t been blessed either by NIST or by digital forensics practitioners, the results produced by running these tools may not be accepted in court.
As expected, there is a multitude of hardware tools for data acquisition. Some notable tools are the MASSter series of products from Intelligent Computer Solutions, Inc. Their products range from handheld devices to portable investigation stations to forensics lab stations that support capture of up to 10 suspect drives to 10 evidence drives.
TIP Consider where and how you will use a particular tool. Will you keep it in an office, or will you be using it in the field? If the latter, spending more money on a sturdier or ruggedized device will cost less in the long run. Consider running the “Charlie Test” while the device is still under warranty: Sweep the device off a three-foot-high desktop onto a concrete floor. If it “takes a lickin’ and keeps on tickin’,” you have a tool worth keeping.
The Fourth Amendment to the Constitution secures a citizen from unreasonable search and seizures, and requires a warrant to specify what things can be seized. Even if you don’t have a warrant, you may still be able to seize digital equipment due to exceptions to the law, or if you receive the consent of an authority.
Obtaining a warrant means demonstrating probable cause for searching a person or property. If you have a warrant, then you are limited to the items mentioned in the warrant unless other rules apply, such as “plain view.” Obtaining electronic communication is a different problem. The Electronic Communications Privacy Act sets limits on what information can be obtained and restricts the process for obtaining that information. The pen/trap statute and Title III cover what kind of information can be obtained. Addressing information (communication metadata) is covered under the pen/trap statute, and is usually easier to obtain than a warrant for the content (communication) itself, which is covered under Title III.
A first responder’s role is to preserve and protect evidence at the crime scene, and this is the first order of business once you arrive on the scene. Preliminary interviews should be conducted as soon as you have properly secured the evidence. Next, document the crime scene using video, still photographs, handwritten sketches, and written notes (audio notes as well). Take 360-degree video first, then tag the equipment, then take still photographs that show the tags associated with that equipment (it may help to know that device A was connected to device B using network port N).
If machines are still running, you should determine if you need a live acquisition. If not, turn them off by literally pulling the power plug from the back of the machine (initiating a shutdown or pressing the power switch may trigger modifications to stored data). Make sure that any device capable of receiving radio signals is shielded. Make sure that any operating device that requires live acquisition or analysis remains powered on (usually via an external charger).
TIP Given how prevalent encrypted drives are, performing a live analysis may be the only way to access relevant information.
Make sure that you transport any electronic evidence such that it’s immune from changes in temperature, humidity, or vibration, and make sure that the storage area for evidence is free from dust, heat, humidity, and electromagnetic interference.
A checklist for first responders should contain steps to guide the initial preservation of the crime scene prior to the arrival of the DFI. A checklist for first responders can alleviate many common mistakes, such as shutting down a machine prematurely, using local tools that destroy evidence, improperly documenting the data collection process, or not collecting relevant information because they’re unfamiliar with that particular digital device.
Data acquisition is the process whereby data are extracted from a digital device for the purpose of examination and analysis. Extracting this data from regular disks is a known quantity: Special considerations apply when acquiring data from SSD drives, RAID arrays, or the cloud. Data acquisition may be either static (from persistent storage) or dynamic (from a running system). In dynamic data collections, collect data from the most volatile to the least volatile. Once you acquire the data, you need to validate them against the original data. You can do this by using a hash algorithm to generate a digest value from the original and the copy. If the values are identical, you know that the two files contain the same content.
There are many different hardware and software tools for data acquisition. FTK and EnCase are two of the most recognized and most used. Hardware tools can speed up the process of data duplication in the case of static acquisition. Always use a write-blocker when extracting data from a disk. Even though you may mount a disk read-only, there is a chance that data or metadata may be changed (one such case is NTFS under Windows).
1. Which of these conditions would permit seizing a computer without a warrant? (Choose all that apply.)
A. Plain view
B. Exigent circumstances
C. Serendipity
D. Hunches based on experience
2. Which of these defines when a search occurs?
A. When the expectation of privacy that society would consider reasonable is infringed
B. When a law enforcement office enters the crime scene
C. When a particular digital device specified in a warrant is seized
D. When computer software is used to scan a disk for particular keywords.
3. True or false: If a suspect gives you permission to search their computer, it means you can search for any evidence whatsoever.
A. True
B. False
4. Which of these actions is not part of seizing and searching a computer when you have a warrant?
A. Identification of a specific item
B. Data acquisition
C. Exigent circumstances
D. Documentation of the steps used to seize the item
5. Which of the following must be covered in a search warrant? (Choose all that apply.)
A. The person or person to be searched
B. The place to search
C. The property to be seized
D. The time during which the search can be carried out
6. Which activities are part of the role of the first responder? (Choose all that apply.)
A. Separate and identify witnesses who were actually at the crime scene.
B. Prevent anyone from touching the digital devices.
C. Ensure that crime scene tape is used to establish a perimeter.
D. Collect all digital devices in one place.
7. What is the purpose of asking about automated applications in the preliminary interview? (Choose all that apply.)
A. Determine when the next backup will occur in order to get a forensic image.
B. Determine if data can be changed on a running computer.
C. Determine other login accounts.
D. Determine the possible use of external devices.
8. The last step in a witness interview is:
A. Notify them of their Miranda rights.
B. Obtain their contact information.
C. Obtain their signature on their description of the crime scene.
D. Caution them against revealing any information to non-law enforcement people.
9. What is the benefit of removing the battery from a portable device?
A. Wipes any transient information that can obscure significant data
B. Forces the investigator to use external power
C. Prevents accidently starting the device and possibly overwriting critical evidence
D. Fingerprints may help identify the owner of the device
10. Which of these are common mistakes made by first responders? (Choose all that apply.)
A. Shutting down a running device
B. Using native tools that may destroy evidence
C. Prematurely restricting access to the computer
D. Asking detailed questions during a preliminary interview
11. Which of the following are types of data acquisition? (Choose all that apply.)
A. Disk-to-disk
B. Disk-to-image
C. Sparse data collection
D. Disk-to-compressed archive
12. How do we determine which data acquisition method is best?
A. One that produces a forensically sound image
B. One that copies the data most quickly
C. One that minimizes the amount of data copied
D. One that uses the least amount of resources on the suspect machine
13. Which action is part of contingency planning for data acquisition?
A. Making a copy of the data using two different tools
B. Taking multiple data acquisition hardware tools to the crime scene
C. Reading the CFTT test plan results for each data acquisition tool
D. Having two different DFIs acquire the same data
14. What is the difference between static and live data acquisition?
A. Static data acquisition collects data from persistent storage only.
B. Live data acquisition only looks at volatile data.
C. Static data acquisition collects more data than a live acquisition.
D. Live data acquisition can only be performed on a remote device.
15. Which of these is the most volatile?
A. Memory
B. Registers
D. USB drive
1. A, B. Exigent circumstances and plain view would support seizing a digital device without a warrant.
2. A. A search occurs when the societal expectation of what constitutes a reasonable degree of privacy is infringed.
3. B False. Searches of a computer are still constrained by the nature of the original warrant.
4. C. Exigent circumstances come into play when you don’t have a search warrant.
5. A, B, C, D. A search warrant will specify who, what, when, and where the search can be carried out.
6. A, B. Protecting the evidence and conducting preliminary interviews are part of the duties of a first responder.
7. B, C, D. Determining changes made to data by automated applications, as well as login accounts and external devices, can help you identify other digital devices that should be seized.
8. C. The last thing to do during a witness interview is to get their signature.
9. C. Removing the battery from a portable device avoids accidental startup that may lose information.
10. A, B. Shutting down a running machine and using native tools that modify critical data are both common mistakes of a first responder.
11. A, B, C. Disk-to-disk, disk-to-image, and sparse file copy are all methods of data acquisition.
12. A. The method that provides a forensically sound copy.
13. A. Creating copies of evidence using two different tools is an example of contingency planning for data acquisition.
14. A. Static data collection only collects data from persistent storage.
15. B. CPU registers contain the most volatile data.
1. Jacobsen, 466 U.S. at 113.
2. Jacobsen, 466 U.S. at 113.
3. United States v. Matlock, 415 U.S. 164 (1974).
4. Searching and Seizing Computers and Obtaining Evidence in Computer Investigations, (Washington, DC: DOJ, 2009).
5. Searching and Seizing, p. 42.
6. Tsukayama, H. “Judge Allows Lawsuit Against Google’s Gmail Scans to Move Forward.” Retrieved from http://articles.washingtonpost.com/2013-09-26/business/42421388_1_gmail-users-google-s-marc-rotenberg.
7. Electronic Crime Scene Investigation, A Guide for First Responders, Second Edition (Washington, DC: DOJ, 2008), p. 18.
8. Shinder, D. L. Attack Response Checklist and Flowchart (NY: CBS Interactive, Inc., 2011). Retrieved from http://www.techproresearch.com/downloads/attack-response-checklist-and-flowchart.
9. Brezinski, D., and Killalea, T., Guidelines for Evidence Collection and Monitoring, RFC3227 (CA: IETF, 2002). Retrieved from http://www.ietf.org/rfc/rfc3227.txt, p. 4.
10. EC-Council. “First Responder Procedures,” Computer Forensics Investigation Procedures and Response (NY: Cengage Learning, 2010), pp. 4–14.
11. EC-Council. “Data Acquisition and Duplication,” Computer Forensics: Investigating Data and Image Files (NY: Cengage Learning, 2009), p. 2–2.
12. Brezinski, D., and Killalea, T., Guidelines for Evidence Collection and Monitoring, RFC3227 (CA: IETF, 2002). Retrieved from http://www.ietf.org/rfc/rfc3227.txt, p. 3.
13. Digital Data Acquisition Tool Test Assertions and Test Plan (Washington, DC: NIST, 2005). Retrieved from http://www.cftt.nist.gov/DA-ATP-pc-01.pdf, p. 4.
14. Henry, P. “Best Practices in Digital Evidence,” Computer Forensics and Incident Response Blog. Retrieved from http://computer-forensics.sans.org/blog/2009/09/12/best-practices-in-digital-evidence-collection.
15. md5deep and hashdeep, latest version 4.3. Retrieved from http://md5deep.sourceforge.net.