11

Analyzing System Storage

So far, the evidence that has been analyzed has focused on those elements that are obtained from the network traffic or the system’s memory. Even though an incident’s root cause may be ferreted out from these evidence sources, it is important to understand how to obtain evidentiary material from a system’s storage, whether that is removable storage such as USB devices or the larger connected disk drives. These containers carry a massive amount of data that may be leveraged by incident response analysts to determine a root cause. It should be noted that this chapter will only be able to scratch the surface as entire volumes have been devoted to the depth of forensic evidence that’s available.

To provide a better understanding of analyzing system storage, this chapter will focus on the following topics:

• Forensic platforms: There are a variety of commercial and open source platforms that we can use to conduct system storage analysis. This section will address the key features and potential options we have.
• Autopsy: To provide you with an open source platform that can be leveraged in system storage analysis, the majority of this chapter will use the Autopsy tool. Some of its features will be highlighted by utilizing a test image.
• Master File Table (MFT) analysis: Containing a comprehensive list of all the files on the system, the MFT is a key source of data for responders. This section addresses the extraction and analysis of the MFT.
• Prefetch analysis: Determining if a potentially malicious file has been executed is a key piece of incident investigations. This section will cover extracting a Windows Prefetch file, processing it, and conducting an analysis.
• Registry analysis: A favorite target of malware coders and other exploits, responders should become familiar with registry analysis. An overview of how to extract and analyze the registry will be addressed in this section.

System storage analysis is a complex process. The depth and breadth of it cannot be explored in a single chapter; due to this, we hope that this chapter provides some concrete areas of focus with the understanding that responders will gain a better sense of some of the tools that can be employed, as well as an understanding of some of the critical data that can be leveraged.

Forensic platforms

Over the past 15 years, there has been an increase in the power of disk forensics platforms. For the incident response analyst, there are options as to what type of platform can be leveraged to examine disk drives. Often, the limiting factor in utilizing these platforms is the cost of more robust systems, when a lower-cost alternative will be just as effective for an incident response team.

Several factors should be addressed when examining software for disk analysis. First, has the platform been tested? Several organizations test platforms for efficacy, such as the National Institute of Standards and Technology Computer Forensic Tools Testing Program (https://www.cftt.nist.gov/). Second, the tool’s use in criminal and civil proceedings must be examined. There is no single court-accepted standard, but tools should conform to the rules of evidence. The use of a platform that has not been tested or does not conform to the rules of evidence may lead to the evidence being excluded from legal proceedings. In other, more disastrous consequences, it may lead to an analyst arriving at the wrong conclusion.

Forensically sound tools

An example of an untested and forensically unsound toolset that was used in a criminal proceeding was in the case of The State of Connecticut versus Amero. In this case, a law enforcement agency utilized unsound forensic methods and tools to convict a woman for allegedly allowing children to see sexually explicit pop-up ads. A subsequent review of the methods and facts of this case indicated that there were significant deficiencies with the forensic examination. An excellent examination of this case is also available from the Journal of Digital Forensics, Security, and Law at https://commons.erau.edu/jdfsl/vol7/iss2/5/.

One final consideration is how the tool fits into the overall incident response planning. For example, commercial disk forensics tools are excellent at locating images and web artifacts. They are also excellent at carving out data from a suspect's drive. This is often because forensic software is utilized by law enforcement agencies as a tool to investigate child exploitation crimes. As a result, this capability is paramount to bringing a criminal case against such suspects. While these are excellent capabilities to have, incident responders may be more interested in tools that can be utilized for keyword searches and timeline analysis so that they can reconstruct a series of events before, during, and after an incident.

While most commercial and free forensic platforms have a variety of features, several common ones can be of use to incident response personnel:

• File structure view: It is often very important to be able to view the file structure of the disk under examination. Forensic platforms should have the ability to view the file structure and allow responders to quickly review files with known locations on a suspect system.
• Hex viewer: Having the ability to view files in hexadecimal allows responders to have a granular look at the files under examination. This may be beneficial in cases involving malware or other custom exploits.
• Web artifacts: With a great deal of data stored on the drive associated with web searching, forensic platforms should have the ability to examine these pieces of data. This is very handy when examining social engineering attacks where users navigate to a malicious website.
• Email carving: Incident responders may be called into cases where malicious employees are involved in illegal activities or have committed policy violations. Often, evidence of this type of conduct is contained within emails on the suspect system. Having a platform that can pull this data out for immediate view assists the analyst in viewing communication between the suspect system and others.
• Image viewer: Often, it is necessary to view the images that are saved on systems. As we mentioned previously, law enforcement may utilize this feature to determine whether there is evidence of child exploitation on a system. Incident responders can utilize these features to determine whether there has been a policy violation.
• Metadata: Key pieces of data about files such as date and time created, file hashes, and the location of a suspect file on the disk are useful when examining a system associated with an incident. For example, the time an application is run, taken in conjunction with a piece of malware, may be correlated with network activity, allowing the analyst to determine the actual executable run.

In terms of commercial options, the following three platforms are generally accepted as sound and are in use by commercial and government entities all over the world. Each uses the features we described previously, among other, more specialized, tools:

• OpenText EnCase: Arguably the preeminent forensics platform, EnCase has a long history of being the platform that’s used in major criminal investigations, such as the BTK Killer. EnCase is a feature-rich platform that makes it a powerful tool in the hands of a trained analyst. In addition to disk forensics, EnCase also has integrated features for mobile devices. This is a powerful capability for organizations that may have to analyze not only disks but also mobile devices in connection with an incident.
• AccessData Forensic Toolkit: In Chapter 6, the FTK Imager tool was utilized to acquire disk and memory evidence. This tool is part of a suite of tools provided by AccessData that have been specifically tailored for disk forensics. In addition to the imager, Access Data has a full-featured forensic platform that allows responders to perform a range of tasks associated with an incident. FTK is in use by law enforcement agencies such as the Federal Bureau of Investigation (FBI) and has proven to be more than effective in assisting responders with incident investigations.
• X-Ways Forensics: One drawback of FTK and EnCase is cost. These platforms can cost several thousands of dollars per year. For larger organizations, such as government agencies and large enterprises, the trade-off of cost versus features may not be an issue. For smaller organizations, these platforms may be cost-prohibitive. An alternative, feature-rich forensic platform is X-Ways. This platform can perform a variety of tasks but at a fraction of the cost. Another great benefit of X-Ways is that it is less resource-intensive and can be run off a USB device, making it an alternative platform, especially for incident response.

Each of these platforms has a rich feature set and provides responders with a powerful tool for conducting a wide range of forensic tasks. The specific tools in each of these platforms are outside the scope of this book. As such, it is recommended that responders are trained on how to use these platforms to ensure that they fully understand these tools’ capabilities.

Autopsy

One alternative to commercial forensics programs is Autopsy. Autopsy is a GUI-based forensic platform based on the open source The Sleuth Kit toolset. This open source platform provides features that are commonly found in commercial platforms. This includes timeline analysis, keyword searching, web and email artifacts, and the ability to filter results on known bad file hashes. One of its key features is its ease of use. This allows incident responders to have a light platform that focuses on critical tasks and obtain the critical evidence that’s needed.

Installing Autopsy

Several of the Linux distributions we discussed previously have Autopsy preinstalled. It is good practice for responders to ensure that the platform they are using is up to date. For the Windows operating system, download the Microsoft self-installer file located at https://www.sleuthkit.org/autopsy/download.php. Once downloaded, execute the MSI file and choose an install location. Once you’ve done this, the application will be ready to use.

Starting a case

Once Autopsy has been installed, the analyst can open a case with very little pre-configuration. The following steps will discuss the process of opening a new case:

1. To begin an analysis, ensure that the entire disk image is contained in a single directory. This allows the entire image to be utilized during the analysis:

Figure 11.1 – E01 files

In the preceding screenshot, an image file has been taken from a suspect system. The image has been divided into two separate files. Looking back to Chapter 8, imaging applications such as FTK Imager will divide an image into multiple files. So long as the separate files are in the same directory, Autopsy will be able to take the two files and reconstruct the entire volume that has been imaged.

Sample image file

For our examination of Autopsy, a sample image file taken from a Windows 10 system can be found at https://cfreds.nist.gov/all/MagnetForensics/2022WindowsMagnetCTF. For more practice, additional testing images can be downloaded from the Computer Forensic Reference Data Sets located at https://www.cfreds.nist.gov/.

2. Open Autopsy. The following window will appear; select New Case:

Figure 11.2 – Autopsy – creating a new case

3. A second window will appear where the analyst will input the case’s title. In addition, the path to Autopsy that will store the files associated with the case can also be set. This is useful when circumstances dictate that the analyst must place the files in a specific container, including external drives. Once done, click Next:

Figure 11.3 – Autopsy – New Case Information

4. On the next window, the responder should input the case number, their name, their contact information, and a brief description of the case in Notes. Click Finish:

Figure 11.4 – New Case Information – Optional Information

Adding evidence

One way to think of the case is as a container for all the related case data and evidence related to an incident. Autopsy allows the analyst to add multiple data sources such as disk images and virtual machine disks as well. At this stage, we will load the E01 file as a data source:

1. Once the case details have been entered, the analyst will need to load the image file that was created previously. Click on the Add Data Source button in the top left-hand corner of the Autopsy window:

Figure 11.5 – Add Data Source – Select Host

Autopsy can automatically detect the hostname. If the analyst knows the hostname, it can be added in the Specific new host name field. From a best practices perspective, if known, the host’s name should always be entered. Once complete, click Next.

2. Select the appropriate data source type. In this case, the examination will be conducted against an image file that was forensically acquired. Autopsy can also examine .vmdk files. This is a handy feature in environments where virtualization is utilized for systems. This feature allows the analyst to examine a VM file, without having to acquire it via tools such as FTK Imager:

Figure 11.6 – Add Data Source – Select Data Source Type

3. Once the data source type has been selected, browse to the image location. This folder contains several image files; select the file that ends in E01. Loading this file will include all the subsequent image files located in that folder. Next, select the appropriate time zone. As a matter of best practice, analysts should select a time zone that is uniform across the investigation. In that case, the best option is to select UTC. Once done, click Next:

Figure 11.7 – Selecting the E01 file

4. The next screen allows the analyst to tailor the modules in use. Depending on the type of investigation, some of these options can go unchecked. In the beginning, though, the analyst should select all of them to ensure that all the necessary information is available for examination.

One other option is to process unallocated space (this is important!). This captures all the information in the space that’s not currently allocated to data on the hard drive. There are methods where unallocated space can be utilized to hide information. Once done, click Next:

Figure 11.8 – Add Data Source – Configure Ingest

This will start the processing procedure:

Figure 11.9 – Data source processing

5. On the next screen, verify that the data source has been loaded and click Finish. This will start the process of adding the E01 file as a data source:

Figure 11.10 – Data source complete

Autopsy will now go through the process of analyzing the files from the image. Depending on the size of the image, this will take between several minutes and a couple of hours. The process bar in the lower-right corner of the screen will show its progress. How long this process takes is often dependent on the processing speed of the computer, as well as the size of the image file(s). At this point, Autopsy will start to populate the specific fields in the left-hand pane, even though additional processing is taking place. The lower right-hand corner of the GUI will show the progress of the processing:

Figure 11.11 – Evidence source processing

As was stated earlier, processing may take some time, depending on the forensic system’s specifications and the size of the file. Analysts can conduct some analysis with the understanding that not all data may be available.

Navigating Autopsy

The Autopsy GUI is divided into three main sections. These sections display details relating to the system and specific files. When Autopsy has finished processing a new case or opening an existing case, the analyst will see the following window:

Figure 11.12 – Autopsy GUI

As shown in the previous screenshot, Autopsy is divided into three main panes. The first of these is the left-hand pane, which contains the data sources and file structure, as well as search results. Clicking on the plus (+) sign expands the results while clicking on the minus (-) sign collapses them. This allows the analyst to access the system at a high level, and also drill down to specific elements. The center pane contains directory listings or results from searches. For example, the following screenshot shows the Program Files directory that was located on the system:

Figure 11.13 – Autopsy’s center pane

Finally, the bottom pane contains the metadata and other information about individual files contained in the center pane. In this example, the desktop.ini file has been selected. Clicking on the File Metadata tab displays information specific to that file:

Figure 11.14 – File metadata

Finally, the file’s hexadecimal content can be viewed by clicking on the Hex tab:

Figure 11.15 – Hex view

This view is excellent if an analyst wants to inspect an application or another file that is suspected of being malware.

What Autopsy offers is the ability to perform some of the actions and analyses that can be found on other commercial platforms. However, it should be noted that in the case of more complex investigations, it may become necessary to utilize more sophisticated platforms. Autopsy also provides responders that are new to disk forensics with a more user-friendly platform so that they can gain experience with one before they move on to a more sophisticated commercial solution.

Examining a case

Once the case has been processed, the left-hand pane will be populated with the number of artifacts located in the system:

Figure 11.16 – Autopsy’s artifacts pane

In the previous screenshot, there are several items listed under the Data Artifacts portion. These include looking at programs that have been installed, the operating system’s information, and recent documents. Another key feature of Autopsy is the ability to examine the entire folder structure of the image file. Clicking on the plus (+) sign next to Data Sources expands the entire folder structure. This is useful if, through other sources, an analyst can identify the location of a suspect file:

Figure 11.17 – Data Sources

Different data points can be examined by utilizing Autopsy. What to search for and how to search for it is often dictated by the type of incident or examination under investigation. For example, a malware infection that originates from a compromised website may involve examining the system for URLs that the user may have typed in or otherwise accessed via a browser. Furthermore, the actual file may be located by utilizing information that’s been obtained by examining the system memory, which we covered in the previous chapter. For example, if an analyst was able to locate a suspect process and was subsequently able to also locate the executable, they may utilize Autopsy to find the last time the executable was launched. This can provide responders with a time so that they can examine other systems for evidence of compromise.

In another scenario, responders may be tasked with identifying whether an employee accessed confidential files so that they could pass them on to a competitor. This may involve examining the system for the times and dates when files were accessed, email addresses that may have been used, external cloud storage sites that were accessed, or USB storage that was connected to the system. Finally, a full list of these files may provide insight into the confidential documents that were moved.

Web artifacts

There are several types of incidents where it may be necessary to examine a system for evidence of malicious activity that’s been conducted by a user. Previously, we mentioned accessing cloud-based storage where a malicious insider had uploaded confidential documents. In other circumstances, social engineering attacks may have an unsuspecting employee navigate to a compromised website that subsequently downloads malicious software. In either case, Autopsy provides us with the ability to examine several areas of web artifacts.

The first of these web artifacts is web history. In the event of a social engineering attack that involves a user navigating to a malware delivery site, this data may provide some insight into the specific URL that was navigated to. This URL can then be extracted and compared with known malicious website lists from internal or external sources. In other cases, where an insider has accessed an external cloud storage site, the web history may provide evidence of this activity. Let’s take a look at this case in detail:

1. Clicking on the Web History section in the left-hand pane opens the center pane and shows detailed information concerning a URL that was accessed by the system:

Figure 11.18 – Web History

2. In the preceding screenshot, Autopsy indicates that the website hacker-simulator.com was accessed by this system. Further information provided by Autopsy allows the analyst to evaluate other information, such as the location of the artifact and what type of browser was used. This information can be accessed via the Data Artifacts tab in the lower Results pane:

Figure 11.19 – Web history metadata

3. Another source of data that is useful in investigations is Web Downloads in the Data Artifacts section. A common technique used by threat actors is to direct users or scripts to download secondary exploits or malware. This can include hacking tools and other scripts, often using the system’s capability to download from websites. In this case, if we click on Web Downloads, we can see the path to the downloaded file, along with the URL the file was downloaded from:

Figure 11.20 – Web Downloads

4. In addition, Autopsy provides the metadata of the specific downloaded file under examination. Clicking on the File Metadata tab produces the following data:

Figure 11.21 – Web download metadata

As the preceding screenshot shows, there are some more details concerning the downloaded file. For example, the analyst can gather time information, file location, and an MD5 hash, which can be utilized to compare any extracted files that are examined further. In some circumstances, a suspect may decide to delete the browsing history from the system to hide any malicious activity. Another location that may provide evidence of sites that have been accessed by a malicious insider is web cookies. These can be accessed in the left-hand pane under Web Cookies. Clicking on this produces a list of the cookies that are still on the system:

Figure 11.22 – Web Cookies

Depending on the type of incident, web artifacts can play an important role. Autopsy has some functionality for this, but responders may find that other commercial solutions provide a much more robust platform. Evidence Finder by Magnet Forensics (www.magnetforensics.com) scours the entire system for internet artifacts and then presents them in a way that is easy for the analyst to view. Another key advantage of commercial solutions such as this is that their functionality is updated continuously. Depending on the frequency of internet and web artifact searching, the inclusion of tools such as this may be beneficial.

Email

Locating suspect emails continues to be a task that incident responders often engage in. This can include externally caused incidents such as social engineering, where responders may be tasked with locating a suspect email that had malware attached to it. In other circumstances, malicious insiders may have sent or received communication that was inappropriate or violated company policy. In those cases, responders may be tasked with recovering those emails so that they can be included in termination proceedings or legal action.

Autopsy can locate emails contained in the system. From these emails, they may be able to identify one or more suspicious emails and domains that can be further researched to see if they are associated with social engineering or other malicious activity. Simply click on Keyword Hits and then the Email Addresses tab in the left-hand pane. From there, the analyst can see the email addresses that are located on the system:

Figure 11.23 – Email addresses

Next, let’s look at attached devices.

Attached devices

Another key piece of evidence that may be useful to an analyst is data about when specific devices were attached to the system. In the scenario of a malicious insider attempting to steal confidential documents, knowing whether they utilized a USB device would be helpful. Autopsy utilizes the registry settings located on the system to identify the types of devices attached and the last time that they were used. In this case, the output of clicking Devices Attached in the left-hand pane produces the following results:

Figure 11.24 – USB devices

Drilling down into the Data Artifacts tab, the analyst can identify the type of device and the date and time that the USB device was attached:

Figure 11.25 – USB device artifacts

Finally, a more detailed examination of the Source File Metadata area would show additional data that can be utilized to reconstruct the time that the USB device was accessed on the system:

Figure 11.26 – Device entry metadata

Next, let’s look at deleted files.

Deleted files

Files that have been deleted can also be reconstructed, either partially or completely. The Windows operating system will not delete files when the user selects deletion. The operating system will mark the space a deleted file takes up in the Master File Table (MTF) as available to write new files to. As a result, responders may be able to view deleted files that have not been overwritten.

Solid-state drives

As discussed in Chapter 8, keep in mind the challenge that forensic analysts have when examining solid-state drives (SSDs). Deleted files can often be recovered from traditional platter hard drives, even after a system is powered down. With SSDs, the operating system will often remove deleted files to make storing files more efficient. The following website has an excellent breakdown of this if you want to find out more: https://www.datanarro.com/the-impact-of-ssds-on-digital- forensics/.

To view the deleted files on a system, click on Deleted Files in the left-hand pane. From here, the analyst can see all of the files that have been marked for deletion:

Figure 11.27 – Deleted files

From here, the analyst can search through deleted files. These files may hold evidentiary value. For example, in the case of malicious insider activity, if several sensitive files are found in the deleted files, all of which have been deleted within the same time, it may be indicative of the insider attempting to cover their tracks by deleting suspicious files.

Keyword searching

One key advantage that forensic applications have is the ability to perform keyword searches. This is especially advantageous as disk drives have gotten larger and responders would have to parse through an overwhelming quantity of data. Keywords are often derived from other elements of the investigation or by using external sources. For example, if an analyst is investigating a malware incident, they may use a suspicious DLL or executable name from the analysis of the memory image. In other instances, such as a malicious insider being suspected of accessing confidential information, keywords in those documents, either secret or confidential, can be used to see if the suspect used the system to access those files.

Autopsy can perform keyword searches while utilizing an exact or a substring match. For example, let’s say an analyst has been tasked with determining what evidence can be located concerning the ZeroTier One executable, which had been located in the Web Downloads entries. The analyst is tasked with locating any trace evidence that would indicate that the file was executed and if possible, identify the user.

The analyst would navigate to the top-right corner and input ZeroTier One in the field. In this case, an exact match will be utilized. Once selected, they would click the Search button. The left-hand pane will indicate whether there were any hits on that text. In this case, the pricing decision has 82 hits:

Figure 11.28 – Keyword search hits

As shown in the preceding screenshot, the center pane will contain a list of the files that contained the hits. One file that stands out is the Master File Table entry. This entry shows the dates and times the file was first placed on the system, along with any modifications and changes:

Figure 11.29 – Master File Table entry

Further review shows a Windows PowerShell event log entry, which shows that the application was executed by the user account Patrick based on the file path:

Figure 11.30 – Keyword search results

Digging further into the hits, there is an entry within the Windows PowerShell Operational event logs indicating that the executable was associated with a network connection established via a PowerShell script:

Figure 11.31 – Keyword PowerShell script

Further down within the entry is a Base64-encoded PowerShell script entry:

Figure 11.32 – Base64 PowerShell script

Taken together, this may point to some suspicious activity. For example, ZeroTier One is a commercial VPN solution, so it is not out of the ordinary for it to be establishing a connection. What is suspicious is the Base64-encoded PowerShell script, which is often used by adversaries to download additional malware or perform malicious actions. We will look at some of these scripts later in Chapter 16.

Next, we will look at how Autopsy can build a timeline of the system’s activity.

Timeline analysis

When investigating an incident, it is critical to have an idea of when applications or files were executed. Timestamps can sometimes be found in other aspects of the investigation, such as when examining memory images. Also, identifying specific DLL files or executable files in the memory image can be compared to the date and time they were accessed to correlate other activity that’s been observed on the system.

Time normalization

One aspect of digital forensics that bears repeating is to ensure that all the systems are using the same time zone. With network systems, this is usually accomplished with the Network Time Protocol (NTP). There are times when systems do not have normalized time through NTP. Responders should take great care in understanding what time zone and synchronization should be used. The best practice regarding time is to set all the systems to UTC. This is critical if an organization is geographically diverse.

Autopsy has functionality specifically for timeline analysis. Simply clicking on the Timeline button at the top of the window will make Autopsy begin the process of parsing out timeline data. Depending on the size of the image file being analyzed, it may take a few minutes. Once completed, the following window will open:

Figure 11.33 – Timeline viewer

From here, the analyst can utilize several features. First is the text filter on the left-hand side of the screen. Using this, the analyst can search for specific text in files. For example, the analyst has already identified that the executable named ZeroTier One had been executed on the system under investigation. If the analyst would like to know whether that file was accessed at any other times, they could enter pricing into the Text Filter box and click Apply, which would produce the following results:

Figure 11.34 – Keyword timeline

From this graph, the analyst can further drill down into the specific times the file was accessed by clicking on the colored bars. The responders can now see that the executable was only accessed at one particular date and time from this system.

Next, we will look at extracting specific evidence items from a disk image and processing them with additional tools.

Master File Table analysis

Another technique that can be leveraged for timeline analysis is utilizing external tools to analyze the MFT. Autopsy allows the analyst to export the MFT for analysis using third-party tools. In this case, we will use MFT Explorer, one of several tools developed by Eric Zimmerman.

Eric Zimmerman's tools

Eric Zimmerman is a former FBI agent, SANS course developer, and digital forensics expert. He has created a suite of tools for carving and analyzing data available at https://ericzimmerman.github.io/#!index.md. Additionally, the SANS Institute has created a cheat sheet for the tools available at https://www.sans.org/posters/eric-zimmerman-tools-cheat-sheet/.

In this instance, we will look at processing the MFT from the image that was examined with Autopsy. The MFT can be found within the root directory of the filesystem. Find the $MFT file, right-click it, select Extract Files, and then save the file to an evidence drive. As good practice, change the name to something that reflects the case.

Next, find the MFTECmd.exe executable. The following command processes the MFT and outputs the results to a Comma-Separated Value (CSV) file:

C:UsersforensicsDocumentsimmmermanTools>MFTECmd.exe -f "D:Suspect_$MFT" --csv "D:" --csvf SuspectMFT.csv

The CSV file can now be opened and examined. In this case, the CSV has been opened via Microsoft Excel. This allows for keyword searching and examination of times and dates to identify when a file or files were placed on the system. Going back to the previous keyword search, we can use the filter option within Excel. Under the ParentPath column, the ZeroTier keyword has been entered:

Figure 11.35 – ZeroTier filter MFT results

The MFT can be difficult to work with in terms of the amount of data. In this case, the MFT has over 410,000 separate entries that may need to be sorted through. It is a good idea to have a starting point such as a date and time or a filename to search for. This allows analysts to work with only those results that are pertinent. Other tools, such as Eric Zimmerman’s Timeline Explorer, can be used to process and extract those data points that are important to the investigation.

Now that we have looked for the presence of the file on the system, we can look at evidence of execution.

Prefetch analysis

One question that analysts will often have to answer is determining if an executable has run. One of the best sources of data to answer this question is Prefetch files. When an application or other executable is run, a file is created and stored within the C:WindowsPrefetch directory. If the program is run in multiple locations, an entry is created for each of these. Another key aspect of Prefetch files is that they are not deleted when the application or program has been deleted. So, if an adversary is attempting to clean up the system of malicious executables or DLL files, proof of their execution may still be located in the Prefetch directory.

The Prefetch files do have some quirks that should be understood. First, even unsuccessful program execution can still produce a Prefetch file. It should be noted that the operative word is can, meaning that not every unsuccessful execution creates a file. Second, the Prefetch directory is specifically limited to 1,024 separate files. Older files are overwritten in favor of new files. On most end user systems, this generally does not present an issue if analysts can capture the evidence promptly. Third, a program that has been previously executed can still create a new Prefetch file. Finally, there is a time lag with Prefetch files. In general, the creation of the file itself might be 10 seconds off other time stamps an analyst may find.

Acquiring the Prefetch directory is straightforward. Triage tools, like those that were discussed in Chapter 6, can collect the directory. The directory can also be extracted directly through Autopsy. Simply navigate to the Prefetch directory and right-click and select Extract Files. Select the directory to output the files to. It is good practice to place the output in an evidence drive or use Autopsy’s default export directory. Once extracted, the Prefetch entries will look as follows:

Figure 11.36 – Prefetch file entries

This output directory can then be processed with the Prefetch parser with the following command:

C:UsersforensicsDocumentsimmmermanTools>PECmd.exe -d D:Suspect_Prefetch -q --csv D: --csvf suspect_prefetch.csv

The previous command outputs two files. The first is a CSV that contains the Prefetch entries. The second contains a timeline breakdown. Let’s look at the timeline version. The CSV file’s output allows for the same type of searching and filtering that was used in the previous section, Master File Table analysis. In this case, again, we will use ZeroTier for filtering. In this case, the search reveals several entries showing the execution of the ZEROTIER_DESKTOP_UI.EXE executable:

Figure 11.37 – ZeroTier Prefetch entries

Registry analysis

There is a great deal of activity that occurs under the hood of the Windows operating system. One place where this activity occurs and is documented is in the Windows Registry. The Windows Registry is a database that stores the low-level system settings for the Windows operating system. This includes settings for devices, security, services, and the storage of user account security settings in the Security Accounts Manager (SAM).

The registry is made up of two elements. The first is the key. The key is a container that holds the second element – the values. These values hold specific settings information. The highest-level key is called the root key and the Windows operating system has five root keys, all of which are stored on the disk in the registry hives. These registry hives are located in the %SystemRoot%system32config folder on the Windows file structure:

• HKEY_CURRENT_USER
• HKEY_USERS
• HKEY_CLASSES_ROOT
• HKEY_LOCAL_MACHINE
• HKEY_CURRENT_CONFIG

Of the five root keys, the most valuable during an incident investigation is the HKEY_LOCAL_MACHINE or HKLM key. This key contains the following subkeys (these are the ones that are the most interesting during an investigation):

• SAM: This is the location where the Windows OS stores the user’s passwords in the LM or NTLM hash form. The main purpose of the SAM subkey is to maintain the Windows account passwords.
• Security: This subkey contains the security information of the domain that the system is connected to.
• Software: The software subkey is the repository for software and Windows settings. This subkey is often modified by software or system installers. This is a good location to check for additions or modifications that have been made to the software by malware.
• System: This subkey stores information about the Windows system configuration. One key piece of evidence that is also included within the system subkey is the currently mounted devices within a filesystem.

Another source of data that can be critical to an incident investigation is the HKEY_CURRENT_USER key. Attackers may make changes to a user account or profile as part of a privilege escalation attack. Changes that have been made to the user’s data are recorded in that user’s NTUSER.dat file. An NTUSER.dat file is created for every user account on the system and is located at C:Users*UserName*. This file contains the user’s profile settings and may provide additional data on the systems that are connected, network connections, or other settings. Data contained within the HKEY_CURRENT_USER key may be of benefit in some incidents where user activity or user account modification of the system is suspected.

Responders can access the various registry hives using Autopsy. Simply navigate to the Windows/System32/config folder from the file structure in the left-hand pane:

Figure 11.38 – Registry location

The SAM registry file is located in the center pane:

Figure 11.39 – SAM location

The actual examination and evidentiary value of registry key settings are, like many aspects of digital forensics, very detailed. While it is impossible to cover all of the aspects of registry forensics in this chapter, or even in this book, it is important for responders to be able to acquire the registry keys for evaluation, and also to have some familiarity with tools that can allow responders to gain some hands-on experience with evaluating registry settings.

In this case, the system, SAM, security, and software registry keys will be acquired for analysis. For this, the analyst can use Autopsy to acquire the proper keys and then examine them with a third-party tool. Let’s take a look at how to do this:

1. First, navigate to the proper folder, /System32/config, on the applicable volume of the system image.
2. Next, select the four registry keys using the right mouse button and the Ctrl key. Right-click on one of the files and select Export File(s).
3. Select a folder to output the registry keys to. In this case, a separate file folder was created to contain the keys. Select Save.
4. Verify that the registry keys have been saved:

Figure 11.40 – Suspect registry

The Windows operating system records and maintains artifacts of when USB devices such as mass storage, iOS devices, digital cameras, and other USB devices are connected. This is due to the Plug and Play (PnP) manager, which is part of the Windows operating system. The PnP receives a notification that a USB has been connected and queries the device for information so that it can load the proper device driver. Upon completion, the Windows operating system will make an entry for the device within the registry settings.

To determine what USB devices were connected, follow these steps:

1. Open Registry Explorer.
2. Click File and then Load Hive.
3. Navigate to the system registry hive. (Depending on the files, there may be errors related to Dirty Hives. It is normal to see this; they can be processed with Registry Explorer.)

Once loaded, the following window will appear:

Figure 11.41 – Registry Explorer view

4. From here, navigate to the proper USB registry location at ROOTControlSet001EnumUSB:

Figure 11.42 – USB registry key location

5. Click on the first registry value, VID_05C8&PID_0815&MI_00, and then 6&a631fef&0&000. The following information will appear in the top-right pane:

Figure 11.43 – Registry values

From here, the analyst has a lot of information they need to review. Of particular importance is the hardware ID. Clicking on that section of the output produces the following in the lower-right window:

Figure 11.44 – HardwareID data

As we mentioned previously, registry analysis is a deep subset of digital forensics in and of itself. Whole volumes have been written on the evidentiary value present in the settings and entries in registry hives. At a minimum, responders should be prepared to acquire this evidence for others for further examination. That being said, as responders gain more and more experience and skill, the registry should be an area that can be leveraged for evidence when examining a disk image.

Summary

In many ways, this chapter just scratches the surface of what information can be found by leveraging disk forensic tools. Exploring a disk image using Autopsy demonstrated some of the features that are available to responders. From here, extracting other data stores such as the Windows Registry and MFT were explored to provide responders with an idea of what data is available during an incident analysis.

Specific tools and techniques are largely dependent on the tool that’s utilized. What’s important to understand is that modern operating systems leave traces of their activity all over the disk, from file change evidence in the MFT to registry key settings when new user accounts are added. Incident responders should have expertise in understanding how modern operating systems store data and how to leverage commercial or freeware tools to find this data. Taken in concert with other pieces of evidence that are obtained from network sources and in memory, disk evidence may provide more clarity on an incident and aid in determining its root cause. One area of focus when it comes to system storage analysis is extracting and examining log files. Log files are critical data points that provide responders with a great deal of information.

The next chapter will carry on from the work that was done here and address how log files can be utilized in an incident investigation.

Questions

Answer the following questions to test your knowledge of this chapter:

1. What are some of the features that are available with commercial and open source forensic platforms?
   1. Hex viewer
   2. Email carving
   3. Metadata viewer
   4. All of the above
2. In what registry hive could an incident responder find USBs that have been connected to the system?
   1. SAM
   2. Security
   3. System
   4. User profile
3. Web history may provide data on a phishing URL that’s been accessed by the system.
   1. True
   2. False
4. Which of the following is not a Windows registry hive?
   1. System
   2. SAM
   3. Storage
   4. Software

Further reading

For more information about the topics covered in this chapter, refer to the following resources:

• Autopsy GitHub: https://github.com/sleuthkit/autopsy
• Eric Zimmerman Tools: https://ericzimmerman.github.io/#!index.md
• Eric Zimmerman Tools Cheat Sheet: https://www.sans.org/posters/eric-zimmerman-tools-cheat-sheet/
• Registry Analysis with FTK Registry Viewer: https://subscription.packtpub.com/book/networking_and_servers/9781784390495/6/ch06lvl1sec37/registry-analysis-with-ftkregistry-viewer
• Windows Registry Analysis 101: https://www.forensicfocus.com/articles/windows-registry-analysis-101/