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.

Addendum, 28 Oct - Okay, so there's been no new info on this topic beyond the testing that's been done.  On that note, it's actually a bit sad that you can't point Windows systems to a centralized hosts file; Trend Micro recently posted regarding some new malware, which included listings of C2 services.  Being able to quickly add this info to a centralized hosts file (redirect host names to localhost) which all systems use would be very beneficial in defanging this malware.  

An alternative to this is to maintain a centralized hosts file, but have a GPO or some other process that regularly updates the hosts files, even if only on critical systems.  

So, at this point, it appears that the DataBasePath value on Win10 systems is pointless/has no discernible impact.  However, that does not mean that we don't look to other Registry locations that contain network-based information.  For example, I previously mentioned persistent routes and port proxy info, and I'd add checking the DNS server names/IP addresses for interfaces.



6 comments:

Anonymous said...

Thanks for your blog post. Always good looking for such places to hide and read that key using RegRipper or other means during compromise assessments.

...change the default location and plant a malicious hosts file.

I tested it but I failed to use an own one placed in another place than C:\Windows\System32\drivers\etc. I used C:\Windows\Temp\etc but name resolution relied on the one in System32.

was someone able to successfuly use that key to relocate the hosts file?

H. Carvey said...

Which version of Windows are you using?

Anonymous said...

I tested it on a Win 10 machine and tried a bit further by looking at procmon output. Always the default hosts file is read by the running applications and quickly after changing the file there are ReadFile ops for the hosts file by the running applications. My own hosts file from temp is never used.

Anonymous said...

It seems that this registry key it's only for backward compatibility, since windows 7 doesn't works (yes in WindowsXP):

https://forums.tomshardware.com/threads/hosts-file-alternate-location-is-not-recognized.1192243/

H. Carvey said...

I've found that the DataBasePath value exists in the System hive from Win10 1809 and 1909 systems (one each). My own personal system is Win10 2004, and the value exists.

I did find this, indicating that Win7 ignores the contents of the value:
https://social.technet.microsoft.com/Forums/windows/en-US/ac9710ff-ed68-40c5-b95a-bc8a84600a9d/ignored-hoststcpip-databasepath-registry-value-answers-amp-discussion-welcomed?forum=w7itpronetworking

It looks as if more testing is required.

Thanks, all, for contributing to this thread!

Unknown said...

No way baby let’s have dinner- netbios name,WINS, Broadcast, lmhost, host (your post), DNS
Let’s have dinner when baby leaves- lmhost, Host, DNS,WINS, Broadcast,
These are the two mnemonic devices that tell you the order of resolution of windows host going all the way back to windows 95 and NT-4.
So as an attacker host and DNS are quite delicious but there are many other resolution meals to be had on the windows host.

Dean Bushmiller