Digital Evidence Collection

Investigations involving digital evidence follow the same rules of evidence as any other investigation. Digital evidence, much like non-digital physical evidence, should be seized according to evidentiary procedures of the investigator’s agency and legal rules of evidence. As a general rule, any type of evidence collection should be done with the least detriment to its condition. Exceptions aside, the collection of digital evidence most always involves creating a working copy of the data contained on electronic storage media from which an analysis is conducted. It is always preferable to work on a copy, or forensic image, than touch the original storage media to prevent changing the original evidence.

The forensic image is a file format that contains every bit of data on the original storage media, such as a hard drive or flash drive. The format of a forensic image is chosen by the examiner creating the image which can be in any number of file formats, such as the Unix “Data Description format” (dd) or “Advanced File Format,” in which the forensic image file contains a bit stream copy of all data from the storage media.

The acquisition of digital evidence has different implications and objectives as compared to the method of seizure and preservation of non-physical evidence. Not so many years ago, the most common method to seize electronic data was only to “pull the plug” on the suspect computer and create a forensic image or exact clone of the storage media. Given subsequent research in the field of digital forensics, this is not the only method, or even the preferred method, as evidence will be lost if a “live” computer system is shut down without first capturing volatile memory. With a running computer system, the investigator must make a choice of an acquisition method. Any method chosen will allow for the collection of some information but will also not allow for the collection of other data.

The following methods of data collection are simply options to consider in the different situations the investigator will face. Depending upon the goals of the investigation, specific measures in data acquisition must be taken. Case examples will be discussed in which the manner of digital evidence acquisition may have an impact on whether or not a suspect can be placed behind the keyboard. As the intention of this book is showing how to place the suspect behind the keyboard, investigators should be aware of options of evidence seizure. Electronic evidence is different than any other type of evidence. If a computer system is running, you can compare it to a living being, because the data is changing as you stand and look at it. Knowing reasonable methods of acquiring the evidence for a given situation is important and beneficial to the investigation. Before bagging and tagging electronic evidence, take time to think of the consequences of your choices.

As to the best method to seize electronic evidence, it is up to the investigator to decide which method is most reasonable when approaching the computer systems at each scene. Each case is different. Each computer system configuration is different. And each investigator is different. The totality of the circumstances at the time will determine which method will be a reasonable choice.

Those tasked with collecting electronic evidence need to be acutely aware that computer systems that are running are constantly changing data naturally. These changes may be minimal variations occurring through normal operating system tasks, or the changes can be dramatic depending upon specific programs that may be employed. A word processing application will have minimal impact on a live system, however, an application such as a data wiping program or a malicious software program will have a destructive impact on a system.

Any human interaction with a live system by an examiner compounds the changes already being made on the system. No matter how small the interaction may be with a live system, there will be an impact on the system through the examiner’s actions. These impacts potentially include both the destruction and the creation of electronic data, and individually in volatile memory and hard drive storage. Either way, if the system is on, the data is changing and anything you do or don’t do will still result in changes to the data. So what are your options?

Simple File Copying

In some cases, copying files by dragging them from the evidence computer to an external hard drive may be appropriate. Such an instance usually occurs in a civil case where the only importance may be the content of the copied files and the computer user is not in debate. Simple file copying will alter the metadata of the files and if the evidence computer is live, then the data on that system will also be altered. In those situations where simply file copying is warranted, the use of specialized software to at least maintain the original metadata is advised. Yet, in the many civil cases and certainly in every criminal case, this is not an acceptable method for collecting electronic evidence.

Frequently, parties to litigation have agreed to custodians of specific computers and disputes as to the users have been concluded. However, there remains the possibility that a custodian of a computer may deny specific actions that occurred on his or her computer. In that instance, the examiner must now work to place a person behind the keyboard for the questioned instances of activity.

Using simple file copying of only user created files leaves little electronic evidence from which to work, besides the copied files. Unless the examiner copies data that bolsters user activity, such as event logs and registry hives, basic user created files, such as word processing documents, leave little for an examiner to investigate if the need arises after the fact.

Where a file copying utility will be used on a suspect’s computer, the choice of the tool should be one that has the most minimal impact on the files, such as a DOS application like “Upcopy” from Maresware (see Figure 1.1, Upcopy available freely from http://www.dmares.com). Among many of its features, Upcopy maintains the file’s metadata as well as verifies copied files through hashing and creating a log file.

For best practices of data collection, even in those civil electronic discovery instances where simple file copying is approved rather than a complete forensic collection of a hard drive, steps can be taken that will constitute a more complete collection. As an example, hard drives containing files for electronic discovery collection can be removed, connected to a forensic workstation, and copied using forensic applications.

Another option could be to boot the custodian computer to a forensic operating system using external boot media like a compact disk modified not to alter any evidence devices. Having access without risk of changing the files can allow collecting the files using a forensically sound process.

Collecting data haphazardly without a process may eventually cause problems should the veracity of the data collected be called into question. Copying files through any method such as drag and dropping files or using file copying software is the least comprehensive method of collecting data. Before you decide to copy files on a live computer, remember that you only have one chance to collect the evidence reasonably. Every other attempt on a live machine results in the original evidence being higher at risk of modification.

“Dead Box” Approaches

Sometimes the easiest decision to make is the one you don’t have to make. Investigators that approach computer systems that are not running (“dead”) upon arrival have their decision on the method of acquisition decided already. In most criminal cases, these computers are not to be turned on by the responding investigator, but instead they are imaged using write protection to the evidence hard drive. Sometimes, it may be a necessary and acceptable practice to boot the system and create a forensic image from the live system. These cases usually happen in corporate and civil litigation matters or where the system is encrypted.

The steps to creating a dead box image could involve removing the hard drive and connecting it to a hardware write blocker or booting into a forensic operating system. Write protecting the evidence hard drive is accomplished using hardware write protection devices, an example seen in Figure 1.2. Evidence hard drives are connected to forensic computer systems using hardware write protection devices; much like an adaptor may connect a hard drive through a USB cable to a computer. However, unlike a basic adaptor, a hardware write protection device prevents modifications to the evidence hard drive as the device only allows data to be read from the evidence source.

Along with the hardware write blockers, software developed to create forensic images is used to read or copy the evidence data. Although there are countless applications developed for data duplication, data acquisition, and backing up data, nearly all forensic analysts will use applications specifically developed for creating forensic images. Most commercial vendors of forensic suites, in addition to open source software developers, also provide applications to create forensic images applications. Table 1.1 lists several examples of commonly used software applications developed with the ability to create forensically sound images of electronic data.

Forensic imaging applications are naturally used in conjunction with a write protection device (“dead” box acquisitions). Most of these same forensic imaging applications can also be used on a live machine when necessary. Figure 1.3 shows an example of FTK Imager from Accessdata, which can create forensic images with hardware write blockers in the ‘dead box’ approach as well as be able to capture volatile memory and hard drive imaging from a live machine.

Another approach option for imaging is booting the suspect computer with specially modified boot media such as a forensic boot disk. A forensic boot disk is a CD/DVD/USB/floppy that contains an operating system from which a computer will run to avoid using and accessing the computer’s internal hard drive. Even though the “floppy” hasn’t been supplied with current computer systems, nor even as an option, there is still a possibility of encountering a system that may require a forensic floppy boot to exist.

The operating system on the boot media can be one of many forensically modified versions of Linux, Windows, or DOS. The primary modification required in a forensic boot media is that configuration which prevents mounting the evidence drive or otherwise allowing modification of data on the evidence hard drive. Many of these forensic boot media are freely available online or can be built and customized by individual examiners (see Table 1.2).

Once a computer has been booted to the forensic operating system, an image of the computer hard drive can be created and saved onto an attached external hard drive. Forensic boot media provides write protection of the evidence hard drive(s) through software configurations.

In order to use a forensic boot media, the BIOS of the suspect computer system is first modified by the examiner to boot the forensic media rather than boot the hard drive in the computer. This method of booting an evidence computer carries a risk of inadvertently booting the suspect system causing modification of files on the evidence drive if precautions are not taken to control the booting process. Failing to control the booting process runs the risk of booting your evidence to its operating system, changing thousands of files on the hard drive.

During a search warrant or civil evidence collection, you may feel either a self-induced pressure or actual external pressures to hurry up. Being rushed causes mistakes to be made, items overlooked, and regret after you leave the scene for doing a less than reasonable job. Booting a computer to a forensic disk is one of those times where being rushed will cause problems. To avoid inadvertently booting the evidence computer’s operating system, test it first.

First, disconnect the evidence hard drive in the computer by unplugging the cable to all hard drives in the computer. Next, boot the computer to the BIOS. Change the boot order with the hard drive being last. The first boot media will be your forensic operating system on a CD or USB drive. The second boot media should be any other drive other than the hard drive. If there is a floppy drive, choose the floppy as the second media. Save your changes, exit, and shut down the computer.

Your forensic boot disk is placed in the CD drive, or if you are using a USB drive, plug it in. Any remaining drives can be filled with empty media, such as a blank floppy disk. Boot the computer and make sure your forensic operating system boots. If it does, shut down the system, reconnect the hard drive, and boot the system to your forensic disk.

A reason for filling any other drives with blank media, like the floppy drive, is to give an added layer of protection if the boot process somehow bypasses your forensic CD. Maybe the blank media will be caught in the booting process and prevent booting the evidence drive and if that happens, you will know that although your boot media was skipped, your blank media prevented evidence from being changed. Then go through this process again, maybe with another bootable media.

Figure 1.4 shows the Raptor Forensics Boot Operating System, one of many variations of a modified Linux operating system capable of running from a CD/DVD/USB.

Dead box imaging also applies to digital media that is not connected to a computer system, such as external hard drives, USB flash drives, compact disks, and other small media. The concepts of write protection are the same since the small media would not be in operation (not powered on). Through write protection, these small media are connected to a forensic workstation and imaged much like a computer hard drive.

On the face of simply imaging a hard drive, it would seem to be an easy task. But I would rather compare it to steering a ship through the Suez Canal. Maybe steering the ship is only a few inches of turning the wheel left and right to keep the boat straight, but there is no such thing as a small mistake with those few inches of wheel sway.

Although this is an oversimplified analogy, the point is that imaging seems easy until it isn’t. Software that worked on one drive may not work on another. Hardware that worked on one drive may not work on another drive of the same type. Computer systems with RAID configurations add complexity that may have to be solved with multiple imaging attempts in order to capture useable data depending upon the type of RAID, and whether it is a software or hardware RAID.

Failing hard drives during imaging is only one small part of imaging problems. In most instances, capturing a RAID through the live system is the surest method of capturing the RAID data, as there are occasions where individually acquired RAID hard drives are problematic to reconstruct outside of their original setup.

The hard drive itself may be a collection issue solely based on the size of the drive and the amount of data stored. A single desktop computer system can have terabytes of data storage across multiple hard drives. Creating forensic bit for bit images of each drive may not be practical or allowable with time constraints. In network systems in which even larger storage systems exist, it may be physically impossible to image every bit of data. Sparse or targeted collections may be the most reasonable method in these situations.

The bottom line is that the easy forensic imaging situations are becoming less and less common. You should not be surprised that if everything seems easy, you might be overlooking something.

“Live Box” Approaches

Approaching a computer system that is running (“Live box”) creates a time sensitive situation in which a decision must be made as to the method of data collection. As an investigator ponders this decision, changes to the data on the evidence drive are occurring. Therefore, to not make a decision or to slowly make a decision allows that data to continue to be modified by the operating system or any open applications.

Depending on future needs of the investigation that requires digital evidence to place the suspect behind the keyboard, the data in physical memory may be crucial to obtain. To show an example of processes naturally occurring on a running system, Figure 1.5 is a screen capture of Process Monitor, a Windows Sysinternals program. Besides the 122, 171 events listed by Process Monitor in the screen capture, as the system continues to operate, more processes and changes will occur. So again, the decision not to interact with the system for fear of changing it, is actually a decision to allow the system to change regardless.

There are several factors to consider in the decision to choose a data acquisition method, each with risks and compromises. One of the most important factors to consider in approaching a live system is to decide to conduct a Live Response approach or shut down the system and directly image the evidence hard drive.

This is an important decision and cannot be taken lightly. You don’t get a practice attempt or a do-over. Once the first steps have been taken, there is no starting over. To help make this decision, accept that unless the system was already shutdown upon your approach, the data will change regardless of the decisions you make.

There is also the consideration of the “Order of Volatility” when the choice to capture physical memory has been made. All data is considered volatile, in that, at a point in time, that data may not be available for recovery. This volatility of data can range from nanoseconds to an indefinite time period. As an example, certain data in RAM is susceptible to be destroyed by natural processes of the operating system or user intervention in nanoseconds, whereas other data stored on archival disks or backup tapes will exist indefinitely. Depending upon the needs of the investigation, the order of capturing different volatile has to be decided. Depending upon the case, all or some of the volatile data is required, and even the order of volatility has to be taken into account to capture data before it vanishes while you are capturing other data.

Specifically, if a system is shut down, physical memory will vanish. Physical memory, which is the most volatile data, resides in the Random Access Memory (RAM) and contains information from the programs that have been run and are running during the time the computer system has been on in the current session. Shutting down the computer system will cause that data being temporarily stored in RAM to vanish. Live Response involves collecting volatile data information, where live acquisition involves capturing memory as an image file.

Live Response and acquiring physical memory can be compared to acquiring a moving target. It is constantly in flux and volatile (non-persistent). One example of data contained in physical memory which is not written to the hard drive is chat messages using various social networking websites. These chats may only exist in the RAM and only for as long as the computer is running. If this data is not captured from the live system, the chats will not exist to be recovered from the hard drive, since they are not always written to the hard drive in the first place.

Table 1.3 lists examples of electronic evidence existing in physical memory. Each approach to a live system may or may not require acquiring the information in physical memory, depending upon the needs of each individual investigation.

Obtaining volatile physical memory may best be conducted with batch files or scripts to automate the process. Although there are multiple pre-configured volatile memory collection systems freely available, such as the Linux forensics live CDs, the investigator should be certain that the systems used fit the needs of the situation. Having the ability to create or modify which collection programs are run, and in which order, is an important option to have.

Table 1.4 lists several applications suited for physical memory acquisition. As any application may unexpectedly not operate on a given system, the examiner’s ability to quickly transition from one non-working application to another, rather than troubleshoot a problematic program on a live system, should be done. Troubleshooting your software issue on an evidence will make many more changes to the system than using a different software.

Since the standard amount of RAM in personal computers now commonly ranges from 2 GB to 4 GB and higher, the amount of data contained therein is substantial. Given this amount of memory, it is also known that intruders have the ability to install rootkits or malicious software (malware) within RAM and that the code to these malware program will only execute in memory. By not capturing the physical memory, it is likely never to be known if a malware existed only in RAM and was never written to, or created files on, the disk.

If malware exists on the system, it is possible that this same malware will interfere with forensic applications used to examine and acquire memory. This interference, whether by design or chance, can cause the forensic applications to fail to work, fail to capture certain data, or even crash the system. The use of the suspect system to operate forensic applications is an unknown risk but in these cases, there aren’t too many other choices.

One solution to minimize malware interference during a live acquisition of memory or hard drive is acquiring the data remotely. By connecting a forensic workstation to the suspect machine via a network or network cable, forensic applications can be run on the trusted forensic workstation rather than the suspect machine. Although typically, a small amount of code from the forensic program needs to be installed onto the suspect machine, the actual forensic applications will be run on the trusted machine, thereby reducing the amount of modifications to the suspect computer and risk of interference from the evidence system.

A unique and effective utility to facilitate this process is F-Response (http://www.f-response.com). F-Response allows examiners to connect their forensic workstations to suspect machines remotely. The connection to the suspect machine is Read-Only, in that the forensic examiner cannot modify the suspect machine’s data (other than the changes that are made naturally by the suspect’s operating system). Using F-Response, the hard drive(s) can be imaged as can the Physical memory.

As F-Response simply (yet ingeniously) provides a secure and Read-Only connection, it does not have the functionality to acquire data. This is an intentional feature not supplied as the forensic examiner can use virtually any application to acquire data through the F-Response connection. The ease of accessing systems remotely with F-Response can be seen in Figure 1.6.

Data encryption that is suspected or known to be employed can prevent acquisition of some or all of the data. Data encryption can encompass one or more files, folders, volumes, partitions, or even the entire hard drive. If an image is created of an encrypted file or hard drive, the decryption key will be needed to decrypt and analyze the encrypted data. Without the decryption key, the likelihood of recovering the encrypted data may be slim to none, depending upon the complexity of the encryption and decryption key.

Encryption programs, such as TrueCrypt seen in Figure 1.7, are plentiful and freely available on the Internet. TrueCrypt gives any computer user the option to encrypt their entire operating system or a specific container of files. Commercial products, such as the Microsoft Operating System, also offer full disk encryption as part of the operating system.

Other operating systems, such as Linux, generally allow the computer user to encrypt their entire system or individual files as well. There are few operating systems that do not come with encryption programs by default. Any system that does not come with encryption programs by default most likely is able to have third party encryption programs to be used.

Ignoring encryption possibilities on a suspect computer will eventually lead to extremely short forensic examinations because when encrypted, there is little that can be done to examine an encrypted system without the decryption keys. You can assume that nearly any live system can be encrypted, either in whole or part, as many current operating systems include encryption as a system feature. There are also countless encryption programs that are freely available to accomplish encryption. So take some time to evaluate the encryption potential before pulling the plug from the computer.

Trusting the computer user to provide the key before or afterward, or even trust to be provided the correct key is a risk without resolution if the decryption keys do not work as promised. As current case law sways back and forth of demanding suspects to provide passwords, reliance on a court order risks not being able to access the information should a court order not be issued, or if the suspect conveniently forgets the password.

With full disk encryption, once the computer has been shut down, the decryption key will be needed, otherwise, it could take weeks or years to decrypt, with the possibility or being virtually unable to decrypt. Several forensic applications, such as X-Ways Capture seen in Figure 1.8, can be run on the suspect computer to not only determine if encryption is employed, but to also image the system’s physical memory and subsequently, the evidence hard drive(s) should encryption be detected on the live system.

As described thus far, the clock continues to tick away when suspect computers are running and choices are being weighed. Yet another factor that can literally add hours to the process and modify the evidence even more are applications that may be running on the suspect machine. Commonly used programs, such as word processing programs, are not so much the concern as are other programs.

Data wiping programs that may be open are a serious concern and need to be addressed quickly to prevent evidence destruction. Virtual machine applications also pose a problem, if a virtual machine is running on your evidence system.

Virtual machine applications, such as developed by Vmware (http://www.vmware.com) and VirtualBox (http://www.virtualbox.org), allow for entire operating systems to be operated as guest systems within the host operating system. As an example, a computer with a physical hard drive running Microsoft Windows, can also run the VirtualBox application which can run a separate operating system as a guest system, or several simultaneous guest systems. The guest operating system maintains its own data within its own files. In effect, an examiner that approaches a running suspect machine that is seen to have a running virtual machine on the desktop now has to decide acquisition methods of two systems.

The guest virtual machine will have many of the same considerations of data collection as the host machine. It is possible to temporarily suspend the virtual machine operating systems with some types of virtual machine applications such as vmware, storing the physical memory in file. This stored physical memory can be examined as if it were imaged. Other virtual machine applications do not suspend or store physical memory, which gives the investigator more difficult decisions on how to proceed.

Given the nature of a virtual machine containing all its data internally, it is conceivable that all evidence needed for the investigation could be contained solely within the virtual machine and not exist on the host system. This evidence could consist of Internet history, running processes, or email. The collection of a running virtual machine from a running suspect computer increases the risks of system crashes, lost data, and altered data.

However, this is expected and unavoidable and the investigator must make a decision based on the facts of that particular situation. Figure 1.9 shows a Windows host operating system with an Ubuntu guest virtual system. The approach to this one system is actually an approach to two individual systems.

Other problematic programs and processes that will interfere in the collection of evidence include peer-to-peer networking applications, open remote connections, active file deletion or file copying, and active program installations. Closing some programs, such as Internet Explorer, may cause user created data to be written to the drive, which may be beneficial to the examination. Some applications may lose data when they are closed on a running system.

Each of these can contribute to a substantial loss of pertinent electronic evidence and create obstacles to the investigator’s process of collection. All of the choices made will require explanations in reports and may be testimony for the choices made. Right or wrong, you have to make a decision based on what you know at the time.

As previously discussed processes can be seen in detail using Process Monitor, but indicators to active programs can also be seen in the task bar. A quick glance at the task bar can give information that might require immediate attention or direct you on how to move forward with data collections. Using Figure 1.10 as an example, an icon for “TrueCrypt” (http://www.truecrypt.org) is seen, indicating that encryption is probably certain.

Knowing that encryption exists helps make choices of approaching live systems easier. The TeamViewer icon (http://www.teamviewer.com) shows that this computer can communicate with another system and it can be accessed remotely.

In this same example, there is a possibility of an active session with TeamViewer which the investigators at the scene may not be aware of. In effect, a suspect could listen and see with an attached webcam all that is happening around his system covertly, all the while, accessing and wiping files.

Another icon can be seen for “DropBox” (http://www.getdropbox.com). The Dropbox icon shows that files that exist on this computer and are stored online with Dropbox and are potentially shared with other computers. An online file sharing system such as Dropbox can be accessed by any Internet connected computer, and as this computer system remains connected, the files stored in the Dropbox folder can be modified remotely through any other computer. Examiners also cannot rely solely upon a lack of icons in the task bar since icons can be hidden by the computer user.

Even as a suspect may be away from his computer, he can easily access and delete files in his Dropbox using any other Internet connected computer. The online deletions will delete the files on his computer automatically, even as you stand and watch the screen. Of course, the files are probably recoverable with a forensic analysis, but the point is that the computer was being changed by the suspect remotely.

Observing active processes will give information to also base decisions on. Knowing which processes are important to the specific scenario depends upon the investigator’s knowledge and skill level. And as mentioned, some processes deserve immediate attention to prevent the destruction of needed evidence while accepting the fact that destruction of other less relevant data is imminent.

Decision-Making FlowChart

Since a great number of digital evidence seizure missions take place with unknown factors, such as the number of computer systems, types of operating systems, employed encryption, and other factors, having a plan developed beforehand helps the decision-making process. Experienced examiners are aware that no amount of planning and guessing will be absolutely correct when approaching computer systems. However, these examiners do know that by having some plans in place, the timeliness of making decisions is quicker and more apt to be reasonable decisions.

Case dependent, a certain flow of decision making can be developed that covers a range of situations. The time available to collect and analyze case data involving a missing or kidnapped person will be much shorter than the time frame to investigate a theft that was facilitated with a computer system weeks prior. Obviously, the risk of harm to persons causes decisions to be made quicker. Seizing computer systems without a plan is not only an ineffective method, but also places persons at a higher risk of harm if not identified or found due to overlooking or neglecting important data.

Search warrant raid briefings, where many persons are tasked with seizing digital evidence in different locations, can be significantly improved if a process has been discussed and agreed upon before examiners approach the suspect systems.

Such pre-planned decisions can be visually displayed using decision-making charts. These charts must be adjustable to each circumstance in each case. Since time may be the essence in person crimes, the perfect acquisition of all digital data may not be practical to obtain the most important information needed to prevent physical harm to victims. These can be considered a “Live Response” plan more than a data acquisition plan, although data acquisition most likely will occur afterward (see Figure 1.11).

Preview/Triage

The topic of previewing evidence has been an ongoing discussion for years. Even the terminology changes with definitions of the same processes being described as a “preview” or a “triage.” In the context of this book, both previewing and triaging a computer system will have the same meaning as it relates to obtaining electronic evidence at the crime scene. Preview/triage can also occur at a lab with the goal to prioritize electronic evidence for examination. In the context of this book, the preview/triage goal is to obtain information to identify suspects and place them behind the keyboard.

The methodology of previewing and triaging computer systems can be viewed as nearly identical in processes, yet the goals may be completely different. In cases where gaining information must be timely due to critical circumstances, the objective in previewing multiple computers or a single computer is to quickly find the “low hanging fruit” and the most critical evidence. This evidence may consist of an email or a chat message stating the location of a planned kidnapping. Acquisition of the storage media is secondary compared to obtaining actionable intelligence to prevent a crime or save a life.

Practically, an examiner can triage a computer simply by poking around a live system looking for relevant evidence. This type of action obviously is not recommended, since just as there are forensic software applications, there are also forensic triage software applications. Table 1.5 shows several examples of triage software, some of which is law enforcement (LE) only. The use of these applications will still alter data on the computer system, but will be a least intrusive method when triage is warranted.

The same principles of approaching systems apply when preview/triage is chosen as the first step. However, with live systems, triage/preview will cause data to be created on the system with other data potentially being overwritten during the process. Keyword searches, viewing images, and other aspects of a preview/triage on a live system will cause changes to both physical memory and the hard drive. Dependent upon the situation, this is probably completely acceptable and expected.

Perhaps the most important reason to preview/triage a computer system is to find information of immediate and actionable value. This may be to identify victims, suspects, or potential crimes. In the direst situations, such as a child being lured from home by an online sexual predator, the immediate objective concerning the victim’s computer is to capture specific data.

In this type of scenario, where every minute counts, the option to create a forensic image of the hard drive, data carve files, index the drive for searching, and perform an analysis of the data would be the worst decision to make. Primarily, the goal would be to find items such as chat messages or emails related to the luring as fast as possible, even if that requires triaging the live system and changing data on the system.

An example of a preview/triage application available to law enforcement and military is Field Search. Field Search (seen in Figure 1.12) runs on the Windows operating System and the Apple Operating System. As a first responder utility, not a data collection application, its use is to obtain relevant and timely information based on a specific scenario.

One scenario where triaging a computer system is effective is with the computer owner’s consent to search. Usually, this is done to determine if a crime exists, such as possession of child pornography, particularly for sex offenders under supervision. Triage utilities such as Field Search are able to quickly sort images, Internet history, and user activity to assist in determining if evidence exists on the system.

Conducting a preview/triage on a dead box can also be done without altering any information stored on a hard drive by write protecting the evidence drive through hardware write blockers or booting the suspect machine to a forensic boot environment. This would be the most forensically sound method, however, it does require the computer being shut down. This would eliminate physical memory unless the physical memory was captured before shutdown.

Conducting a preview/triage with suspects present or in close proximity can be an effective method of obtaining admissions through evidence immediately collected to aid in questioning suspects. Crime scenes in which a computer has been left unattended and running are particularly important to respond with both a preview/triage method and live response. The information stored in RAM may be the best source of information as to the most recent activity that had taken place which may identify the most recent user or users. Locations where computer systems are accessible by many persons, such as an Internet café or business, also require that a live response and triage be conducted. Activity on a public computer that has been stored on the hard drive in the past could reach several years in the past whereas potentially, only the information existing in RAM during the most current and active session will be of importance.

SmartPhones and Cellular Devices

Many of the commonly accepted practices for seizing electronic evidence as it pertains to computer desktops and laptops do not fit nicely within the practices of seizing smartphones and cell phones. Regardless of differences, these devices also need collection for examination as at times, a smartphone may be the primary means of identifying a suspect.

A consideration for cellular devices includes data on the device being accessible by the suspect remotely. If the phone is capable of remote access, a suspect can send a ‘wipe’ command to the phone, destroying much or all of the data contained in the device. Precautions to prevent the device accessing a cellular network, such as placing the device in “airplane mode” or storing in a container blocking cellular reception, may be the first priority.

In addition to the device’s internal memory, many of these devices will contain removable flash memory and a SIM card. A singular cellular device can easily contain 30GB or more of data, stored in various media locations on the phone, which can store data such as text messages, GPS information, call logs, photos, videos, documents, and voice recordings, any of which may help pinpoint a suspect’s activity or location.

Summary

Electronic evidence cannot be ignored. Nearly any device that contains storage of electronic data to include the temporary storage of data such as RAM must be considered for examination. Any one device or a combination of devices may contain the key piece of information that can effectively tie a suspect to a crime or to the device used.

The methods to approach computer systems will vary in degree based upon the needs of the investigation, the skill of the investigator, and the configuration of the systems encountered. No approach will be able to collect all data without loss or modification of some data. The forensic imaging of a write protected hard drive will allow for the collection of the entire hard drive data, but not of RAM that existed before the system was shut down.

The collection of volatile data also does not allow for the collection of all pristine data, as merely touching the computer (or not touching the computer) will create data and cause data to be lost through normal operating processes. The examiner has to choose which data is more important, knowing that some data will be lost or changed.

The goal of “first do no harm” in regard to collecting electronic data may more appropriately be described as “do as little harm as possible”. As long as the investigator performs the least intrusive means possible, which may vary depending upon the immediacy of the situation, then that means it will be a reasonable choice to have been made. The least intrusive means in one particular case may be different compared to another. Again, where the threat of bodily harm exists, the threshold of acceptable changes to data will need to be adjusted to obtain timely information. Even with each decision made, the examiner may feel that the choice made was not the best choice upon later reflection. Given any scenario placed before an investigator, such as a running computer system, where time is clearly the essence, any decision made is certainly better than no decision at all.

Bibliography

1. Apple Operating System, Apple. <http://www.apple.com>.

2. Backtrack. <http://www.backtrack-linux.com>.

3. CAINE. <http://www.caine-live.net>.

4. DEFT. <http://www.deftlinux.com>.

5. DropBox. <http://www.getdropbox.com>.

6. Farmer’s Boot CD. <http://www.forensicbootcd.com>.

7. Field Search, KBSolutions. <http://www.kbsolutions.com>.

8. Forward Discovery. <http://www.raptorforensics.com>.

9. F-Response. <http://www.f-response.com>.

10. Guymager. <http://www.guymager.sourceforget.net>.

11. Maresware. <http://www.dmares.com>.

12. mdd. <http://www.sourceforge.net/projects/mdd/>.

13. Microsoft. <http://www.technet.microsoft.com>.

14. osTriage. (LE Only) <http://feeble-industries.com/forums>.

15. Tableau SATA/IDE Bridge, image courtesy of Forensic Computers, Inc. <http://www.forensiccomputers.com>.

16. TeamViewer. <http://www.teamviewer.com>.

17. TrueCrypt. <http://www.truecrypt.org>.

18. VirtualBox <http://www.virtualbox.com>.

19. Vmware. <http://www.vmware.com>.

20. Windows Forensic Environment. <http://winfe.wordpress.com>.