Getting Started With The Windows Registry

Key Takeaways

The Windows registry is one of the most artifact rich sources of evidence that we have on a Windows system. And yet, it's also one of those topics that can feel a little intimidating when you first start digging into it. All right, the registry is massive. It's dense and the data inside it isn't always presented to us in a way that's immediately human readable. But once you understand how the registry is structured and where the key forensic artifacts live, it becomes one of the most powerful tools in your investigative toolkit. You know, it can tell us what programs were executed, what files were accessed, what devices were connected to the system, things like how persistence was achieved. And in some cases, as we'll see later on, it can even store malware itself. And so in this video, we'll take a look at how the registry is organized, as well as some common data formats and artifacts that you'll encounter, and also the tools that we can use to analyze them. Then we'll wrap things up with a practical example of hunting for fileless malware that's hiding directly inside the registry. Let's get into it. All right, so let's start out with just the basics. So at its core, the Windows registry is a collection of database-like files that store configuration data for the operating system. And Windows uses the registry to manage, well, configuration settings for different applications or hardware, things like user preferences, security policies, services, right? Essentially anything that the system or its applications needs to keep track of. Now, the registry is organized into a hierarchical structure. The easiest way to think about this is kind of like its own file system, right? We have keys, which you can think of as folders, right? Keys contain different subkeys, which are just nested folders underneath them, giving us that sort of folder-like organizational structure. And then inside those keys, we have values. And values are where the actual data is stored. And each value has a name and also a data type and, of course, the data itself. And the data types you'll encounter most often include things like strings. We might have 32-bit integers, right? For things like Boolean flags or different configuration toggles. We have raw binary data. You'll see this one a lot in different forensic artifacts and often it requires us to decode that information as it's stored in the registry. We'll also see things like strings that contain environment variables or an array of multiple strings. And so, understanding this structure and these data types is going to be important because a lot of what we do in registry forensics involves navigating to specific keys and then parsing out and interpreting the values stored inside of them. Now, the registry itself is made up of what we call hives. A registry hive is essentially its own self-contained file. Right? A collection of keys, subkeys, and values that get loaded into memory as the computer is running and as users are logged in. Now, the core system hives live on disk and we can find them at C:\Windows\System32\Config. And they'll all be found in this directory here. And specifically in this directory, we'll find things like the SAM file or the SAM hive, right? The Security Account Manager. And this contains local user account information, things like password hashes, group memberships, different account metadata. We have the Security hive, all right? As you can see from this file here, this stores security policies, things like audit configurations, cached domain credentials. We have the System hive, which contains hardware configuration, right? So things like services, boot parameters, a number of important forensic artifacts we can find here like Shimcache. The Software hive contains information about the installed applications, right? Or different operating system settings and a ton of system-wide configuration data. And we can also see this default hive here. This is sort of referring to the default user profile template that gets applied to new user accounts that get created on the system. We also have additional system hives like Amcache, for example, which lives at C:\Windows\AppCompat\Programs and Amcache.hive. Amcache is an incredibly important or useful artifact that tracks application execution, things like installed programs, drivers, and shortcuts. It gives us a really detailed picture of what software has been present and run on the system. Now, beyond the system hives, we also have what are known as user hives, right? So each user account on the system has its own registry hive that stores configuration settings and different artifacts tied specifically to that user's activity. And this is a really good way to profile user behavior during an investigation is through these different NTUSER.DAT hives. And the primary user hive, again, is going to be under C:\Users under the username, and then the file is called NTUSER.DAT. This is, again, where we're going to find artifacts related to program executions, file access, typed paths, user preferences, and much more. And we can get all types of forensic evidence from here related to what programs a user ran, what files they opened, what searches they performed, right? Really useful stuff for building a timeline of user-specific activity. And then there's also things like the userclass.dat hive, which is found under C:\Users under the username, AppData, Local, Microsoft, Windows, and then userclass.dat. And this hive contains an additional set of forensic artifacts like ShellBags, which track folder access and navigation, even for folders that might have been deleted. It also contains data related to And so my tip for you is don't overlook this file, this userclass.dat hive, in your triage collection or analysis. It's easy to miss because, again, it's not in that sort of standard location, but it can contain some really valuable evidence. Now, an important distinction to make here is between live registry hives and offline registry hives. Now, when we're working on a live Windows system, we access the registry through what are called handle keys. These are sort of these root level keys that you'll see in, for example, Regedit, right? We can see references to HKEY_LOCAL_MACHINE or HKLM, which gives us access to the system-wide hives. We also see things like HKEY_CURRENT_USER or HKCU, which maps to the currently logged in user's hive. So on a live system, you know, for instance, HKLM/SAM maps over to the SAM hive file. Security maps over to Security, System maps over to System, and so on, right? HKCU maps over to that user's NTUSER.DAT hive. In forensics, we're often times going to be conducting our registry analysis on the hive files themselves, right? Offline, maybe pulled from a triage image or even extracted from disk, rather than doing live analysis on a system. This is generally preferred because it preserves the integrity of that evidence while we're working with a copy, rather than, you know, modifying the live system or all the different registry changes that are happening on a system as it's just doing its normal thing, right? As it's running. That said, in live incident response scenarios, we could absolutely be interrogating and querying the live registry. And we can do that through many different tools, right? We can do it natively through PowerShell or through reg.exe, the command line, or even Regedit for, you know, some some quick spot checks, depending on what we're doing. Both approaches have their place depending on the situation. Now, as you start exploring the registry for forensic evidence, you'll frequently encounter what are called MRU lists or most recently used lists. These are exactly what they sound like, sort of these ordered lists that track the most recent items that, say, a user has interacted with. For example, we might find MRU data for recently opened files or recently typed paths in the run dialog. Maybe recently used search terms or recently accessed documents by file extension, right? A good example of this is the recent docs key. One important thing to note here is that registry keys contain a last write timestamp in UTC format. This timestamp updates whenever any value within that key is modified. And this is really useful for us because it helps us establish a timeline. We can correlate when a key was last modified with other forensic artifacts, you know, file system timestamps, event logs, network activity, to sort of build a more complete picture with this corroborating evidence of what happened and when. But an important point to note is that this last written timestamp belongs to the key, not the value itself. So if a key has multiple values that are being written to, there's scenarios where there's sometimes some ambiguity there. Let's briefly talk about the data formats that you'll encounter when examining registry values because it's not always as straightforward as just reading plain text data. A lot of forensic artifacts in the registry are stored in formats that require some level of decoding or interpretation. You know, you might encounter hexadecimal values, right? Raw hex data that needs to be converted to make full sense of it. Where frequently when we come across timestamps, we might be dealing with Windows file time timestamps, kind of this 64-bit value representing the number of, what is it? The number of a 100-nanosecond intervals since January 1st, 1601. These aren't exactly human readable at first glance, but they're precisely and widely used across different Windows artifacts. We might come across weird things like ROT13 encoded strings, like what we see with user assist entries, where program names are, for whatever reason, obfuscated with just the simple letter rotation cipher. We commonly see Base64 encoded data as well. Sometimes you'll find values encoded in Base64, particularly when we're dealing with certain application configurations or, unfortunately, within a lot of malware configurations, too. The good news is that most forensic tools will handle these types of decoding for us. For example, in Registry Explorer, which we'll take a look at in a moment, there's a built-in decode tool that can convert things like hex values. It can interpret file time timestamps. It can decode Base64 and much more. So even when the raw data looks like gibberish to us, we don't need to panic. We have ways to make sense of it pretty quickly. All right, so now let's look at a practical example that ties a lot of this together. So, we're going to look at hunting for fileless malware in the registry. And fileless malware is a technique where the malicious payload doesn't exist as traditional files on disk. Instead, the malware stores its code in things like the registry, often as encoded or obfuscated values, and uses legitimate system processes to execute it later on. This makes it particularly evasive because, you know, again, there's no malicious executable sitting on disk just waiting for, you know, antivirus to scan it. Now, there many other ways to conduct fileless malware attacks, and personally, if you ask me, it's sometimes a pet peeve of mine to refer to registry-based malware as fileless malware because, as we talked about, the registry hives themselves are on disk as files, but, you know, we can debate the semantics another time. One of the more well-known families that use this kind of technique is Koadic, the Koadic malware here. This is a click-fraud Trojan that kind of stores its payload entirely in registry values, encoding its malicious scripts in the registry, and using file association hijacking to later execute them. So, let's see how we might go about detecting something like this. And so, again, I have a sample of the Koadic malware here. And the first thing I'm going to do is fire up Process Monitor, or Procmon, another fantastic Sysinternals tool. And I want to see what this malware does when it executes, specifically what registry activity it generates. And so, I'm going to head over to my filters here. And what I'm going to do is set up a filter so where the process name is koadic.exe. And what I'm also going to do is set up a second filter here to make sure I'm only looking at events where the operation is Reg Create Key. Because that's specifically what we're interested in here. We want to see what registry keys this malware is creating when it runs. All right, so just add that. And with these filters in place, I'm going to kick off the capture here. And I'm going to set this over to the side. Just so I can execute this malware side by side, and we can see exactly what it's doing as it runs. And so, I'm going to right-click and click on run as administrator on our malware here. And we will let it go. That malware is now loaded. It's running on the system. It's executing. And there we go, we do have some activity, specifically some Reg Create Key operations from that Koadic executable. And so, this malware created a few different registry keys here, all of them being under this HKLM Software Wow6432 Node subkey. Now, this is a section of the registry that uses Windows to handle 32-bit application compatibility on 64-bit systems. And so, when a 32-bit process writes to the software hive, its entries often end up here under Wow6432 Node, rather than just directly under software, kind of this registry redirection thing going on here. And interestingly, these first two entries here appear to have completely random names for the key. And this random naming we're seeing here is very common with malware, whether it's you know, things like share names or process names, registry keys and values, service names, you know, whatever it may be, attackers will frequently randomize these identifiers or these IOCs to make it harder to write static detection signatures for. And so, we did capture that activity. So, what I'm going to do is minimize this now, and I'm going to open up Registry Explorer so we can look at the live system's registry hives and see what was actually written. All right, so within Registry Explorer, I'm going to open up my live system software hive here, because again, that's where we saw that those are being written to under HKLM Software. And if we drill down to Wow6432 Node, we're going to see that randomly named key. And if we open that up, inside that key, we see these two values here, also seemingly have their own set of random names for the value names here. Now, we can see that the value type for both of these is a string, right? We see Reg_SZ. But when we expand the data, this is clearly not your typical string content, right? The first value here contains what appears to be raw encoded binary content, right? We just see a wall of garbled non-printable characters and symbols. This is the malware's encrypted payload stored directly as a registry value, right? There's no file on disk holding this content. It just lives entirely right here in the registry. The second value here is more interesting. It starts out with what looks like heavily obfuscated script code, right? We see these long randomly named variables being assigned to long random strings, almost like a variable declaration. As we continue scrolling through this value, and it's a very long entry, we start to see some really telling fragments, right? We see different things like string from character code, we see parse integer here, right? ParseInt, we see substring length. So, what we're looking at here is heavily obfuscated script that when executed is going to decode some of these hex values that we're seeing here in these different variables and reconstruct the malicious logic. These random variable names and, you know, all these junk string assignments, this is all more so just padding your obfuscation, right? It's just here to bloat up the code and make static analysis more difficult. Now, we're not going to get into fully reverse engineering this sample today. Maybe that's for, you know, a video for another time. But the takeaway here is what Koadic has done, right? It's split its malicious logic across multiple registry values, using one to store, you know, different payloads, and another to store the decoding and execution logic, but no files on disk, right? Technically. The persistence mechanism simply points back to these registry entries and uses legitimate Windows processes to kick off the execution chain. Now, here's a really practical hunting technique that I want to show you. Let's say that we didn't have Procmon running, right? Let's say we we've been handed a software hive from a triage collection, and we need to look for suspicious activity. How would we go about finding something like this hidden in the registry, right? The registry is huge. Well, in tools like Registry Explorer, we can use the find menu, right? You just hit Ctrl F, and we have a really powerful option to search by minimum value data size, right? And the key here is simple. It's a very common threat hunting technique. Legitimate registry values tend to be relatively small, right? It could be pointing to a file path or a configuration string, you know, numbers, right? Malware that's storing encoded payloads or obfuscated scripts in the registry, on the other hand, need to store a lot of data, right? So, if we crank this minimum size up to something like 100,000 bytes and run our search, we're essentially asking, "Show me any registry values in this entire hive that contain more than 100 kilobytes of data." And when we run that search, we get a handful of results across the entire software hive. A few of them are legitimate Windows entries, things like, you know, cached font data we might see here, things like theme configurations or different application blobs that, again, naturally legitimately store larger values. But right there, very quickly visible to us, we see our two values under their random names, right? They stick out like a sore thumb. And that's kind of the ironic part. By randomizing their key and value names to evade that traditional signature-based detection, the malware authors have made a choice, right? They actually made it easier for us to spot if we know what to hunt for, right? A legitimate application is going to have recognizable human-readable key names. These randomized key names sitting under Wow6432 Node with, you know, a couple of 200 kilobyte string values full of garbled data and obfuscated JavaScript, that's really going to raise some red flags for us very quickly. And so, this is a perfect example of why understanding the registry matters for forensic investigations or even malware investigations, right? Intrusions. If we're only looking at the file system for malicious executables, we're going to miss a ton of data entirely. This malware lives in the registry, and we have to know to look there. All right, and I think this is a good spot to wrap things up for now. But hopefully, you found that interesting, and you can see why the registry is such a gold mine for forensic evidence. You know, we covered the basic structure and terminology, and then we walked through a practical example of hunting for fileless malware hiding directly in the registry. And honestly, we've still only just barely scratched the surface. The Windows registry is incredibly deep, and there are so many more artifacts and techniques to explore. But as always, if you enjoyed this video, be sure to leave a like and subscribe to the channel if you want to see more just like this. So, thank you, and see you next time.