Windows Incident Response
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
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: