Forensics with the Windows Registry

Consider the following scenario:

A user within a corporation connects a USB drive to their work station. The USB drive contains a Word document that is copied to the users desktop and opened with Microsoft Word. Word presents a security warning to the user - "Macros are disabled. Click to enable" - and unfortunately the user chooses to enable macros. The Word document's malicious payload is executed, but fortunately stopped by Anti-Virus. In a panic the user closes the Anti-Virus alert, closes and deletes the Word document, and removes the USB drive from the computer.


This scenario presents some interesting questions:

• Is it possible to identify exactly which USB devices have been connected to the computer?
• How could the malicious Word document's filename be identified if it has been removed from the system, or if the user simply does not recall which document was opened?
• If the Word document was successful in dropping an additional stage of malware onto the system, how could this potentially be identified? 

It is possible to answer each of these questions with information gathered from the Windows Registry. Before sifting through the plethora of data available in the Registry it is first necessary to understand what, exactly, the Windows Registry is (and why it's not as terrifying as it sounds).

The Windows Registry is the unsung hero of the Windows Operating System. It dutifully stores and processes low level machine information, sorted into a hierarchical database structure, for both the Operating System and applications that opt to use the Registry (not all applications do or need to). The Registry contains information, settings, options, and other useful data for applications and hardware. The sheer amount of information stored in the Registry is staggering. To make operations involving the Registry more efficient, Windows stores the data in a binary format. The binary data can be viewed directly with the 'Regedit' tool which displays the data in a human readable hexadecimal format.

The Windows Registry contains volatile and non-volatile data. The non-volatile data is stored on the systems HDD while the volatile data is created during system startup and user login. The volatile and non-volatile data are both stored in memory during normal Windows operations. This means that a 'complete' Registry only exists while the system is powered on and running normally. If volatile data is required for further analysis than it should be exported from the live system prior to it shutting down.

The Registry contains two basic elements - keys and values. Registry keys are container objects that store Registry values, similar to a folder storing documents. Registry values are non-container objects that contain binary data, similar to a document that contains information of some kind.
Understanding the key/value structure of the Windows Registry makes navigating the immense amount of data a much less daunting task. There are 5 'root keys' under which many sub-keys are stored. Each of the root keys exists to store a different category of data.

Navigation of the Windows Registry is primary achieved with the Registry Editor software. There is a 'find' function that helpfully searches based on user defined keywords and of course the option to manually explore each key, sub-key and value until the desired information has been located. While manually searching is a slower process it is also a great way to discover what information is located under which key. 

Root keys and sub-keys.
The root key 'HKEY_CURRENT_USER' is expanded to show its various sub-keys.

The HKEY_USERS key contains user information for all accounts on the machine, including system accounts. Each user account is identified by a unique numerical number that is loaded into the Registry when the user signs in. The information in question contains data ranging from desktop preferences and peripheral hardware settings, through to default applications and other user defined/specific settings.

The HKEY_CURRENT_USER key contains information regarding the currently logged in user. This key acts as a shortcut to the information already available in the HKEY_USERS key.

The HKEY_LOCAL_MACHINE key contains hardware and machine specific setup information. Specifically this key stores values for every installed driver on the system, as well as software settings that are common across all users.

The DriverDatabase key contains sub-keys that reference every driver installed on the machine.

The HKEY_CURRENT_CONFIG key is a shortcut to a path within the HKEY_LOCAL_MACHINE key that contains hardware information specific to the hardware profile that is currently active.

The HKEY_CLASSES_ROOT key contains file name extension associations and COM class registration information. The information stored under this key is actually a merged view of the information stored in two additional keys - the HKEY_CURRENT_USER\Software\Classes key and HKEY_LOCAL_MACHINE\SOFTWARE\Classes key. The information in these key/value pairs control which application is used to handle a particular file extension (i.e WordPad to open a .docx file).

.docx files associated with the WordPad.exe application.
This is a very small subset of the information available in HKEY_CLASSES_ROOT.

Collectively, this information is enough to perform a basic forensic analyse with. Perhaps unsurprisingly there is a wealth of additional information that could yet be discussed about the Registry, however for the purposes of this discussion it is out of scope. Our attention can now be turned to answering the questions surrounding the scenario explained earlier.

The first piece of information to locate from within the Registry is a list of USB devices that have been connected to the users machine. When a USB device is connected to a Windows system it leaves behind a unique fingerprint in the Windows Registry. The path for finding this fingerprint is HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR.

USB devices that have been connected to this system, regardless of the user.

In this instance it appears that two SanDisk devices, a SanDisk Cruzer and a SanDisk Ultra Fit, have been connected to the system along with a single SMI device. SMI is a reference to 'Silicon Motion Inc.', a company that manufactures USB flash drive controllers. Its reference in this list indicates that a generic USB device was connected to the system, and no specific branding or name information was recorded.

If the SanDisk USB drives have been verified as trusted company devices than there is a high probability the third device contained the malicious file. Beyond this point the device would need to be physically located and examined. Before examining the device further, it will be useful to know the name of the file we are looking for.

The Windows Registry maintains a list of recently opened documents for each user on the system. Navigating to the path HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs will display this information. The Registry keys in the list each reference a particular file extension type. The values within these keys are references to the most recently opened documents of that file extension type.

The values on the right each represent a recently opened .docx file.
The highest number in the 'name' column indicates the most recently opened file.

In this particular scenario we are aware that the document was saved in the .docx format. Viewing the name of the most recently opened .docx file is as simple as locating the highest numbered value in the 'name' field and inspecting the hexadecimal data contained within. In this instance the value named '18' will contain the required information.

Once the name of the file has been enumerated it will be possible to advise other users, update any relevant security controls, and audit the information for use in any necessary incident reports.

The file name is revealed to be "Resume And Cover Letter.docx".

Often times malware will create a backdoor for easy re-entry into the network by attackers at a later point in time. One such way for a backdoor to stay persistent is to write a registry entry in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run key. Values that are written to this key reference programs that are automatically started when the user signs in.

This is not the only key that may be used - the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run key controls which programs are loaded on startup for all configured users on the system, and, the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key enables services to start for each user of the system after they log in.

Checking these keys for anything suspicious is a productive step towards ensuring the integrity of a system and the network it is connected to. Depending on how much information is present in each key it may or may not be more practical to examine a before and after copy of the systems registry if possible. In this instance there is nothing untoward located in the Registry.

Expected 'Run' values for the current user.

In the grand scheme of Windows Registry forensics, this paper serves as a very manageable bite sized foray into the field. This basic knowledge acts as a solid foundation, however, and will enable much deeper dives into the topic without too much difficulty. The overall usefulness of forensics cannot be dismissed. The ability to answer 'who/what/when/where' after a cyber incident is invaluable information for defending the network and its users against future incursions.