Threat Hunting With The Windows Registry

The Windows registry is a central repository or, more specifically, a vast hierarchical database that stores Windows system configuration settings for hardware, software applications, and the operating system in addition to the user’s preferences and the computer’s and applications’ usage history.  While creating a convenient central location for this data, it also creates the potential for a single point of failure that can bring the system to a halt.  Almost every action conducted by a Windows user is stored in its registry in one way or another; this makes the Windows registry a rich source of evidence that can be extremely valuable for any digital forensic investigation.

The Architecture of The Windows Registry

Registry data is structured in a tree format, where each node in the tree is called a key. A key can contain other keys (subkeys) in addition to data values as shown in the figure below.

The Windows registry contains five root keys. Looking at the figure above, you will see them listed in the key pane, each with the prefix HKEY.  Of the five root keys in the registry, only two root keys HKEY_LOCAL_MACHINE and HKEY_USERS have physical files or hives. These two keys are called master keys. The remaining three keys are derived keys, meaning they are linked to keys within the two master keys. The figure below describes the relationship between the root keys.

 

 

 

These root keys, along with a brief description of their purpose, are listed in the table below.

 

Root Key	Description
HKEY_CLASSES_ROOT	Used to associate file types with programs that open them and also to register classes for Component Object Model (COM) objects. It is the largest of the root keys in terms of the registry space it occupies. This key is derived from two keys, HKLM\Software\Classes and HKCU\Software\Classes. This merger effectively blends default settings with per-user settings.
HKEY_CURRENT_USER	Used to configure the environment for the console user. It is a per-user setting (specific only to this user) and is derived from a link to HKU\SID, where the SID is the user’s security identifier
HKEY_CURRENT_CONFIG	Used to establish the current hardware configuration profile. This key is derived from a link to HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current. Current is derived from a link to HKLM\SYSTEM\ CurrentControlSet\Hardware Profiles\####, where #### is a number that increments starting at 0000. HKLM\SYSTEM\CurrentControlSet, in turn, is a link to HKLM\SYSTEM\ControlSet###, where ### is a number that increments starting at 000. The value located in HKLM\SYSTEM\Select\Current determines which control set is current and, therefore, which control set is to be used to create this key via a link.
HKEY_LOCAL_MACHINE	Used to establish the per-computer settings. Settings found in this key apply to the machine and all of its users, covering all facets of the computer’s function. This key is a master key and is not, therefore, derived from any link as are the previous three keys. During system startup, the local machine settings are loaded before the user-specific settings.
HKEY_USERS	Used to contain the user environment settings for the console user as well as other users who have logged on to the system. There will be at least three subkeys, which are .DEFAULT, SID, and SID_Classes, where the SID is that of the console user. You may also find SIDs S-1–5–18, S-1–5–19, and S-1–5–20, which are for the LocalSystem, LocalService, and NetworkService accounts, respectively. Any other SIDs found here will belong to other users who have logged on to the machine. This key is a master key and is not, therefore, derived from any link as are the first three keys.

Root keys are divided into two types with regard to their data persistence: volatile and nonvolatile. HKEY_LOCAL_MACHINE and HKEY_USERS keys are nonvolatile and are stored on the hard drive, while the remaining keys are volatile and should be captured while the system is running in order to acquire useful information from them. 

The HKEY_LOCAL_MACHINE Root Key

 

 

At a physical level, each of the logical master keys has its source data stored in files called hives. For each of the two master keys (HKLM and HKU), there are subkeys named for each of the hive files. The table below lists the HKEY_LOCAL_MACHINE (abbreviated HKLM) hive keys and the associated hive or source files from which they originate. These hive files are located in the folder %SYSTEMROOT%\System32\config.

Hive Key	Hive file
HKEY_LOCAL_MACHINE\SAM	%SYSTEMROOT%\System32\config\SAM
HKEY_LOCAL_MACHINE\SECURITY	%SYSTEMROOT%\System32\config\SECURITY
HKEY_LOCAL_MACHINE\SOFTWARE	%SYSTEMROOT%\System32\config\SOFTWARE
HKEY_LOCAL_MACHINE\SYSTEM	%SYSTEMROOT%\System32\config\SYSTEM
HKEY_LOCAL_MACHINE\COMPONENTS	\%SYSTEMROOT%\System32\config\COMPONENTS
HKEY_LOCAL_MACHINE\BCD00000000	%SYSTEMROOT%\Boot\BCD

Performing a postmortem analysis on the system registry requires extracting the hives (in bold fonts) from the filesystem.

 

You will also see one more subkey named HARDWARE. Interestingly, HARDWARE is a dynamic key with no source hive file stored on disk. It is created as a dynamic key in RAM when Windows boots, and it disappears when the computer is shut down. This dynamic hive contains information about the hardware such as BIOS versions and manufacturer. This type of information is not normally vital for our purposes; however, the fact that this data disappears when power is removed from the computer should reinforce the need for capturing volatile data when the system is live.

Registry Redirection and Reflection

Starting with Windows XP (the 64-bit version), a couple of new features were enabled that allowed for the isolation of 32- and 64-bit applications. These features are called registry redirection and reflection, and it is important to understand their impact on the forensic analysis of the registry so that, as examiners, investigators, and incident responders, we leave no stone unturned.

The purpose of registry redirection and reflection surrounds the issue of needing to isolate legacy 32-bit applications that are running in a 64-bit world. In essence, redirection gives us the ability for 32-bit and 64-bit applications to coexist on the same computer, even if they call, write, edit, or create registry keys that have the same name. As a result of the redirection, 32-bit applications that write entries into the system-wide registry key HKLM\SOFTWARE are redirected to the HKLM\SOFTWARE\WOW6432Node key.  WOW stands for Windows on Windows, and 6432 references that the data under the key is a node that addresses the 64-bit and 32-bit application compatibility. This key maps back to HKLM\SOFTWARE and provides the application with the illusion that it is running on a 32-bit system. Some of the subkeys under HKLM\SOFTWARE are shared with the 64-bit system instead of being redirected to the WOW6432Node key. The keys that are affected by the redirection are listed here.

In some cases, while the registry entries of 32-bit and 64-bit applications must be isolated, it is important that some values between the two logical registry views maintain the same information. This is where reflection comes to our aid. Reflection is essentially the synchronization of any changes that occur in the 64-bit registry key to the redirected 32-bit registry key and vice versa. In this way, we can be assured that both 32- and 64-bit applications are running off the same information in the registry. Registry reflection has been phased out in Windows 7 and newer versions in favor of shared keys, but it was functional in Windows 2000, XP, 2003, Vista, and 2008.

Registry Virtualization

This feature was introduced with Windows Vista.  Registry virtualization is a User Account Control (UAC)–related process. When a non-administrative user, or an interactive application running in the security context of a non-administrative user, attempts to make a system-wide registry change to certain keys in the HKLM\SOFTWARE registry key, that change is instead placed into a user-based virtual location. This user-based recording helps protect the system by restricting nonadministrative users from making system-wide changes that affect all users. If a registry key is opened up for writing, but the user account doesn’t have the permissions to write to that key, the changes that were destined for HKLM\SOFTWARE are made in HKU\<SID>_Classes\VirtualStore\ Machine\Software. This key then stores its data in the %SystemRoot%\Users\%UserName%\AppData\Local\Microsoft\Windows\UsrClass.dat hive file. This virtualization allows a nonadministrative user to be able to run applications that require the registry change capability without having administrative permissions.

 

Registry virtualization does not impact every application that could possibly be loaded on a Windows operating system. It is limited to 32-bit interactive applications and to entries in the HKLM\SOFTWARE key. In addition, it’s limited to keys that an administrator has permissions to write to. If an application wants to write to a key that even an administrator doesn’t have permissions to change, the write attempt will fail on both the master key and the virtualized key. This also does not work for keys in the following: 

• HKLM\Software\Classes
• HKLM\Software\Microsoft\Windows
•  HKLM\Software\Microsoft\WindowsNT
  

The impact of registry virtualization is that we now have a bit more work to do when looking for user-specific data in the registry. The upside is that each non-administrative user now has certain keys that apply only to that user, which can show which user account made the change. Starting with Windows Vista, we have another user-based registry file (UsrClass.dat) that we have to consult in addition to NTUSER.DAT. From a registry redirection and reflection standpoint, we now know that we also need to examine the WOW64 subkeys when we’re looking for application information stored in the registry. We can’t just assume that everything we need to find is going to be where it was in previous Windows versions. If we only look in the NTUSER.DAT file and under the HKLM\SOFTWARE key for information related to applications installed on the target computer, we may miss the golden nugget that would lead to the intruder, her toolbox, or a specific process that was used during the intrusion.

The HKEY_USERS Root Key

The master key HKU has its share of subkeys and source hive files as well. In fact, each subkey under HKU is a hive key with a corresponding hive file. The hive files for HKU are found in several locations. The table below shows the various hive keys in HKU and their source hive files. When SID is referenced, it is the SID of the console user or other past logged-on user. When UserName is referenced, it is the username corresponding to the SID.

Hive Key	Hive File
HKU\.DEFAULT	%SYSTEMROOT%\System32\config\default
HKU\S-1–5–19	Documents and Settings\LocalService NTUSER.DAT (Pre-Vista Operating systems) %SYSTEMROOT%\Windows\ServiceProfiles\LocalService\NTUSER.DAT (Vista and beyond)
HKU\S-1–5–19_Classes	Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat (Pre-Vista Operating systems only; this key doesn’t exist in Vista and beyond.)
HKU\S-1–5–20	Documents and Settings\NetworkService NTUSER.DAT %SYSTEMROOT%\ Windows\ServiceProfiles\NetworkService\NTUSER.DAT (Post-Vista Operating systems)
HKU\S-1–5–20_Classes	Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat (Pre-Vista OSs only; this key doesn’t exist in Vista and beyond.)
HKU\SID	Documents and Settings\UserName\NTUSER.DAT (Pre-Vista OSes) Users\UserName\NTUSER.DAT (Vista and beyond)
HKU\SID_Classes	Documents and Settings\UserName\Local Settings\Application Data\ Microsoft\Windows\UsrClass.dat (Pre-Vista OSes) Users\UserName\ AppData\Local\Microsoft\Windows\UsrClass.dat (Vista and beyond)

When the system loads these hives into the registry, there is one key that lists, or maps, the loaded hive files (complete with paths) with their corresponding registry hive keys. This key may be found at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist. Notice that the HARDWARE key lacks a file path. Again, this is because this subkey is dynamically generated at boot time. From an evidentiary point of view, this subkey is unremarkable, but it is an excellent place to visit for understanding the relationships between hive files and hive keys that are loaded on the system. You should expect to find this subkey only in the live registry. When the system is shut down, none of the hives are loaded, and this subkey therefore will not appear in a hive file viewed in an offline forensic environment.

Registry Key Values and Attributes

The registry keys are displayed in the left, or key, pane of the Registry Editor. It is from this pane that you may navigate the hierarchy of the various registry keys. The right, or value, pane is the pane by which you view or access the registry values. A value has three components: its name, its data type, and its data.

All values have names because there cannot be a null name. A value’s name is analogous to a file’s name. A value name can be up to 512 ANSI characters in length (256 Unicode characters), except for the special characters question mark (?), backslash (\), and asterisk (*). Just as no folder can contain two files with exactly the same name, no key can contain two values with exactly the same name.

Registry data can be stored in a variety of encodings—in fact, the registry stores a “value type” field along with each value that specifies the structure of its accompanying data. These types include everything from simple numbers and strings, to lists and even binary-encoded data. As a result, whereas some registry values and data are human readable, others require the use of specialized decoding tools. The table shows each of the data types, their corresponding number, and a brief description of what the data type means.

 

Data Type	Number	Description
REG_NONE	0	Data type is not defined.
REG_SZ	1	Fixed-length text string expressed in userfriendly format, which is often used to describe components.
REG_EXPAND_SZ	2	Variable- or expandable-length data string.
REG_BINARY	3	Binary data that is displayed in the editor as hex.
REG_DWORD	4	32-bit double word values and the most common data type found in the registry.
REG_DWORD_LITTLE_ENDIAN	4	32-bit double word values with bytes in reverse order. Since Intel already stores data in this format, this term is synonymous with REG_DWORD and they have the same numeric value.
REG_DWORD_BIG_ENDIAN	5	32-bit double word value with bytes in normal order with the highest bit appearing first.
REG_LINK	6	An internal-use-only data type for a Unicode symbolic link.
REG_MULTI_SZ	7	Multiple-string field in which each string is separated by a null (00), and two nulls (00 00) mark the end of the list of strings.
REG_RESOURCE_LIST	8	Listing of resource lists for devices or device drivers.
REG_FULL_RESOURCE_DESCRIPTOR	9	Hardware resource descriptions.
REG_RESOURCE_REQUIREMENTS_LIST	10	Resource requirements
REG_QWORD	11	64-bit number.
REG_QWORD_LITTLE_ENDIAN		64-bit number in little endian format (low byte first).

Viewing The Registry With Forensic Tools

The live registry and the registry as seen in offline forensic environments have noticeable differences.  When you view the registry with an offline forensic tool, you are looking only at the hive files, and that view differs from a live registry in many ways. One such example is the HARDWARE key; you will not see the HARDWARE key that exists in the live registry under HKLM. This key is a dynamic key, created at boot, and exists only in RAM while the system is loaded and running. There is no HARDWARE hive file for this dynamic key. 

I have explained earlier that certain keys exist virtually as links to keys on the master keys. You should not therefore expect to see the virtually created keys, but you can certainly view their data by going to the key to which they are linked. For example, do not expect to see HKEY_ CURRENT_USER in the offline forensic tool registry view. However, we know that this key is derived from the SID key under HKEY_USERS and that the SID key is actually a hive key whose source file is NTUSER.DAT, which is located in the root of the SID user’s folder (root user folder).

When dealing with “dead” hive files, you won’t be able to find any of the virtual key paths, such as HKEY_CURENT_CONFIG or HKEY_CURRENT_USER, or even some subkeys, such as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet, that only exist on a live system. 

 

Windows maintains five main registry hives in the path %SYSTEMROOT%\system32\config: SYSTEM, SECURITY, SOFTWARE, SAM, and DEFAULT. Note that these are the actual hive file names—they do not have an extension. Two user hives, NTUSER.DAT and USRCLASS.DAT, are stored in different locations, depending on the version of Windows, as listed next.

Windows XP and Lower Versions

• \Documents and Settings\<user>\NTUSER.DAT 
• \Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Windows\USRCLASS.DAT
  

Windows Vista and Higher Versions

• \Users\<user>\NTUSER.DAT
• \Users\<user>\AppData\Local\Microsoft\Windows\USRCLASS.DAT 
  

Note that you will need to use a forensic imaging or acquisition tool with raw disk access (for example, AccessData FTK Imager) to export these registry hive files. You cannot simply copy them with Windows Explorer.

Remember that Windows only maintains profile data for users who have interactively logged on to a system. If a user has only established a network logon (such as when mounting a share), the system will not contain a profile directory or registry hive for that specific account. As a side note, that means the absence of a user profile directory does not indicate that user has never authenticated to the system.

Windows Registry Forensic Examination

Most computer forensics suites have the ability to investigate the Windows registry from the acquired forensic image. There are also many programs specializing in analyzing Windows registry files alone. In this section, we will assume that we have booted up using a suspect forensic image to perform various forensic analyses on it.

Installed Software

When programs are installed on a computer, a registry entry is usually associated with that software installation. Oddly enough, even when software is removed or uninstalled, many registry entries persist, making the registry, once again, a rich source for evidentiary data. Software installation entries are varied in both name and location. If you don’t know exactly what you are looking for, it is best to look in many different locations known to contain information about software on a system.

If determining which software is installed on a computer is important to your investigation, and it usually is with a network-intrusion case, you will need to look in many locations to make that assessment as follows.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall - If the suspect’s machine has more than one user, each user will have his/her own set of software installed on his/her own key under the (HKEY_CURRENT_USER) hive. 
HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\<Product_Code>\SourceList\Net

 

In addition to locating installed software, it is usually important to have date and time information about that software when possible. Often intruders will alter the Modified, Accessed, Created (MAC) times on their software files, making them appear as though they have been on the system for months or years. As you will later discover, the registry stores last-written time stamps for various keys. Intruders often overlook these time stamps. If you can determine when a particular malware software registry key was last written, particularly an Uninstall key, you can likely use that information to determine when the intruder was active on the target system. With that information, you can examine various logs pertaining to network activity and begin the process of tracking the intruder back to the source.

Last Logon

When it’s important to determine who last logged on to a system, you should look in a couple different locations, because Microsoft seems to change its mind as to where the most appropriate location is for this information.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

The value DefaultUserName, when present, holds the username of the last user to log on to Windows so that it can be displayed as the default username for the next logon session. It may also be important to know whether the last-logged-on user was doing so using a local account, an account from the local site’s domain, or even an account from some other trusted domain. This same key contains the value DefaultDomainName, which describes the local or domain security authority of the last account used to log on. 

There is an alternate location to look for the last user logged onto Windows that is a timesaving alternative to manually traversing the NTUSER.DAT files for each user.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData

This key stores data on multiple sessions under the value LoggedOnSAMUser and LoggedOnUsername and tracks not only logons that occur at the keyboard but also ones that occur over Remote Desktop Connection (RDC). 

Automatic Startup Locations

Windows has a feature that allows programs to launch automatically as it boots; this feature is necessary for some applications like antivirus software that must run first to stop any malicious software before Windows gets booted completely. Malware programs usually tend to preserve their existence in the system in case the system was rebooted or different users log on to the system. The following shows two important autorun keys that run when the system boots:

 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services - This contains a list of services that run at system startup. If the value Start is 2, startup is automatic. If the value Start is 3, startup is manual and starts on demand for the service. If the value Start is 4, the service is disabled. The number of services listed in this key is quite large.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad - Value Load, if present, runs using explorer.exe after it starts.

 

These locations can host malware that targets the machine itself, such as rootkit, botnet, or backdoor. Other malware executables target some users on the system and run when the specific user or any user logs on to the system. They can be found in the following locations:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellServiceObjects 
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows\CurrentVersion\Run - All values in this key execute at system startup
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce - All values in this key execute at system startup and then are deleted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx - Per Microsoft KB232509, the syntax to run a program from here is RunMyApp = ||notepad.exe.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run - If Explorer and run are present, the values under run are executed after Explorer starts.
HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon - The value Shell will be executed when any user logs on. This value is normally set to explorer.exe, but it could be changed to a different Explorer in a different path!
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\ SharedtaskScheduler 
HKEY_LOCAL_MACHINE\Software\Microsoft\active Setup\Installed Components - Each subkey (GUID name) represents an installed component. All subkeys are monitored, and the StubPath value in subkeys, when present, is a way of running code.
HKEY_LOCAL_MACHINE\Wow6432node\Microsoft\active Setup\Installed Components - Same as above
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\ Winlogon\Userinit - Value Userinit runs when any user logs on—it can be appended to have additional programs start here.
HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Control\Session Manager - The value BootExecute contains files that are native applications executed before Windows runs.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows nt\CurrentVersion\Drivers32
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce - All values in this subkey run when this specific user logs on, and then the values are deleted
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run - All values in this subkey run when this specific user logs on, because this setting is user specific
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load - For this specific user, the string specified in the value load runs when this user logs on
HKEY_CURRENT_USER\Software\Wow6432node\Microsoft\Windows\CurrentVersion\Run - For this specific user, the string specified in the value run runs when this user logs on. 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnceEx

 

This is by no means an exhaustive list but a list of the more common areas in which intruders often start code. In fact, it is limited to the CURRENT USER and only the SYSTEM and SOFTWARE branches of the LOCAL MACHINE keys. To try to create a list and say that is complete is to invite trouble, because new ways are continually being found to start code in Windows. 

Timezone Information

The TimeZoneInformation key is a critical reference for supporting a consistent timeline of evidence.  There are certain values contained within this key that can help determine time zone and daylight savings time (DST) information, which may be necessary in converting UTC timestamps to local time.  DST does not affect UTC time, but it can play a significant roll in determining local time.  The full path to the key is given below:

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation 

The values of interest in this key includes:

• ActiveTimeBias
• Bias
• DaylightBias
• StandardBias
  

If you are using forensic software, and you want to see your case in the proper time zone reference, you must set the proper time zone offset. Also, if you are examining registry hive keys using regedit, and those hive keys were created in a different time zone, you will need to adjust your local time zone to match if you want to view the time accurately for that time zone. The formulas of interest include:

• UTC = Local Time + ActiveTimeBias
• Local Time = UTC - ActiveTimeBias
• Standard Time = Bias + StandardBias
• Daylight Time = Bias + DaylightBias
  

When conducting investigations,  it is very common to have to work with time stamps from different sources, many of which are in different time zones. It is easier to work with them if you convert them all to one time zone. Some investigators prefer to convert to the local time zone, and others prefer to convert all to UTC/GMT since many Internet-based logs (IIS logs, for example) are stored in this time zone. While the latter makes sense to most technical people, juries and clients are more likely to relate to the former, which is local time. You need to prepare your case to be easily understood by your audience.

Registry Timestamp Structure

Unlike file system metadata, registry keys contain only a single timestamp. All Registry keys contain a value associated with them called the “LastWrite” time, which is very similar to the last modified time of a file.  This value is stored as a FILETIME structure and indicates when the Registry key was last modified.  In reference to the Microsoft Knowledge Base, A FILETIME structure represents the number of 100 nanosecond intervals since January 1, 1601.  The LastWrite time is updated when a registry key has been created, modified, accessed, or deleted.  Unfortunately, only the LastWrite time of a Registry key can be obtained, where as a LastWrite time for the Registry value cannot.

 

Knowing the LastWrite time of a key could allow a forensic analyst to obtain the approximate date or time an event occurred.  And although one may know the last time a Registry key was modified, it still remains difficult to determine what value was actually changed.  Using the Registry as a log is most helpful in the correlation between the LastWrite time of a Registry key and other sources of information, such as MAC (modified, accessed, or created) times found within the file system.  A comprehensive discussion of that process is beyond the scope of this post.    

There’s one more drawback to the limited amount of time metadata is available in the registry—Windows frequently updates the LastWriteTime for large swaths of registry keys during system updates and service pack installations, and sometimes even from a reboot. This will often be readily apparent when conducting timeline analysis of the registry and filtering around the LastWriteTime of a key of interest. If you see a significant number of other keys—particularly within the same or nested paths—updated within the same second or minute, it’s likely you’re witnessing a change brought about by the operating system, software update, or even a security application such as antivirus.

What about deliberate changes to LastWriteTime (Timestomping)? The Windows API does not provide a method specifically designed to change a key’s Last Modified time that is equivalent to the SetFileTime function for file metadata. As a result, we rarely see attackers attempt to directly modify registry timestamps.

MRU List

A “Most Recently Used List” contains entries made due to specific actions performed by the user.  There are numerous MRU list locations throughout various Registry keys. Windows keep a log of the most recently accessed files (e.g., when you open a file using Windows File Explorer or from a standard open/save dialog box, run command using the MS-DOS prompt on the registry). There are many applications that run on Windows that have most recently used (MRU) lists such as recently opened MS Office files and recently visited web pages; these applications list the files that have been most recently accessed. The most common places for storing such lists are in the registry keys are listed below:

 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU - Lists most-recently-used commands in the Run window by user.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU - Lists most-recently-mapped network drives by user.  This can be useful in a network intrusion investigation
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU - Lists files opened and saved, grouped by extension; there is a key named for each file in the list.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU - This key tracks the application (executable) used to open the files in the previous (OpenSavePidlMRU) key
HKEY_CURRENT_USER\Printers\Settings\Wizard\ConnectMRU - Lists most-recently-used networked printers by user.
HKEY_CURRENT_USER\Software\Microsoft\Search Assistant\ACMru - Contains two subkeys that store searches carried out in Windows Explorer, which is useful in determining if the user/ intruder was searching his local or networked drives for files/directories or words/phrases, with the former stored in key 5603 and the latter in key 5604.
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TypedURLs 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\File MRU - Replace “Word” with “Excel,” “Access,” “PowerPoint,” “Outlook,” as needed. The MRU list for each MS Office program currently installed is located under this General key. We are testing now using Windows 10 with MS Office 2016 already installed.

Note: This list provides many common locations, but isn’t comprehensive. 

 

The MapNetworkDriveMRU key contains a listing of the most recently mapped networked drives. This can be important in a network-intrusion investigation because you will want to know what other machines were connected to the compromised host. Those machines are usually next in line for a compromise, because a trusted connection already exists. 

Network Connections

Whenever a Windows user connects his/her machine to the Internet or intranet, Windows will log this action in the registry. The registry lists all network cards that have been used on the suspect machine whether it is built in or attached (e.g., via USB port). The registry also reveals wireless connection profile (name, IP address, subnet mask, DHCP) in addition to the date the connection was first created and the last date the connection took place. The common registry keys for storing network connections include:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Services\Tcpip\Parameters\Interfaces\{interface-name} - Subkeys under \Interfaces\ for each TCP/IP interface. Values under this subkeys contain current network adapter configuration.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{GUID} - Profiles for networks to which the system has previously connected. 1 — Wired, 2 — Broadband, 3 — Wireless. For wireless networks, ProfileName and/or Description typically match SSID.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess \Parameters\FirewallPolicy - Subkeys for Windows Firewall settings under the Standard, Public, and Domain Profiles.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Services\LanmanServer\Shares - One value per local share; data for each values include the share path.
HKEY_LOCAL_MACHINE\SOFTWARE\SOFtWarE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Wireless - Holds the identifier of all wireless networks to which the system was connected.  More information about each of these wireless networks such as the MAC address of the default gateway, DNS suffix and SSID can also be found here.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\NetworkList\Signatures\Unmanaged - Holds detailed information about each wireless connection on the target machine. Links the identifier of the previous key to this key to provide comprehensive information about the target connection.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards - Holds a list of all network cards whether the network card is built in or is an external network card
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\Intranet - Holds list of intranet network that the system has been connected to 

The following should be noted about the key highlighted in red above.

 

The type of the  CreatedDate and DateLastConnected is binary. It is 16 bytes in length and stored as Little Endian. To decode the data, it must first be converted into Big Endian. Taking the CreatedDate for instance, it is converted into Big Endian as follows:

e6 07 09 00 02 00 0d 00 0e 00 25 00 32 00 a0 02 -> Little Endian

07 e6 00 09 00 02 00 0d 00 0e 00 25 00 32 02 a0 -> Big Endian

Each two bytes has a corresponding value for the year, month, date, hour, minute and second. By converting from Hexadecimal to its Decimal equivalent, the data is therefore decoded as follows:

Year = 07 e6 = 2022
Month = 00 09 = September (1 = January, 2 = February, ...)
Day = 00 02 = Tuesday (0 = Sunday, 1 = Monday, ...)
Date = 00 0d = 13th
Hour = 00 0e = 14:00 0r 2PM
Minutes = 00 25 = 37 minutes
Seconds = 00 32 = 50 seconds

Consequently, the decoded created date is 13th September, 2022 14:37:50.

Windows Shutdown Time

The Windows registry records when the system was last shut down in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows 

 

The shutdown value is stored using a binary value; to decode it to a readable form, use a tool called DCode from Digital Detective.

AppInit_DLLs

The AppInit_DLLs registry value contains a list of DLLs that will be automatically loaded whenever any user-mode application that is linked to user32.dll is launched. If an attacker adds a malicious DLL to this value, its code will effectively be injected into every subsequently launched application:

 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs 

Both the version of Windows and certain configuration settings can have an impact on whether the system will actually load a file that is specified as in AppInit_DLLs. The user can globally disable the loading of all AppInit_DLLs by setting the registry value HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\LoadAppInit_DLLs to 0x0.

Internet Explorer

Internet Explorer stores its data in one key and has three subkeys within it that hold the majority of useful information. The key is given below:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer

The first subkey, Main, stores the user’s settings in Internet Explorer.  It contains information such as search bars, start page, form settings, etc. 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main

 

The next key displays the last directory used to store a downloadable file from Internet Explorer, which could give a fairly good idea as to where the user stores his/her files:

 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\DownloadDirectory

 

This next location stores all URLs that a user has typed into the address field of the web browser. 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\TypedURLs

This evidence can help support assertions that a user truly intended (manually typed in) to visit a particular URL, rather than simply “clicking a link by accident.” As its name implies, the TypedURLs registry key tracks URLs that a user either explicitly entered into the address bar (via typing or copy and paste) or selected from autocomplete suggestions while entering a URL. It does not track URLs visited by clicking links or following bookmarks. Prior to Internet Explorer 10, Windows tracked up to 25 values under TypedURLs—url1 (most recently visited) through url25, each of which records a single URL. In Internet Explorer 10 and later, this maximum was bumped up from 25 to 50. The data within these values is human-readable plain text and does not require any further decoding.

Prior to Internet Explorer 10, these keys did not provide sufficient evidence to indicate when a given url# value was added. The Last Modified time for the TypedURLs key is updated upon a change to any of its subvalues; therefore, you can only determine the access time of the most recently added URL. However, Internet Explorer 10 introduced an additional key, TypedURLsTime, that contains matching sets of url# values and data indicating when each was added to TypedURLs.

UserAssist

The UserAssist key tracks applications that a user has launched through the Windows Explorer shell. You can find the UserAssist key in the location shown below:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

This data is used to populate a user’s Start Menu with a customized list of frequently launched programs. The decoded contents of UserAssist keys include the following: 

• Full paths to each executable
• Number of times each program ran 
• Last execution time.
  

 

The UserAssist key contains two or more subkeys, which have long hexadecimal names or globally unique identifiers (GUIDs) and beneath each GUID is a subkey called Count.  The Count subkey contains recorded values that pertain to objects the user has accessed on the system, such as Control Panel applets, shortcut files, programs, documents, media, etc.  These values, however, are encoded with the ROT-13 encryption algorithm.  This encryption technique is quite easy to decipher, as each character is substituted with the character 13 spaces away from it in the ASCII table.  A much faster and easier method to decipher this code is with the use of a ROT-13 decoder.

 

In  pre-Windows 7 versions, each encrypted name has a 16 byte hexadecimal value associated with it.  The fifth byte (from left to right) is a counter that represents how many times the application has been launched.  It is important to note that the counter starts at 5.  Therefore, if the counter displays a 6, then the application has only been run one time (to get an accurate count, you will need to subtract 5 from the counter).  If the UserAssist key gets cleared, then the hex counter value will start over at 5. The last 8 bytes consist of a Windows 64-bit time stamp that records when the program was last run.  With this information one can see what program was launched, when it was launched and how many times it was launched. Consider the following as it appears in the UserAssist key.

HRZR_EHACNGU:P:\\Cebtenz Svyrf\\Nqbor\\Npebong 7.0\\Npebong\\Npebong.rkr
Hex value: 24 00 00 00 15 00 00 00 40 0f 7b fa 8d 15 c8 01 (Note: Hex value is not encrypted) 

After the encrypted name has been decoded, we obtain the full run path recorded in UEME strings prefix as shown below.

UEME_RUNPATH:C:\\Program Files\\Adobe\\Acrobat 7.0\\Acrobat\\Acrobat.exe 

The fifth hex byte (with a value of 15 in this case) shows that the application has been launched 10 times (15-5).   The 40 0f 7b fa 8d 15 c8 01 is the timestamp information of the last run date, which when converted using the Dcode tool mentioned earlier gives the date and time as Tue, 23 October 2007 16:01:31 UTC.

In Windows 7 and higher versions, the UserAssist key performs the same overall function as that of the pre-Windows 7 versions; however, the artifacts that are found in these newer versions are significantly different. While the UserAssist keys have the same main artifacts, such as execution count and time stamps, the data presentation and content deserve some additional attention. First, the GUID labels in the UserAssist key are different. Second, UEME strings, which used to represent the type of User Assist value that was being shown, are all but eliminated. Third, in many cases the command-line paths that were present before Windows 7 have been replaced with path GUIDs. 

In newer versions, the UEME_RUNPATH string is missing, as is the full path to the executable. What these versios does leave us is a path GUID. If the path is not one of the well-recognized GUIDs, you are left with asking your friend Google, searching the registry looking for other commonalities, or performing some testing to determine exactly where the executable would have been run from.

Finally, the byte count in each program-execution entry of the UserAssist key is significantly greater than the 16 bytes that were found in earlier versions of Windows. With Windows 7 and higher versions, these values now contain 72 bytes of data. The two items that are often of most interest to examiners and investigators are the execution count and the time stamp associated with the last execution. The execution count is located in bytes 4–7 and represents a 32-bit integer, as it did in earlier versions. Starting with Windows 7, this counter value starts at 1 as opposed to 5 in earlier versions. The time stamp still records the time of the last execution of the program but is now stored in bytes 60–67 as a Windows 64-bit time stamp, as it was in earlier versions.

 

 

From the above, the run count is 6 times and the last run date (5F C0 63 E8 FA 19 CF 01) when converted using the Dcode tools is Sat, 25 January 2014 18:26:04 UTC.

The purpose of the other bytes found in this section is up for debate and research. Didier Stevens, who has conducted a plethora of research into the UserAssist key, suggests that some of this data (bytes 8–11) represents the total number of times the application receives focus and others (bytes 12–15) represent the amount of time that an application window has focus or the running time of the application.

Windows Prefetch

Prefetch is a feature used by Windows to speed up loading applications. Windows creates a Prefetch file when a user executes an application for the first time, and then it will record which files have been loaded as a part of this application execution, in addition to the last time this application was executed, so the next time a user launches it, Windows will load it quicker. From a digital forensic perspective, the Prefetch feature can tell us what program(s) was executed on the target system even though the subject program was uninstalled after executing it, as it will remain in the Windows Prefetch folder.

 

Sometimes we come across systems that have no prefetch files in the %SYSTEMROOT%/Windows/Prefetch directory. In those cases, it may be helpful to check the registry key containing most of the prefetch settings:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

Two of the values within this key are particularly important:

• EnablePrefetcher - Controls the Prefetcher operation. Settings are as follows: 1 – Disable Prefetch; 2 – Prefetch Boot Files; 3 – Prefetch All Applications. Prefetch is often disabled on servers and systems with solid state drives. 
• HostingAppList - Specifies special Windows applications that load other executable modules, such as DLLHOST.EXE, MMC.EXE, and RUNDLL32.EXE. The Prefetcher incorporates the loaded module into the Prefetch hash value for these applications.
  

Note that even when EnablePrefetcher is set to 3, Windows will not create an infinite number of prefetch files—the maximum number is 128.

USB Devices

Windows keeps a history log of all previously connected USB devices along with their connection times in addition to the associated user account which installs them. The Windows registry also stores important technical information for each connected USB device such as vendor ID, product ID, revision, and serial number.

 

Windows stores USB history-related information using five registry keys, where each key offers a different piece of information about the connected device. By merging this information together, investigators will have an idea of how an offender has used removable devices—such as a USB—to conduct/facilitate his/her actions.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USBSTOR - Here you will find all USB devices that have been plugged into the operating system since its installation. It shows the USB vendor ID (manufacturer name), product ID, and the device serial number (note that if the second character of the device serial number is “&,” it means the connected device does not have a serial number and the device ID has been generated by the system). See image below.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB -  holds technical information about each connected USB device in addition to the last time the subject USB was connected to the investigated computer.

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices -  Stores the drive letter allocations; it matches the serial number of a USB device to a given drive letter or volume that was mounted when the USB device was inserted.
 
HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Explorer\MountPoints2 -  This key will record which user was logged into Windows when a specific USB device was connected. The key also includes the “Last Write Time” for each device that was connected to the system.

%SYSTEMROOT%\Windows\inf\setupapi.upgrade.log (For Windows 10)  - Identify the first time device was connected.
%SYSTEMROOT\Windows\inf\setupapi.dev.log (For Windows Vista, 7, and 8) - Same information as above
%SYSTEMROOT\Windows\setupapi (For Windows XP) - Same information as above.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USBSTOR

 

User Account Information

There are a number of elements of information about the user account that are stored in the Registry. For example a list of user accounts, last login time of each account, whether it requires a password, whether it is a disabled or enabled account and the method used to hash the password of the user account. All of this information is held in the following Registry key: 

HKEY_LOCAL_MACHINE \SAM\Domains\Account\Users 

In addition the user account names are listed in the following Registry key

HKEY_LOCAL_MACHINE \SAM\Domains\Account\Users\Names

 

 

 Shim Cache

The Shim Cache, also known as the Application Compatibility Cache, allows Windows to track executable files and scripts that may require special compatibility settings to properly run. The decoded contents of this key vary by version of Windows, and can include the following data: 

• Executable or script file names and full paths 
• Standard information last modified date 
• Size in bytes 
• Whether the file actually ran on the system

The cache is maintained within kernel memory and serialized to the registry upon shutdown. The registry key location varies slightly depending on the version of Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache - Windows Vista and higher versions
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache - Windows XP

One advantage of Application Compatibility Cache over other sources of evidence is that the cache can track more items than prefetch, which rolls after 128 files: Windows 7 and higher versions maintain up to 1,024 cache entries, and earlier versions of Windows track up to 512 entries. Windows also processes and adds executable files to the cache upon changes to file metadata and path, regardless of whether the file has executed. In other words, the Shim Cache can provide evidence of executable files that never actually ran on a system.

Printer Registry Information

The Windows registry contains the entries for printing listed below:

HKEY_CURRENT_USER\Printers - Holds settings of the current default printer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print - Contains additional subkeys that hold information about installed printer

For instance, to view the properties of currently installed printers on the target machine, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\<printername> 

Computer Name

In most investigations, you are going to need the name of the computer in question. This value is stored in the registry and is located in the following key:

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName

In this key, there is a value named ComputerName, and the string data for ComputerName reveals the computer’s name.

BIOS and Processor Information

The system information Registry sub key has the following path:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS 

This key holds several values that contain information about the system such as BIOS information and product information. The BIOS information includes the BIOS release date and BIOS version. Information about the BIOS includes the product name of the system and its manufacturer’s name.

The information about the processors of the system is stored in the following Windows Registry sub keys: 

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\1

This information includes the processor name, its speed and vendor identifier.

Exploring Security Identifiers (SIDs)

Each user, group, and machine in a Windows environment are assigned a security identifier. The SID is a unique identifier in that no two SIDs are the same. Windows grants or denies access and privileges to system objects based on access control lists (ACLs), which in turn use the SID as a means of identifying users, groups, and machines, since each has its own unique SID. Consider the following SID given below:

S-1-5-21-220523388-688789844-18016745311003

 

As you will see, each part of this number has a meaning or purpose. The first part is the first and only letter in the string. The S simply means that the string that follows is an SID. The second part is the revision number, which is currently always 1 (S-1-5-21220523388-688789844-1801674531-1003). The third segment is the authority level, which holds a value from 0 to 5. This value describes the authority that issued the SID, as listed below:

0 - NULL SID authority
1 - World SID authority
2 - Local SID authority
3 - Creator SID authority
4 - Not used
5 - Windows NT security subsystem SID authority

In this example, it is a 5 (S-1-5-21220523388-688789844-1801674531-1003). The fourth part is the longest segment in the example and is the domain or local computer identifier (S-1-5-21-220523388-688789844-1801674531-1003). This string uniquely identifies the domain or local computer. This string can be, however, as short as one field for the well-known SIDs. Microsoft’s website contains a comprehensive listing of these commonly known SIDs. The fifth and final part is the relative identifier (RID), which is a unique number within the domain or local computer. In this example it is 1003 (S-1-5-21-220523388-688789844-1801674531-1003). RIDs that are less than 1000 are reserved for special accounts and groups. For example, the RID 500 is reserved for the local computer’s Administrator account, whereas the RID 501 is used for the built-in Guest account. RIDs can also be used to specify a group, such as 512, which is the RID for the global group of domain administrators.

 

Windows Services Check

In your investigation, you may want to fetch the state of a windows service from the registry. Windows services are stored in the following path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet00#\Services

In this key, you will see a list of all the services installed on your system. Each service will have its own subkey. To check the status of a service, locate its subkey and look for the "Start" value in the right pane. The value data for "Start" will indicate the current status of the service, as follows:

• 0x2: Automatic - Service starts automatically when the system boots up.
• 0x3: Manual - Service starts only when a user or application initiates it.
• 0x4: Disabled - Service is not started and cannot be started.

You can also look at the "ImagePath" value in the same subkey to see the location of the service executable on your system.

Remote Desktop

In the Registry Editor, navigate to the following key: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

Under the Terminal Server key, you can find several subkeys that control various aspects of Windows Remote Desktop. Check the value of the "fDenyTSConnections" DWORD. If the value is 0, Remote Desktop is enabled. If the value is 1, Remote Desktop is disabled. You can also check the "fAllowToGetHelp" DWORD. If the value is 1, Remote Assistance is enabled. If the value is 0, Remote Assistance is disabled.

Windows Recycle Bin Status

‘NukeOnDelete’ allows one to disable the ‘Recycle Bin’ function. This means that when a file or folder is selected and the ‘delete’ key is pressed, the file or folder will be permanently deleted (instead of going to the Recycle Bin). A Windows user can set this feature by going to “Recycle Bin Properties” and then checking “Do not move files to the Recycle Bin. Remove files immediately when deleted”. ‘NukeOnDelete’ can found at the following registry location:

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume\{GUID}\NukeOnDelete  

• 0 - Move to Recycle Bin
• 1 - Bypass Recycle Bin

Conclusion

Given the popularity of the Windows operating system in homes and businesses it is important for computer forensic experts to understand the complexity of the Windows Registry.  The information and potential evidence that reside in the Registry make it a significant forensic resource; uncovering this data can be crucial to any computer related investigation.  By understanding the importance of the Registry from a forensic standpoint, an examiner can develop a more accurate account of what actions occurred on the given machine.  As long as operating systems are dependent upon the Registry as a configuration database, there will always be new locations to discover that provide evidential support to an investigation. This Registry Quick Reference may not provide a comprehensive treatment of Registry analysis, but it is intended to present some examples and explanations of the types of data can be found, how they can be found, and why they may be relevant to an examination.