Registry Analysis – The “Why”

This article has been indexed from

Windows Incident Response

Why is Registry analysis important?

The Windows Registry, in part, controls a good bit of the functionality of a Windows system. As such, Registry analysis can help you understand why you’re seeing something, or why you’re not seeing something, as the case may be.
For example, Registry “settings” (i.e., keys, values, or combinations) can be/have been used to disable Windows Event Logs, enable or disable auditing (the content that goes into the Windows Event Log), disable access to security tools, enable or disable other functionality on Windows systems, etc. The Registry can be used to enable or disable application prefetching, which produces artifacts very commonly used by forensic analysts and incident responders.
Most analysts are aware that, particularly with respect to the file system, something “deleted” isn’t always “gone”. This is true for files, but even more so for records (elements with a file), and it’s also true for the Registry. However, the Registry can be used to disable functionality the prevents activity from being recorded in the first place. As such, the records are never actually generated, and therefore, cannot be recovered. This is an important distinction to make, as over the past decade and a half, we’ve seen threat actors actively modify systems within an infrastructure to suit their own needs. For example, disabling or removing security tools, modifying operating system capabilities, and enabling or disabling functionality; whether manually or via a batch file (or some other means), many of these modifications manifest themselves as changes in the Registry. 
Case in point; in the spring of 2019, I was working with incident responders to track activities associated with the Ryuk ransomware group. Looking back to Sept, 2018, we’d seen where the actors had run mimikatz, and then within seconds, moved laterally. Closer examination showed that the actor had modified the Registry so that the operating system would maintain credentials in memory in plain text 6 to 9 days prior to running mimikatz. That way, they didn’t have to copy the hashes so that they could crack them; the credentials were already in plain text, so all they had to do was choose the account with the highest level of privileges and move to subsequent systems. This is just one example of how threat actors have modified systems within a compromised infrastructure t

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.

Read the original article: