The windows registry isn’t the backbone of Windows. Still, you could argue that the registry hives are the arteries of the Windows anatomy. Instead of controlling the blood flow, the hives control how Windows operates by storing various configurations. But that isn’t all the registry is good for. Both defenders and attackers can make use of the repository for their own ends: the blue team can find forensic artifacts and the red team can create persistence.
In this blog, we explore the architecture of the Windows 10 Registry and what it means to an infosec practitioner.
Although this blog is focused on a specific version of Microsoft Windows(Windows 10), the information is also applicable to other versions. I just 10 because, well that is what was available to me. Some of the resources referenced in this blog clarify when things vary between Windows versions.
Let’s start out with a high-level discussion. At the top of this hierarchy, there are five different hives each with their own purposes. These are HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_CONFIG. Within the hives, there are branches of keys and subkeys used to organize the information. You can think of these as branches of the arteries. At the end of the branches are the keys, consisting of a name and value pair.
That’s it. The registry is a pretty simple concept. Information is stored in an organized fashion that Windows uses to make decisions. You could describe it as a database, and you would be right. In fact, Microsoft calls it a “hierarchical database. “
Let's dig in and discuss each of the hives in order.
A subkey of both HKEY_LOCAL_MACHINE\Software and HKEY_CURRENT_USER\Software, storing configurations that apply to all users on the local system and default settings for the current interactive user.
When you view the registry with the Registry Editor, you will see this hive at the very top. But this doesn’t mean it stands on its own. This is the most awkward of the hives because it exists as its own hive but is also listed under two different hives. The idea of this registry hive is to store the default settings for both the system and all the users. If you are thinking that this sounds like the job of other hives you are correct. The settings from HKCR (another name for HKEY_CLASSES_ROOT) are pulled into HKLM and HKCU. Those associated with the local system are in HKLM and those related to the current user are found in HKCU.
You may be wondering why information from one hive is being used by two others. Like I mentioned earlier, HKCR is for the default settings. Basically, if nothing has been specified in the HKLM and HKCU, then these defaults apply. We will discuss this concept more in the sections for the specific hives.
For more information on HKEY_CLASSES_ROOT see the Microsoft article “HKEY_CLASSES_ROOT Key”.
Contains the root of the configuration information for the user who is currently logged on. The user's folders, screen colors, and Control Panel settings are stored here.
In forensic guides and cheat sheets, perhaps other references too, you will often see this hive referenced as HKCU. HKEY_CURRENT_USER is the same thing, so don’t let the abbreviation confuse you. Actually, all of the registry hives, have shortended names.
As mentioned earlier, the default configurations stored in HKCR are pulled into this hive as well. However, any specific changes that are different from the defaults take precedence. So, suppose the current user has specific settings that don’t apply to all other users. In that case, they will not be overwritten by the defaults from HKCR. These non-default settings are actually stored in the user's profile in a file called ntuser.dat. The registry will reference this file anytime the specific user logs in.
Contains configuration information particular to the computer (for any user).
Like HKCU, this hive is also known by a different name, HKLM. It consists of a handful of major subkeys to which information is stored in different files. These files may be recognizable to you if you are familiar with Windows. The supporting files are all located in the path %SystemRoot%\System32\Config\ and made up of SAM, SECURITY, SOFTWARE, and SYSTEM files.
As mentioned earlier, default settings under the Software subkey are pulled from HKCR. Any changes to HKCR will update this subkey, with a few exceptions. I don’t really think there is a need to cover the exceptions here but feel free to research them on your own.
Let’s talk about the HKLM subkeys for a second. If you are clever and counted, you will see we haven’t mentioned the BCD00000000 and HARDWARE subkeys yet. The first stores configurations that are needed for boot up. According to pcministry.com, these files are stored on the “System Reserved” partition in the “\Boot” directory. If you are looking for this mysterious partition on your own computer, you probably don’t see it. Try giving the partition a drive letter. The Pcministry link has a guide for this process.
The other subkey not yet mentioned, Hardware, doesn’t really have a file anywhere. O’Reilly does a great job in their book, Managing The Windows 2000 Registry, describing its purpose and where the information comes from. The author states that the information is volatile and is actually created on bootup. When Windows begins to boot, it checks out the system to figure out what hardware is being used. The OS uses this information, in turn, to figure out what drivers need to be loaded and stores the data in the Hardware subkey
This is why I love writing blogs. I actually never knew this about the Hardware subkey until I started researching for this article. Sometimes I feel like Windows is like the Amazon rainforest, we know a bunch about it, but there is still so much to learn.
In terms of forensic artifacts, HKLM has some of the best registry artifacts. I won’t dig into them in this section but will discuss them later on.
Contains all the actively loaded user profiles on the computer.
Like all the other hives, this one also has an alternative name. You may see it referenced as HKU.
Lifewire did a great job in their article “HKEY_USERS (HKU Registry Hive)” clarifying what Microsoft means. According to them, the user profiles include any currently loaded profiles, including those that have been switched.
For instance, if a computer is used in a communal environment, say in a SOC where there are different shifts, and two analysts share a desk. When it's time for a shift change, the first
analyst locks the computer, and the other logs in with their own account. The accounts have effectively been switched. Now configurations for both accounts will be found in HKEY_USERS.
Contains information about the hardware profile that is used by the local computer at system startup.
Also known as HKCC, Lifewire does a great job clarifying this hive like they did with HKU. In the article, “HKEY_CURRENT_CONFIG (HKCC Registry Hive),” they state that it indeed holds hardware profile information but, the hive itself is just a pointer. Unlike most other hives, this one doesn’t have any files associated with the data stored within. HKCC actually just points to HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current\. Although just a pointer, you can change the configurations in either place, HKCC or HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current\. The changes will populate in the paired location.
Now that we are done with the descriptions let's discuss how you can use the registry in an investigation. My favorite reference for forensic artifacts is the Sans “Windows Forensic Analysis” poster. Go check out the poster if you want to see it in full. Below are my go-to registry artifacts that have helped me the most.
This file has so many artifacts related to a user. My suggestion is if you know a specific user was involved in the activity, grab their NTUSER.DAT file. Sans Institute has a ton of specific subkeys mentioned on the poster. However, you do not have to painstakingly go through each one.
For quickly parsing NTUSER.DAT, I use a tool called RegRipper. Just run the tool on the file and look at the output. RegRipper pulls out all the interesting data in a fraction of the time it would take you to work your way through the forensics poster. This tool isn't limited to just the user file, it can be used on several of the registry support files.
Some of the most useful items from RegRipper's output are MRU’s, search history, and recent files.
System Resource Usage Monitor (SRUM)
Personally, I just found out about this artifact a couple of years ago, but I have been making up for lost time since. This artifact stores 30 to 60 days of information about what your process are doing; how much data was sent over the network, how long it has run, users associated with the process and more. This is seriously a treasure trove of data about processes. I could talk all day about the usefulness of this artifact, but I will save that for another day.
The registry associated with this information is SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SRUM\Extensions, and the file that holds the data can be found at C:\Windows\System32\SRU\.
A good use case would be if you suspected process injection of a C2 implant but you saw no direct evidence in the logs. You could use SRUM to prove that a specific process was communicating over the network with significant traffic. This evidence also depends on if the process itself. Does the process typically send significant traffic? Chrome does but calc does not.
Another use case would be if you know a process is malicious but you have no process create logs. You want to know when the current process started. SRUM can do that.
Sometimes in your investigation, you need more information about the network history for a device. This data is all stored in one place, under the subkey SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\. Here you can find the networks that were connected to, the domain, SSID, and even the gateway MAC address.
This is especially useful for dead box forensics but you can definitely use this artifact in other scenarios as well. Such as with laptops that are constantly off an on the corporate network.
Attacking with the Registry
How about as an attacker? How can the registry help you? Most of the time, I have seen the registry used as a form of persistence. For that reason, below are keys you can use for persistence. Much of this came from the MITRE ATT&CK page, “Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder.”
Although, these aren't the only registry keys that can be used. There are tons! Perhaps I will do another blog digging into this subject a little more. In the meantime these are certainly the most common.
On the flip side, these are also keys that should be of interest to the defenders. Your adversary may be using these to maintain access to a system.
Run Keys are used to run a program at user logon. This is when a user actually logs in not to be mistaken with system bootup. Meaning they run under the context of a user versus the system.
Because they run when a user logs in, they make great persistence mechanisms. Those that say “RunOnce” will literally only run the program once.
Shell items are slightly different but can be used for persistence, nonetheless. With Shell registry entries, you are telling Windows where to find items that should be loaded when a user logs in. These include folders such as “startup.”
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Services are unique in that they run before the user logs on, making them a better option in my book. If I am using services as a beacon to my C2, I would like a connection even if a user isn’t using the system. According to an article by Blackberry, in order of execution, the RunServices keys execute before both run and shell keys.
So that’s it for this post. Hopefully, you learned a little about the registry from this blog. I know I did!
For more information about this topic, make sure to check out the embedded links to the resources I referenced. Depending on the interest in this topic, I may dive in even deeper in future blogs. The blog was already getting pretty long so I figured this would be a good stopping point.
But don't let me hold you back. The registry is a fairly vast subject. For both the blue and red persuasions, I recommend taking some time to learn the fundamentals of the topic and adding registry knowledge to your toolbelt.