1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

11

Analyzing System Storage

So far, the evidence that has been analyzed has focused on those ele-
ments 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 evi-
dence 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 re-
sponse 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 chap-

ter 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 utiliz-
ing 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 respon-
ders. 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 conduct-
ing an analysis.
Registry analysis: A favorite target of malware coders and other ex-
ploits, 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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 1/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 stan-
dard, but tools should conform to the rules of evidence. The use of a plat-
form that has not been tested or does not conform to the rules of evi-
dence 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 re-
sponse planning. For example, commercial disk forensics tools are excel-
lent at locating images and web artifacts. They are also excellent at carv-
ing out data from a suspect's drive. This is often because forensic soft-
ware 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 re-
construct a series of events before, during, and after an incident.

While most commercial and free forensic platforms have a variety of fea-
tures, 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 re-
sponders 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 ex-
amine 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 commit-
ted policy violations. Often, evidence of this type of conduct is con-

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 2/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

tained 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 exploita-
tion on a system. Incident responders can utilize these features to de-
termine whether there has been a policy violation.
Metadata: Key pieces of data about files such as date and time cre-
ated, file hashes, and the location of a suspect file on the disk are use-
ful when examining a system associated with an incident. For exam-
ple, the time an application is run, taken in conjunction with a piece of
malware, may be correlated with network activity, allowing the ana-
lyst to determine the actual executable run.

In terms of commercial options, the following three platforms are gener-

ally accepted as sound and are in use by commercial and government en-
tities 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 ana-
lyst. 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 connec-
tion 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 tai-
lored 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 en-
forcement 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 or-
ganizations, such as government agencies and large enterprises, the
trade-off of cost versus features may not be an issue. For smaller orga-
nizations, these platforms may be cost-prohibitive. An alternative, fea-
ture-rich forensic platform is X-Ways. This platform can perform a va-
riety 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 de-
vice, 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
https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 3/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 al-
lows 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 im-
age into multiple files. So long as the separate files are in the same direc-
tory, 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/.

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 4/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 5/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 en-
tered. 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 envi-
ronments where virtualization is utilized for systems. This feature al-
lows 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 loca-
tion. This folder contains several image files; select the file that ends in

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 6/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

E01. Loading this file will include all the subsequent image files lo-
cated 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:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 7/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 con-
duct 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 dis-
play details relating to the system and specific files. When Autopsy has

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 8/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 list-
ings 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 dis-
plays 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:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 9/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

Figure 11.15 – Hex view

This view is excellent if an analyst wants to inspect an application or an-

other 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 in-
stalled, 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:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 10/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 inci-
dent or examination under investigation. For example, a malware infec-
tion that originates from a compromised website may involve examining
the system for URLs that the user may have typed in or otherwise ac-
cessed via a browser. Furthermore, the actual file may be located by uti-
lizing 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 exe-
cutable 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 exam-

ine 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 circum-
stances, social engineering attacks may have an unsuspecting employee
navigate to a compromised website that subsequently downloads mali-
cious software. In either case, Autopsy provides us with the ability to ex-
amine several areas of web artifacts.

The first of these web artifacts is web history. In the event of a social en-
gineering 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,

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 11/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

where an insider has accessed an external cloud storage site, the web his-
tory 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 informa-
tion provided by Autopsy allows the analyst to evaluate other informa-
tion, 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 ex-
ploits or malware. This can include hacking tools and other scripts, of-
ten 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 down-
loaded 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:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 12/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

Figure 11.21 – Web download metadata

As the preceding screenshot shows, there are some more details concern-
ing the downloaded file. For example, the analyst can gather time infor-
mation, 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 com-
mercial solutions such as this is that their functionality is updated contin-
uously. Depending on the frequency of internet and web artifact search-
ing, 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 so-
cial 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 inappropri-
ate 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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 13/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

that can be further researched to see if they are associated with social en-
gineering or other malicious activity. Simply click on Keyword Hits and
then the Email Addresses tab in the left-hand pane. From there, the ana-
lyst 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, know-
ing 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:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 14/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 ana-

lysts have when examining solid-state drives (SSDs). Deleted files can of-
ten 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 excel-
lent 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:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 15/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 ac-
tivity, 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 in-
sider attempting to cover their tracks by deleting suspicious files.

Keyword searching

One key advantage that forensic applications have is the ability to per-
form keyword searches. This is especially advantageous as disk drives
have gotten larger and responders would have to parse through an over-
whelming quantity of data. Keywords are often derived from other ele-
ments 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 confi-
dential information, keywords in those documents, either secret or confi-
dential, 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 sub-

string match. For example, let’s say an analyst has been tasked with deter-
mining what evidence can be located concerning the ZeroTier One exe-
cutable, which had been located in the Web Downloads entries. The ana-
lyst 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 se-
lected, they would click the Search button. The left-hand pane will indi-
cate whether there were any hits on that text. In this case, the pricing de-
cision 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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 16/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 as-
sociated 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-en-
coded 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 ap-

plications or files were executed. Timestamps can sometimes be found in
other aspects of the investigation, such as when examining memory im-
ages. Also, identifying specific DLL files or executable files in the memory
image can be compared to the date and time they were accessed to corre-
late other activity that’s been observed on the system.

TIME NORMALIZATION

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 17/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 usu-
ally 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 synchroniza-
tion should be used. The best practice regarding time is to set all the sys-
tems to UTC. This is critical if an organization is geographically diverse.

Autopsy has functionality specifically for timeline analysis. Simply click-

ing 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.

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 18/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 direc-
tory 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:\Users\forensics\Documents\ZimmmermanTools>MFTECmd.exe -f "D:\Suspect_$MFT" --csv "D:" --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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 19/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 ques-
tion is Prefetch files. When an application or other executable is run, a
file is created and stored within the C:\Windows\Prefetch 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 attempt-
ing 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 di-
rectory 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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 20/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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

C:\Users\forensics\Documents\ZimmmermanTools>PECmd.exe -d D:\Suspect_Prefetch -q --csv D:\ --c

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 data-
base that stores the low-level system settings for the Windows operating
system. This includes settings for devices, security, services, and the stor-
age 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%\system32\config 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 sub-
keys (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 pass-
words 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.

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 21/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 modifica-
tions 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 ac-
count 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 set-
tings 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 reg-
istry 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

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 22/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 applica-

ble 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) man-
ager, which is part of the Windows operating system. The PnP receives a
notification that a USB has been connected and queries the device for in-
formation 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

ROOT\ControlSet001\Enum\USB\:

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 23/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

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 evi-
dentiary 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 us-
ing Autopsy demonstrated some of the features that are available to re-
sponders. 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.

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 24/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

Specific tools and techniques are largely dependent on the tool that’s uti-
lized. 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 free-
ware tools to find this data. Taken in concert with other pieces of evi-
dence that are obtained from network sources and in memory, disk evi-
dence 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 ad-
dress 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/

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 25/26
1/19/24, 11:21 AM Chapter 11: Analyzing System Storage | Digital Forensics and Incident Response - Third Edition

9781784390495/6/ch06lvl1sec37/registry-analysis-with-ftkregistry-
viewer
Windows Registry Analysis 101:
https://www.forensicfocus.com/articles/windows-registry-analysis-
101/

https://learning.oreilly.com/library/view/digital-forensics-and/9781803238678/B18571_11.xhtml#_idParaDest-190 26/26