Chris Sanders tweeted out an interesting pair of questions recently, and the simple fact is that for me to fully answer the question, the tweet thread would be just too extensive. The questions were:
What are the most common reasons you go looking in the Windows registry? What do you use it to prove most?
Like almost everything else in DFIR, my response to the both questions is, it depends. Why? Well, it depends upon the goals of your investigation. What I use the Registry to prove depends heavily on what I'm trying to prove, or to disprove. This may sound pretty obvious, and even intuitive, but far too often in DFIR, we can find ourselves far too easily chasing down rabbit holes that have little, if anything, to do with our investigative goals.
Configuration
The Windows Registry holds a great deal of configuration information, describing what functionality is enabled or disabled, what tools can be accessed, etc. There are many more options available than what we see when we first install the OS; many are not well documented, and many are undocumented. Many configuration settings are described as being accessible through a UI of some kind, and the end result is a Registry modification. For example, many of the settings in the Local Security Policy, as well as GPOs, result in Registry modifications. Several settings accessible via the Windows Security UI also result in Registry modifications.
Another example is that the Registry contains a great deal of information that pertains to the auditing and logging, including not only the audit configuration of the system, but also the Windows Event Logs that are enabled. There's even an undocumented Registry key that, if you add it to the system, the Security Event Log is no longer populated. As we saw with NotPetya, clearing the Windows Event Log only gets a threat actor so far; cleared records can be recovered from unallocated space. However, if the Windows Event Log in question is disabled, then the records are never actually written to disk. This can be very challenging for an incident responder, but it also means that a dearth or absence of Windows Event Logs is no longer a matter a guesswork or assumption; it's trivial to query the appropriate locations within the Registry, and base your findings on fact.
Keep in mind that the breadth of configuration information available in the Registry is dependent upon the use of the system (both the user, and how it's used), as well as the installed applications.
Persistence
When some analysts think of persistence, they think about the Run or RunOnce keys. Why not? These are pretty popular. In 2012, a Google researcher shared that they'd combed across a popular commercial AV web site and found that 51% of the Registry paths led to a Run key. The bad guys use these keys for persistence, because they work, and work reliably.
However, as Hamlet said, "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." There are more ways to remain persistent on Windows systems, within the Registry, than just a small handful of keys. Different locations in the Registry allow for programs to be automatically executed on system boot, user login, user logoff, system shutdown, upon the launch of various applications, etc.
Proof of Life
There are a number of Registry keys that contain values that are the direct result of user activity, and can be used to place the user at the keyboard, or not, as the case may be.
Another valuable aspect of the Registry is that in recording user activity, as a means of enhancing the user experience, information about installed and/or executed applications can remain in the Registry, even after the application is deleted or uninstalled from the system. The same is true for files; there are locations within the Registry that will record information about a user's interaction with files that remains long after the file is removed from the system. This is also true for shares and devices; remnants remain well beyond the "lifetime" of the connection.
DEFAULT File
Most folks don't really look in the DEFAULT file (located in the system32\config folder), but Registry modifications made by commands executed via LocalSystem account will end up in this file.
I've seen entries for PSEXEC.exe in this file, I've seen entries added to the Run key in this file, and I've seen where entries added to the Run key further populated the Run keys in NTUSER.DAT files for user profiles created after the value was added to the key in the DEFAULT file.
This particular file can be very interesting simply due to the fact that it's not modified via normal user activity; as such, any unusual or new keys or values that appear in this file should be of significant interest.
Finding New Things
Very often, I will go looking in the Registry to see if there were any changes to the threat actor or malware TTPs, based on previous cases, or from information available via open reporting. By casting a wide net across a finite, deterministic space, you can determine if the threat actor was using the same TTPs observed on previous cases, or if they'd opted for a new technique.
One of the challenges of relying on open reporting of threat intelligence is that very often, such reporting is not specifically intended for use by DF analysts and incident responders. This is illustrated in the gaps in DF-specific information, as well as incorrect use of nomenclature. For example, this malware write-up* states:
The malware stores its configuration in ‘\\HKCU\Software\Microsoft\Windows\DWM\‘, using registry keys that consist of a uid generated from the serial number of the C: drive and appended with a single digit or character.
Where the statement mentions "registry keys", it should read "values". Some may consider this pedantic, but programmatically, Registry keys and values are very different; their structures are different, the information contained in the structures are different, and the code used to enumerate Registry keys beneath the DWM key is very different than the code used to enumerate values from beneath the same key.
As such I will often pursue examination of the Registry to identify either the malware family, or attribute activity to an identified threat actor (i.e., attribution), or determine if there were any differences between what I was seeing, and the open reporting.
Registry keys, values, and data (or the lack thereof) can provide insight into a threat actors intent, sophistication, & level of situational awareness, as well as provide insight into attribution. Very often, it's not just a single key or value, and context is king!
Conclusion
There are basically two ways to go about digging into the Registry; casting a wide net, or intentional extraction. As Boris the Animal said in MiB3, "I prefer to do both." By automating both techniques, it's a relatively simple process to validate previous findings and open reporting, as well as find new things. The key, however, is that this is a living, continual process, as new findings are baked right back into the process.
While this blog post is not all-inclusive, I wanted to take a shot a providing a more comprehensive response to Chris's questions than would make sense in a long series of tweets.
*To be fair, my pointing out the above malware write-up is not single out the author; not at all. Microsoft is widely known for making this mistake a great many times, in their own write-ups, and we see this quite a bit more than I'd like to admit in open reporting.
No comments:
Post a Comment