introduction to Windows registry forensics
is an essential field of cyber security that involves gathering evidence of activities performed on computers. It is a part of the wider Digital Forensics field, which deals with forensic analysis of all types of digital devices, including recovering, examining, and analyzing data found in digital devices.
are essential pieces of information that provide evidence of human activity. For example, during the investigation of a crime scene, fingerprints, a broken button on a shirt or coat, and the tools used to perform the crime are all considered forensic artifacts. All of these artifacts are combined to recreate the story of how the crime was committed.
💻Task 2 — — — Windows Registry and Forensics
The Windows Registry is a database collection containing the system’s configuration data. This configuration data can be about the hardware, the software, or the user’s information. It also includes data about the recently used files, programs used or devices connected to the system. As you can understand, this data is beneficial from a forensics standpoint.
Structure of the Registry:
The registry on any Windows system contains the following five root keys:
💻Task 3 — Accessing registry hives offline
However, if you only have access to a disk image, you must know where the registry hives are located on the disk. The majority of these hives are located in the
C:\Windows\System32\Config directory and are:
- DEFAULT (mounted on
- SAM (mounted on
- SECURITY (mounted on
- SOFTWARE (mounted on
- SYSTEM (mounted on
Hives containing user information:
Apart from these hives, two other hives containing user information can be found in the User profile directory. For Windows 7 and above, a user’s profile directory is located in
C:\Users\<username>\ where the hives are:
- NTUSER.DAT (mounted on HKEY_CURRENT_USER when a user logs in)
- USRCLASS.DAT (mounted on HKEY_CURRENT_USER\Software\CLASSES)
The USRCLASS.DAT hive is located in the directory
The NTUSER.DAT hive is located in the directory
The Amcache Hive:
Apart from these files, there is another very important hive called the AmCache hive. This hive is located in
C:\Windows\AppCompat\Programs\Amcache.hve. Windows creates this hive to save information on programs that were recently run on the system.
Transaction Logs and Backups:
Windows often uses transaction logs when writing data to registry hives. This means that the transaction logs can often have the latest changes in the registry that haven’t made their way to the registry hives themselves. The transaction log for each hive is stored as a .LOG file in the same directory as the hive itself. It has the same name as the registry hive, but the extension is .LOG. For example, the transaction log for the SAM hive will be located in
C:\Windows\System32\Config in the filename SAM.LOG. Sometimes there can be multiple transaction logs as well. In that case, they will have .LOG1, .LOG2 etc., as their extension. It is prudent to look at the transaction logs as well when performing registry forensics.
Registry backups are the opposite of Transaction logs. These are the backups of the registry hives located in the
C:\Windows\System32\Config directory. These hives are copied to the
C:\Windows\System32\Config\RegBack directory every ten days. It might be an excellent place to look if you suspect that some registry keys might have been deleted/modified recently.
💻Task 4 — — — Data acquisition
simply, we can define it as taking a full, partition or file image of the actual disk; to perform our forensic on it.
When performing forensics, we will either encounter a live system or an image taken of the system. For the sake of accuracy, it is recommended practice to image the system or make a copy of the required data and perform forensics on it. This process is called data acquisition. Below we discuss different ways to acquire registry data from a live system or a disk image:
Though we can view the registry through the registry editor, the forensically correct method is to acquire a copy of this data and perform analysis on that. However, when we go to copy the registry hives from
%WINDIR%\System32\Config, we cannot because it is a restricted file. So, what to do now?
For acquiring these files, we can use one of the following tools:
[KAPE, AUTO SPY,FTK imager]
💻Task 5 — — — Exploring Windows Registry
Once we have extracted the registry hives, we need a tool to view these files as we would in the registry editor. Since the registry editor only works with live systems and can’t load exported hives, we can use the following tools:
As we can see in the screenshot below, accessdata’s Registry Viewer has a similar user interface to the Windows Registry Editor. There are a couple of limitations, though. It only loads one hive at a time, and it can’t take the transaction logs into account.
Zimmerman’s Registry Explorer:
Eric Zimmerman has developed a handful of tools that are very useful for performing Digital Forensics and Incident Response. One of them is the Registry Explorer. It looks like the below screenshot. It can load multiple hives simultaneously and add data from transaction logs into the hive to make a ‘cleaner’ hive with more up-to-date data. It also has a handy ‘Bookmarks’ option containing forensically important registry keys often sought by forensics investigators. Investigators can go straight to the interesting registry keys and values with the bookmarks menu item. We will explore these in more detail in the upcoming tasks.
RegRipper is a utility that takes a registry hive as input and outputs a report that extracts data from some of the forensically important keys and values in that hive. The output report is in a text file and shows all the results in sequential order.
RegRipper is available in both a CLI and GUI form which is shown in the screenshot below.
One shortcoming of RegRipper is that it does not take the transaction logs into account. We must use Registry Explorer to merge transaction logs with the respective registry hives before sending the output to RegRipper for a more accurate result.
💻Task 6 — —System Information and System Accounts
If we only have triage data to perform forensics, we can determine the OS version from which this data was pulled through the registry. To find the OS version, we can use the following registry key:
<>Current control set:
The hives containing the machine’s configuration data used for controlling system startup are called Control Sets. Commonly, we will see two Control Sets, ControlSet001 and ControlSet002, in the SYSTEM hive on a machine. In most cases, ControlSet001 will point to the Control Set that the machine booted with, and ControlSet002 will be the
last known good configuration. Their locations will be:
Windows creates a volatile Control Set when the machine is live, called the CurrentControlSet (
HKLM\SYSTEM\CurrentControlSet). For getting the most accurate system information, this is the hive that we will refer to. We can find out which Control Set is being used as the CurrentControlSet by looking at the following registry value:
last known good configuration can be found using the following registry value:
It is vital to establish this information before moving forward with the analysis. As we will see, many forensic artifacts we collect will be collected from the Control Sets.
It is crucial to establish the Computer Name while performing forensic analysis to ensure that we are working on the machine we are supposed to work on. We can find the Computer Name from the following location:
Time Zone Information:
For accuracy, it is important to establish what time zone the computer is located in. This will help us understand the chronology of the events as they happened. For finding the Time Zone Information, we can look at the following location:
Time Zone Information is important because some data in the computer will have their timestamps in UTC/GMT and others in the local time zone. Knowledge of the local time zone helps in establishing a timeline when merging data from all the sources.
Network Interfaces and Past Networks:
The following registry key will give a list of network interfaces on the machine we are investigating:
Each Interface is represented with a unique identifier (GUID) subkey, which contains values relating to the interface’s TCP/IP configuration. This key will provide us with information like IP addresses, DHCP IP address and Subnet Mask, DNS Servers, and more. This information is significant because it helps you make sure that you are performing forensics on the machine that you are supposed to perform it on.
The past networks a given machine was connected to can be found in the following locations:
These registry keys contain past networks as well as the last time they were connected. The last write time of the registry key points to the last time these networks were connected.
Autostart Programs (Autoruns):
The following registry keys include information about programs or commands that run when a user logs on.
The following registry key contains information about services:
Notice the Value of the Start key in the screenshot below.
In this registry key, if the
start key is set to 0x02, this means that this service will start at boot.
SAM hive and user information:
The SAM hive contains user account information, login information, and group information. This information is mainly located in the following location:
The information contained here includes the relative identifier (RID) of the user, number of times the user logged in, last login time, last failed login, last password change, password expiry, password policy and password hint, and any groups that the user is a part of.
💻Task 7 — — — Usage or knowledge of files/folders
Windows maintains a list of recently opened files for each user. As we might have seen when using Windows Explorer, it shows us a list of recently used files. This information is stored in the NTUSER hive and can be found on the following location:
Registry Explorer allows us to sort data contained in registry keys quickly. For example, the Recent documents tab arranges the Most Recently Used (MRU) file at the top of the list. Registry Explorer also arranges them so that the Most Recently Used (MRU) file is shown at the top of the list and the older ones later.
Another interesting piece of information in this registry key is that there are different keys with file extensions, such as
.docx etc. These keys provide us with information about the last used files of a specific file extension. So if we are looking specifically for the last used PDF files, we can look at the following registry key:
Registry Explorer also lists the Last Opened time of the files. Answer Question # 1 by looking at the above screenshot.
Office Recent Files:
Similar to the Recent Docs maintained by Windows Explorer, Microsoft Office also maintains a list of recently opened documents. This list is also located in the NTUSER hive. It can be found in the following location:
The version number for each Microsoft Office release is different. An example registry key will look like this:
Here, the 15.0 refers to Office 2013. A list of different Office releases and their version numbers can be found on this link.
Starting from Office 365, Microsoft now ties the location to the user’s live ID. In such a scenario, the recent files can be found at the following location.
In such a scenario, the recent files can be found at the following location. This location also saves the complete path of the most recently used files.
When any user opens a folder, it opens in a specific layout. Users can change this layout according to their preferences. These layouts can be different for different folders. This information about the Windows ‘shell’ is stored and can identify the Most Recently Used files and folders. Since this setting is different for each user, it is located in the user hives. We can find this information on the following locations:
Registry Explorer doesn’t give us much information about ShellBags. However, another tool from Eric Zimmerman’s tools called the ShellBag Explorer shows us the information in an easy-to-use format. We just have to point to the hive file we have extracted, and it parses the data and shows us the results. An example is shown below. Take a look and answer Question # 2.
Open/Save and LastVisited Dialog MRUs:
When we open or save a file, a dialog box appears asking us where to save or open that file from. It might be noticed that once we open/save a file at a specific location, Windows remembers that location. This implies that we can find out recently used files if we get our hands on this information. We can do so by examining the following registry keys
This is how Registry Explorer shows this registry key. Take a look to answer Question # 3 and 4.
Windows Explorer Address/Search Bars:
Another way to identify a user’s recent activity is by looking at the paths typed in the Windows Explorer address bar or searches performed using the following registry keys, respectively.
Here is how the TypedPaths key looks like in Registry Explorer:
💻Task 8 — — — Evidence of Execution
Windows keeps track of applications launched by the user using Windows Explorer for statistical purposes in the User Assist registry keys. These keys contain information about the programs launched, the time of their launch, and the number of times they were executed. However, programs that were run using the command line can’t be found in the User Assist keys. The User Assist key is present in the NTUSER hive, mapped to each user’s GUID. We can find it at the following location:
ShimCache is a mechanism used to keep track of application compatibility with the OS and tracks all applications launched on the machine. Its main purpose in Windows is to ensure backward compatibility of applications. It is also called Application Compatibility Cache (AppCompatCache). It is located in the following location in the SYSTEM hive:
ShimCache stores the file name, file size, and last modified time of the executables.
Our goto tool, the Registry Explorer, doesn’t parse ShimCache data in a human-readable format, so we go to another tool called AppCompatCache Parser, also a part of Eric Zimmerman’s tools. It takes the SYSTEM hive as input, parses the data, and outputs a CSV file that looks like this:
We can use the following command to run the AppCompatCache Parser Utility:
AppCompatCacheParser.exe --csv <path to save output> -f <path to SYSTEM hive for data parsing> -c <control set to parse>
The output can be viewed using EZviewer, another one of Eric Zimmerman’s tools.
The AmCache hive is an artifact related to ShimCache. This performs a similar function to ShimCache, and stores additional data related to program executions. This data includes execution path, installation, execution and deletion times, and SHA1 hashes of the executed programs. This hive is located in the file system at:
Information about the last executed programs can be found at the following location in the hive:
This is how Registry Explorer parses the AmCache hive:
Background Activity Monitor or BAM keeps a tab on the activity of background applications. Similar Desktop Activity Moderator or DAM is a part of Microsoft Windows that optimizes the power consumption of the device. Both of these are a part of the Modern Standby system in Microsoft Windows.
In the Windows registry, the following locations contain information related to BAM and DAM. This location contains information about last run programs, their full paths, and last execution time.
Below you can see how Registry Explorer parses data from BAM:
💻Task 9 — — — External Devices/USB device forensics
When performing forensics on a machine, often the need arises to identify if any USB or removable drives were attached to the machine. If so, any information related to those devices is important for a forensic investigator. In this task, we will go through the different ways to find information on connected devices and the drives on a system using the registry.
The following locations keep track of USB keys plugged into a system. These locations store the vendor id, product id, and version of the USB device plugged in and can be used to identify unique devices. These locations also store the time the devices were plugged into the system.
Similarly, the following registry key tracks the first time the device was connected, the last time it was connected and the last time the device was removed from the system.
In this key, the #### sign can be replaced by the following digits to get the required information:
Although we can check this value manually, as we have seen above, Registry Explorer already parses this data and shows us if we select the USBSTOR key.
USB device Volume Name:
The device name of the connected drive can be found at the following location:
SOFTWARE\Microsoft\Windows Portable Devices\Devices
We can compare the GUID we see here in this registry key and compare it with the Disk ID we see on keys mentioned in device identification to correlate the names with unique devices.
Combining all of this information, we can create a fair picture of any USB devices that were connected to the machine we’re investigating.
💻👍Task 10 — — — Hands-on Challenge
Once we log in, we will see two folders on the Desktop named
triage folder contains a triage collection collected through KAPE, which has the same directory structure as the parent. This is where our artifacts will be located. The
EZtools folder contains Eric Zimmerman's tools, which we will be using to perform our analysis. You will also find RegistryExplorer, EZViewer, and AppCompatCacheParser.exe in the same folder.
Now that we know where the required toolset is, we can start our investigation. We will have to use our knowledge to identify where the different files for the relevant registry hives are located and load them into the tools of our choice. Let’s answer the questions below using our knowledge of registry forensics.
One of the Desktops in the research lab at Organization X is suspected to have been accessed by someone unauthorized. Although they generally have only one user account per Desktop, there were multiple user accounts observed on this system. It is also suspected that the system was connected to some network drive, and a USB device was connected to the system. The triage data from the system was collected and placed on the attached VM. Can you help Organization X with finding answers to the below questions?
When loading registry hives in RegistryExplorer, it will caution us that the hives are dirty. This is nothing to be afraid of. We just need to remember the little lesson about transaction logs and point RegistryExplorer to the .LOG1 and .LOG2 files with the same filename as the registry hive. It will automatically integrate the transaction logs and create a ‘clean’ hive. Once we tell RegistryExplorer where to save the clean hive, we can use that for our analysis and we won’t need to load the dirty hives anymore. RegistryExplorer will guide you through this process.
Let’s start ;)
1-How many user-created accounts are present on the system?
first, we will check SAM hive; because it’s related to everything related to users, like user names, accounts, etc….
Accounts with RIDs starting with 10xx are user-created accounts.
2-What is the username of the account that has never been logged in?
let’s check the account that does not have a last logged-in time
3-What’s the password hint for the user THM-4n6?
4-When was the file ‘Changelog.txt’ accessed?
lets Check-in evidence of file/folder opening by going to the NTUSER hive …
we can get their
NTUSER.DAT located in
C:\Users\THM-4n6\Desktop\triage\C\Users\THM-4n6 and load it to RegistryExplorer.
The information we are interested in can be found in
5-What is the complete path from where the python 3.8.2 installer was run?
The User Assist key is present in the NTUSER hive, mapped to each user’s GUID. We can find it at the
6-When was the USB device with the friendly name ‘USB’ last connected?
we can get the information on
SYSTEM\CurrentControlSet\Enum\USBSTOR Comparing the GUID we saw earlier with the Disk ID, we can ascertain that
USB is the one in the first row alongside the last connected timestamp.
that’s all 😊
I hope i simplified this room for you😊👍💻