There are a number of settings within Windows systems that can and do significantly impact the functionality of Windows, and as a result, can also impact what is available to a #DFIR analyst. These settings very often manifest as modifications to Registry keys or values. These settings also make excellent targets for threat hunting, as well.
Most DFIR analysts are aware of application prefetching and what it means. In short, when application prefetching is enabled, files with *.pf extensions are created in the C:\Windows\Prefetch folder. These files are intended to provide quicker loading of frequently-used applications, by placing needed information in a specific, known location.
Most analysts are also aware that application prefetching is not enabled by default on server versions of Windows. As such, Prefetch files are expected on Windows 7 and 10 systems, but not on Windows Server 2016 and 2019 systems.
As Dr. Ali Hadi pointed out, not all application prefetch files appear directly beneath the Prefetch folder.
We've seen the UseLogonCredential value being used during credential access for some time now, as creating this value and setting it to "1" tells the operating system to maintain credentials in memory in plain text. As a result, threat actors have been observed creating this value (via reg.exe), setting it to "1", and then returning to the system 6 - 14 days later (depending upon the time frame, campaign, threat actor group, etc.) and using freely available tools such as mimikatz to dump credentials. In a number of cases, lateral movement has followed very shortly thereafter, as the credentials are available.
If you perform a Google search for the value name, you'll find more than a few articles that mention setting the value to "0" in order to disable the functionality; however, this will have little effect if the threat actor is able to access systems with the appropriate level of privileges to set the value to "1". However, this does provide an excellent resource for proactive, reactive, and DFIR threat hunting. This is easy to set up and automate, and you'll only need to react when the value is found, and when it's set to "1". That is, however, if the value doesn't exist within your infrastructure at all; if it does, and you find it set to "0", you then have good reason to investigate further.
Disabling Security Event Logging
About a year ago, this Sec-Labs blog post described a Registry key that, when added to a system, disabled Security Event Logging. More recently, this tweet reiterated the same thing, referring to the blog post; I tested this on a Windows Server 2016 VM and found that it worked exactly as described in the Sec-Labs blog post; the EventViewer wasn't functioning properly and after extracting Windows Event Logs from the VM image file, I found the Security Event Log was not being populated. After adding the value to the Registry, I had rebooted the system several times, which should have caused logon events to be written to the log file; however, upon examination of the Security.evtx file, this was not the case.
This is markedly different from clearing the Security Event Log. If a Windows Event Log is cleared, some, if not all, of the records may be recovered (I say "may" because it depends upon how soon you're able to respond). However, adding the "MiniNt" key to the Registry causes events to not be written to the Security Event Log, and as a result, there's nothing to "recover". Nothing is written, neither to the log nor to unallocated space.
I know...I was thinking the same thing when I read the original blog post on the topic, and thought it again when I saw that it worked.
There are other Registry keys and values that can significantly impact the performance and operation of the Windows operating system; the three listed here are by far not the only ones. Rather, they are just examples, and serve to demonstrate what I meant by "significantly impact". These keys and values can also be added to a proactive, reactive, or DFIR threat hunting process.