One critical task that incident response analysts often must perform is imaging digital evidence. As we discussed in prior chapters, a great deal of evidence related to an incident can be found within log files, memory, and other areas and can be acquired relatively quickly. In some incidents, such as internal malicious activity (for example, fraud, industrial espionage, or data leakage), a more detailed search for evidence may be required. This evidence includes master file table entries, files, and specific user data that is contained on the hard drive of a suspect system. If incident response analysts encounter such circumstances, they will be required to obtain an image of a suspect drive. As with any aspect of digital forensics, obtaining a usable and court-defensible image depends on the appropriate tools, techniques, and documentation being used.
This chapter will explore the fundamental concepts of digital imaging and the preparation and tools that are needed to acquire a forensically sound image of a physical drive or another logical volume. More specifically, we will cover the following topics:
While this chapter presents some very technical and process-driven material, it is important that responders understand imaging. This process is critical to producing images that can be relied on for root cause analysis (RCA) and potential courtroom use.
Imaging a storage drive is a process where details matter. This section provides a solid foundation on forensic imaging, how it is accomplished, the various types of digital imaging processes, and the various proprietary file formats.
Having a solid understanding of the facets of forensic imaging is important for incident response analysts. Understanding the tools, techniques, and procedures involved ensures that evidence is handled properly and that analysts have confidence in the evidence they’ve acquired. In addition, understanding the necessary terminology allows analysts to accurately prepare reports and testify as to their findings if the need arises.
One of the first concepts that should be understood is the difference between forensic imaging and copying. Copying files from a suspect hard drive or another medium only provides analysts with the actual data associated with that file. Imaging, on the other hand, allows the analyst to capture the entire drive. This includes areas such as slack space, unallocated space, and possibly accessing deleted files. Imaging also maintains metadata on the volume, including file timestamps. This becomes critical if a timeline analysis is conducted to determine when specific files were accessed or deleted.
Often, the terms cloning and imaging are utilized in place of each other. This is a common improper use of terminology in the IT realm. When cloning a drive, a one-to-one copy of the drive is made. This means that the drive can then be inserted into a system and booted. Cloning a drive is often done to make a fully functional backup of a critical drive. While a cloned drive contains all the necessary files, it is cumbersome to work with, especially with forensic tools. As a result, an image file is taken. An image of a drive contains all the necessary files; its configuration permits a detailed examination while utilizing forensic tools.
The second concept that needs to be understood is the types of volumes that can be imaged. Volumes can be separated into physical or logical volumes. Physical volumes can be thought of as containing the entirety of a hard drive. This includes any partitions, as well as the master boot record (MBR). When imaging a physical volume, the analyst captures all of this data. In contrast, a logical volume is a part of the overall hard drive. For example, in a hard drive that is divided into the MBR and two partitions, a logical volume would be the D: drive. When imaging a logical volume, the analyst would only capture data contained within the D: drive.
The following diagram illustrates data that is captured while imaging either a physical or logical volume:
Figure 8.1 – Physical versus logical volumes
The type of incident that is being investigated largely dictates the type of imaging that is conducted. For example, if an analyst can identify a potentially malicious file being executed from the D: drive and is intent on only capturing that data, it might be faster to acquire a logical image of only that volume. Furthermore, a logical acquisition may be necessary in cases where Full Disk Encryption (FDE) is being used. Without the encryption key, logically acquiring files while the system is running is often the only option that’s available.
The one key drawback that a logical image has is that it will not capture unallocated data or data that is not part of the filesystem. Deleted files and other trace evidence will not be part of a logical image. In cases where an activity such as employee misconduct is suspected, the analyst will need to trace as much activity as possible, so a full image of the physical volume will be conducted. Time isn’t a necessary factor here.
In Chapter 5, we discussed the acquisition of evidence such as log files and running memory from a live or powered-up system. In much the same way, incident response analysts have the capability to obtain a logical volume from a running system. This technique is referred to as live imaging. Live imaging may be the best option if a potentially compromised system cannot be taken offline—say, in a high availability (HA) production server—and potential evidence is located within a logical volume.
Dead imaging is performed on a system that has been powered down and the hard drive removed. In this type of imaging, the analyst can capture the entire disk, including all the volumes and the MBR. This may become necessary in incidents where analysts want to ensure that they capture the entirety of the source evidence so that there is no location that hasn’t been examined.
Another aspect of forensic imaging that an analyst should have knowledge of is the types of image files that can be created and leveraged during an investigation. There are several types of image files, some of which are very specialized, but for the purposes of this book, we will focus on the three most common types of evidence files that analysts will most likely create and work with during an incident:
Figure 8.2 – E01 file format
Another key facet of imaging that incident response analysts need to understand is how to image specific storage media—specifically, understanding the difference between a hard disk drive (HDD) and a solid-state drive (SSD). Understanding this difference has become critical, with SSDs being much more common, especially in endpoints such as laptops and desktop computers.
The main difference between the two goes down to the smallest details of how information is stored. Traditional spinning HDDs store information by changing magnetic polarity on actual spinning disks. Therefore, digital forensic and incident response analysts need to be aware of magnetic fields when handling evidence and why dropping an HDD would often prove fatal for the disk.
The one aspect of HDDs that is of interest to digital forensic examiners is how data is handled. The data is written to the disk and stays within the sectors that have been assigned to the data. When a user deletes a file, it is not removed. The data may be complete or partially overwritten, and with proper imaging tools, this data can be located and reconstructed for analysis.
Because of how HDDs work and the potential for reconstruction of data, it is a good practice to create a physical disk image. This involves powering down the system by removing the source of power, not through the operating system shutdown. This preserves the state of the drive now the analyst has accessed it. In those circumstances where this is not possible, a logical image can be taken from a live and powered-up system.
SSDs, on the other hand, hold information based on the state of electrons in cells in the SSD. This type of data storage uses instructions found on the printed circuit board (PCB) that controls how data is handled on the SSD. The first set of instructions is garbage collection. When a user deletes a file, the operating system sends instructions to the chipset indicating that the file is marked for deletion, and the PCB can reset the electrons in that space to neutral, thereby removing the data. This operating system instruction is often referred to as TRIM. For example, entering the fsutil behavior query disabledeletenotify command into Windows’ Command Prompt will produce the following output if the OS is using an SSD:
Figure 8.3 – TRIM operations enabled
Another feature of SSD chipsets that is of concern to digital forensic and incident response analysts is wear leveling. The electrons in an SSD have a finite lifespan and cannot be continually turned on and off. If the operating system only uses the first 100 GB of the drive, it may wear that section out, making the drive useless. To prevent this, SSDs make use of wear leveling, where data is continually moved to different locations on the drive, thereby reducing the potential of making the drive unusable.
These two features mean that traditional write blockers that are used to ensure that no changes are made to the disk during imaging do not work, as the PCB manages how data is written and leveled on the SSD. While imaging is possible, the analysts cannot ensure that no changes were made to the disk during the process. To limit these changes, analysts should image an SSD in the condition that they found it. If the system is powered off, remove the drive from the system and image. If the system is on, it has to be imaged live.
As with much of the previous material we covered, there are several tools available to a responder for imaging drives. Understanding these tools provides responders with knowledge about which tool to apply to an incident.
While there is no court or legal body that certifies digital forensics imaging tools, there are several methods and associated tools that represent best practices when acquiring disk evidence. Let’s go over these now:
The imaging tools you decide to use will depend on the organization, your training and experience, and which other forensic tools are in use. For example, if an organization uses the Forensic Toolkit (FTK) for analysis, it may be best to use FTK Imager as part of the process. With any imaging tool, it is good practice to ensure that the tool functions properly and that responders have been adequately trained in its use.
Once an imaging tool is selected, the next step is to ensure that the other hardware is ready. This includes ensuring that the destination of stored media is correctly prepared.
Just as important as learning how to handle the evidence drive, having a forensically sound stage drive to which evidence will be imaged is critical. Responders will be walked through how to prepare this item.
Beyond having the necessary hardware and software to perform forensic imaging, it is critical to pre-stage a location to hold the image or evidence file. For incident response teams, the best thing to utilize as an evidence repository is an external USB or FireWire disk drive. This allows a degree of portability as incident responders may have to investigate an incident offsite or at a variety of locations without the benefit of a forensic laboratory.
There are two tasks that need to be performed on evidence drives prior to their use. The first is to ensure that the repository is free of any data. Incident response teams should have a policy and procedure that dictate that an evidence drive be wiped prior to each use. This includes drives that are new in box. This is since a number of manufacturers ship drives with backup software or other data that needs to be removed prior to use.
Wiping further ensures that previously utilized drives are free of any trace data from another incident. This ensures that the evidence collected on a properly wiped drive is not contaminated with unrelated data.
This is easily accomplished through a wiping program. There are several programs, both free and commercial, that can be utilized for this. For example, the Eraser program from Heidi Computers is a freeware wiping utility that can be utilized for both file and volume wiping (Eraser can be downloaded at https://eraser.heidi.ie/).
In the following example, a 2 TB external hard drive will be erased and prepared for use as an evidence drive. The following sequence should be repeated every time a drive is going to be placed into a state that can be utilized for incident investigation:
Figure 8.4 – Setting Eraser task
Figure 8.5 – Eraser drive selection
Figure 8.6 – Erasure method selection
Figure 8.7 – Erase Schedule
Depending on the size of the drive and the system that is performing the wipe, this process can take hours or even days. Once it's complete, the incident response analyst should capture any information that verifies that the evidence drive has been properly wiped. This is important information to include in a written forensic analysis report as it demonstrates that the incident response analyst took appropriate measures to ensure that all evidence files were free from corruption or commingling with other files on the evidence drive.
It is recommended that incident response analysts have several drives available and that these drives be pre-wiped before any incident. This will allow incident response analysts to immediately utilize a wiped drive instead of having to wipe a drive on-site, which wastes time that would be better spent on incident-related activities.
A second preparation step that can be undertaken is to encrypt the evidence drive. Software such as VeraCrypt or another disk encryption platform can be utilized to encrypt the partition of the evidence drive that contains the evidence files. Incident response analysts dealing with confidential information such as credit cards or medical records should encrypt the evidence drive, regardless of whether it leaves the facility or not.
Two methods can be leveraged to encrypt the evidence drive. The first is to utilize encryption software on the forensic workstation that is utilized in the imaging process. This approach is limited to imaging on drives that have been removed from the system and imaged on dedicated systems that have the encryption software installed. A second option is to include encryption software on the evidence drive. In the previous section, an evidence drive was divided into two partitions. One partition was set aside for evidence files, while the second partition was utilized for tools such as those used for dumping memory files or imaging. In this scenario, the encryption software can be loaded in the tools partition, and the drive can be encrypted during the evidence imaging process. This limits the number of changes that are made to the system under investigation.
Once a drive is prepared, another layer of protection is needed to ensure that no changes are made to the suspect system during the imaging process. To ensure that no changes are made, responders should be familiar with and know how to use write blockers.
Write blockers are critical components and ensure that evidence is not tainted during the imaging process. In this section, responders will be exposed to physical and software write blockers.
A key tenet of digital forensics is to ensure that no changes are made to digital evidence while processing and examining it. Any change, no matter how slight, has the potential to bring the entire examination into question. There is a distinct possibility that the evidence may even be excluded from legal proceedings if the responder is unable to articulate how they ensured that the evidence was not tainted during the examination. As a result, it is important to understand how write blockers maintain the integrity of digital evidence.
Write blockers come in two different types. The first of these is a software write blocker. This software sits between the operating system and the evidence. These are often part of any digital forensics tools that are used during the examination phase. They ensure that there is read-only access to the evidence file and that, during the examination, no changes have been made to the evidence. For example, the FTK Imager tool, which will be explored extensively in this chapter, ensures that the acquisition of digital evidence is done without any writes to the disk.
Another type of write blocker is a physical or hardware write blocker. As its name indicates, this is a physical piece of hardware that sits between the evidence drive and the system performing the acquisition. Data is allowed to pass from the evidence disk to the analysis system but not the other way around. The use of this device allows responders to clearly demonstrate that no evidence was altered during the acquisition phase.
Which type of write blocker is used is largely dependent on the type of acquisition that is being conducted. Ideally, responders should choose tools and techniques that clearly demonstrate that they took every reasonable precaution to ensure that the evidence has not been altered. Doing so significantly decreases the risk that the evidence will be excluded from any legal proceedings, and also affords the responder the ability to rely on the evidence while making a root cause determination.
With a properly staged drive and write blocker in place, responders are now able to move on and image evidence drives.
This section is the main part of this chapter in which we will focus on techniques that are available to responders who are called upon to image an evidence drive.
Once a proper repository has been configured for the image file, the incident response analyst is ready to acquire the necessary evidence. Responders will encounter suspect systems that are either powered on or have been shut down. Based on the state that responders find the suspect system in, they will have to utilize one of the following techniques. In any incident, no matter which technique is utilized, incident responders should be prepared to properly document their actions for any subsequent forensic report.
Dead imaging is conducted on media that is not powered on and, in the case of hard drives, removed from the potentially compromised system. In terms of evidence preparation, this method is the most comprehensive as it allows the complete preservation and analysis of a physical volume. There are several methods and tools available, both commercial and freeware, that allow proper imaging. In addition to software, incident response analysts will often make use of a hardware write blocker. These devices ensure that no changes are made to the suspect media. As we discussed in Chapter 1, it is critical to be able to demonstrate to a court of law that no changes were made to the original evidence.
One advantage of imaging a hard drive or other digital media in this manner is that the process can be predefined and repeatable. Having a predefined process that is formalized as part of incident response planning and the procedure itself ensures that evidence is handled in a forensically sound manner.
One tool that is extremely useful in dead imaging is FTK Imager. This tool, provided by Access Data, is a forensically sound platform for acquiring a disk image.
The following process uses a hard drive and FTK Imager to produce a forensically sound image for analysis. Rushing or deviating from these steps may create a situation where the responder may not be able to rely on the evidence’s integrity, thereby making potential evidence unreliable:
Figure 8.8 – Packaging integrity check
Figure 8.9 – Example disk photo
Figure 8.10 – Physical write blocker setup
With the physical write blocker in place, the suspect drive is now ready for imaging. In this example, the FTK Imager freeware application will be used. FTK Imager requires administrator privileges to run. Open the executable; the following screen will appear:
Figure 8.11 – FTK Imager main menu
Figure 8.12 – FTK Imager source selection
Figure 8.13 – Suspect drive selection
Figure 8.14 – FTK Imager Create Image window
Figure 8.15 – FTK Imager Select Image Type window
Figure 8.16 – FTK Imager Evidence Item Information window
Figure 8.17 – FTK Imager Select Image Destination window
Figure 8.18 – FTK Imager Create Image window
Figure 8.19 – FTK Imager Creating Image window
Figure 8.20 – FTK Imager result verification
Dead imaging provides the most forensically sound acquisition; however, there may be times when responders will have to image a system that is powered on. This would necessitate the responder to perform live imaging of a suspect system.
In live imaging, the system is running, and the analyst uses a USB storage drive to house the imaging program and the storage area. One simple technique is to simply copy the FTK Imager directory installed on an imaging workstation to a USB and execute it from there on the target system. Before that, though, the analyst should perform a few checks on the system.
Exterro FTK Imager guidance
FTK Imager can easily be configured to run from a USB device. It is recommended that analysts have at least one or two of these handy. For detailed information on how to configure a USB device, consult the Exterro website: https://exterro.freshdesk.com/support/solutions/articles/69000765662-run-ftk-imager-from-a-flash-drive-imager-lite.
Introduced over a decade ago, Microsoft BitLocker is the native FDE solution used on Windows OS systems. In addition to BitLocker, there are a host of FDE products. These solutions make it difficult for incident response analysts to conduct an analysis of a system. A handy tool to determine if a system is using BitLocker is Magnet Forensics’ Encrypted Disk Detector tool, available at https://www.magnetforensics.com/resources/encrypted-disk-detector/.
Simply download the tool and run it via the command line. For example, the following screenshot shows that the target system is running BitLocker:
Figure 8.21 – Encrypted Disk Detector
An additional check that should be performed is determining if the system has an HDD or SSD and if TRIM is enabled. Refer to the previous section on SSDs for the specific command that can be run.
Responders will often encounter virtual servers and even workstations as part of an investigation. Virtualized systems can be acquired by simply exporting a paused virtual machine (VM) to a removable drive. In other instances, responders can make use of the snapshot feature of a virtual system. This creates a separate file that can be analyzed at the date and time a snapshot is taken. In either case, responders should make sure that the drive has been sanitized properly and that the proper documentation has been addressed.
To acquire a VM, simply pause the system and then move the entire directory to the external media. (In some instances, this can even be accomplished remotely.) In Windows virtual platforms such as VMware, several files make up the virtual image:
Figure 8.22 – ESXi VM files
Let us look at some of the files:
Incident responders can use these files in several ways. First, the .vmdk file can be mounted the same way as an image file can in various digital forensics software platforms. These will be discussed in Chapter 9. Second, the .vmsn file can be used to reconstruct the system by simply copying the file and working with the facsimile. From here, responders can look at the behavior of the system or extract evidence without impacting the original .vmsn file.
Finally, the running memory that is captured through the .vmem and .vmss files can be analyzed in much the same way you would analyze other memory captures. To obtain the proper forensic data, the two files must be combined. This can be done by utilizing the vmss2core.exe tool, which is included as part of the VMware suite of tools. To combine these files, the following command syntax needs to be used:
C:VirtualToolsvmss2core.exe -W "InfectedServer.vmss" "InfectedServer.vmem"
The preceding command will produce a memory dump in the directory containing the two files.
Although virtualization is common in large enterprises, it should not represent a significant challenge. In some ways, the ability to simply pause a system and extract all the necessary files makes extracting the necessary evidence faster.
Thus far, the focus has been on Windows tools for imaging. Another option available to incident responders is the use of Linux imaging tools. There are a variety of tools that provide write-blocking and imaging capabilities that are often open source.
Chapter 3 provided an overview of various forensic tools that are available to the incident response analyst. Some of these tools include Linux distributions that can be leveraged during an incident for various digital forensics tasks. The following example will demonstrate how a Linux distribution with forensics applications can be deployed to capture a forensically sound image of a potentially compromised computer.
The combination of a Linux distribution and a bootable USB device is an option you can use to conduct forensic imaging of potentially compromised systems. Incident response analysts may find themselves in a situation where multiple systems need to be imaged and the analysts have only one write blocker. A great deal of time will be wasted if the analyst must image each one of these systems in sequence. In this situation, the analyst can avoid this by creating a bootable USB drive for each system and imaging each one at the same time. All that the analyst needs are an evidence drive and a bootable USB drive for each source of evidence. Utilizing this technique will allow the analyst to image each system at the same time, saving time that is better spent on other activities.
In this scenario, the Computer Aided INvestigative Environment Live (CAINE) Linux distribution will be utilized to image the hard drive from a potentially compromised system. First, the system is powered off and the bootable USB device containing the CAINE OS is installed. The suspect system is then powered on. Incident response analysts should be aware of how to change the boot order of a system to ensure that it boots to the USB device. Analysts should also be prepared to immediately power down the system if it attempts to boot into the native OS and not the USB device. Let’s get started:
caine@caine:~$sudo fdisk -l
The fdisk -l command lists all partitions that are visible to the CAINE OS. The output will look like this:
Figure 8.23 – fdisk output data
In the preceding screenshot, the first disk indicated is SDA, with 447.13 GB of storage. Further down, the SDA disk is divided into three separate partitions. The partition labeled SDA2 is the boot partition. With the SDA3 partition, it has a size of 387.7 GB, as shown by the cursor arrow. This is the data storage area where the bulk of the digital evidence will be located. It is the SDA disk that will be imaged.
Scrolling down through the output, the evidence and CAINE OS drive are also visible:
Figure 8.24 – fdisk output data
In the preceding screenshots, there are three separate disks, each with its own partitions. The disk labeled /dev/sdc is the USB drive that contains the CAINE OS that the system has been booted from. The /dev/sdb disk is the evidence drive that the system will be imaged to. Finally, the target system is labeled as /dev/sda.
Figure 8.25 – UnBlock device selection
caine@caine:~$ sudo mkdir /mnt/Disk_Images
caine@caine:~$sudo mount /dev/sdb2 /mnt/Disk_Images
Now, the evidence drive has been mounted on the mount point that was created.
caine@caine:~$ cd /mnt/Disk_Images
caine@caine:~$ mkdir Incident2022-034
caine@caine :/ mnt /Disk_Images$ cd Incident2022-034
caine@caine:/mnt/Disk_Images/Incident2022-034$ dc3dd if=dev/sda of=ACMELaptop056.img hash=md5 log=ACMELaptop56.txt
The preceding command contains dc3dd. Start by imaging the disk at sda to the evidence drive and output the image file with the name ACMELaptop056.
The command also has Dc3dd hash the image file with the MD5 algorithm. Finally, an ACMELaptop56.txt log file is created that can be utilized for reporting purposes. Running the command produces the following output:
Figure 8.26 – dc3dd command and output
Figure 8.27 – Dc3dd imaging completion
Figure 8.28 – Dc3dd output files
dc3dd 7.2.646 started at 2022-05-24 22:17:14 +0200
compiled options:
command line: dc3dd if=/dev/sda of=ACMELaptop056.img hash=md5 log=ACMELaptop56.txt
device size: 937703088 sectors (probed), 480,103,981,056 bytes
sector size: 512 bytes (probed)
480103981056 bytes ( 447 G ) copied ( 100% ), 11176,1 s, 41 M/s
input results for device `/dev/sda':
937703088 sectors in
0 bad sectors replaced by zeros
9fc8eb158e5665a05875f4f5f2e6f791 (md5)
output results for file `ACMELaptop056.img':
937703088 sectors out
dc3dd completed at 2022-05-25 01:23:30 +0200
Linux is a viable option when it comes to acquiring disk evidence. One significant advantage it has is that it is easy to scale. In the event that multiple systems have to be acquired, responders can use several USB storage drives and Linux USB devices and acquire them in parallel, rather than waiting for software to become available. CAINE is an excellent option for this as the included write blocker also affords a measure of evidence integrity in the process.
Imaging is a critical process for responders to understand. The incident will often dictate which technique should be used. In any incident, though, responders should ensure that the process is conducted in a sound manner as the subsequent investigation will often rely on data acquired from these systems.
Not every incident will dictate the need to obtain an image from a potentially compromised hard drive or another volume. Regardless, incident response analysts should be familiar with, and able to perform, this function when called upon. The evidence that’s found on a hard drive may be critical to determining a sequence of events or to obtaining actual files that can aid in determining the root cause of an incident. This is the central reason why responders need to understand the fundamentals of imaging and the tools and processes involved, how to create a stage drive, how to use write blockers, and how to execute any of the imaging techniques we mentioned in this chapter. As with any process that’s performed in a forensic discipline, imaging should be conducted in a systematic manner in which all the steps are followed and properly documented. This will ensure that any evidence that’s obtained will be sound and admissible in a courtroom.
In the next chapter, we will discuss examining network-based evidence in relation to the network activity that is associated with an incident.
Refer to the following resources for more information about the topics covered in this chapter: