Wednesday, October 21, 2020

Name Resolution

How often to DFIR analysts think about name resolution, particularly on Windows systems?  I know that looking back across engagements I've done in the past, I've asked for DNS server logs but very often, these were not available. I'm sure others have seen the same thing. When we moved to enterprise response and had access to EDR tools, we could look up DNS queries or create reports based on EDR telemetry, if such a thing was recorded by the agent.  In some cases, we could have the DNS queries automatically checked against a blacklist, and queries for known-bad domains highlighted or marked.

According to MS KB article 172218, Windows systems look to their local hosts file prior to making a DNS query (on the network) when looking up a host name. This hosts file is located, by default, in the %SystemRoot%\System32\drivers\etc folder.  I say "by default", because this path can be changed via the following Registry value:

Key: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Value: DataBasePath

Okay...so what?  Well, it's widely known that threat actors will (we know because we've seen it) make modifications to Windows systems to meet their needs, modifying the environment to suit their goals.  We've discussed some of those settings before, and we've seen where threat actors have changed the location of a user's StartUp folder in order to hide their persistence mechanism.  If I wanted to keep DNS queries from appearing on the network, it would be relatively easy to either just modify the hosts file, or change the default location and plant a malicious hosts file.

Addendum, 22 Oct - since publishing this post yesterday, others have tried this and found that changing the location of the hosts file does not appear to work.  At this point, I have only found the value to exist on a few of the Windows 10 1809 and up systems/images to which I have access, and through searches, I've found indications online that this does not work for Windows 7 systems.  At this point, in the absence of explicit documentation, a bit more testing would be valuable.

However, analysts should still keep in the name resolution order in mind, and be aware that modifying the hosts file itself is still something a threat actor can do.  Other issues to keep in mind include the use of persistent routes (I've actually seen this done for legitimate business purposes), as well as the use of a port proxy. Both are fairly trivial to check during DFIR pre-processing or threat hunting.


Sunday, October 11, 2020

Settings That Impact The Windows OS

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.

Application Prefetching
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.

Plaintext Passwords
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.

Conclusion
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.

#OSDFCON

 The agenda for the 11th annual Open Source Digital Forensics Conference has been posted.  I've attended OSDFCON before (several times), it's one of the conferences where I've enjoyed presenting over the years. Maybe someone reading this remembers the "mall-wear" incident from a number of years ago.

So, on 18 Nov, I'll be speaking on Effectively Using RRv3This past spring, I shared some information about about this new version of RegRipper (here, and here), as well as highlighting specific plugins. What I'd like to do is, in the same vein as the conference agenda, crowd-source some of the content for my 30 min presentation.

What would you like to see, hear, or learn about during my 30-ish minute presentation regarding RegRipper 3.0?