Windows DNS logging

Preface

Windows DNS logging is NOT our recommended method to collect DNS request and reply transaction for continuous security monitoring. However, sometimes we do not have an option, especially when Windows DNS debug/analytics log is the only available data source during IR investigation. In the first part of this post, we will discuss the Windows DNS debug and analytics log. Then, we will discuss other options of DNS logging for continuous monitoring. Lastly, we will also discuss some new DNS protocol such as DoH(DNS over https).

Why DNS logging?

DNS traffic is one of the most important logging for continuous network security monitoring. DNS requests will be sent whenever you are sending an email or browsing a website. Therefore, with DNS logging, we can easily identify email from known phishing domain, known phishing URL, access to known malicious C2 domain and even Typosquatting domain.

In addition, there are tons of malicious ways which leverage standard DNS query to transfer payload, establish covert channel and data ex-filtration. Some interesting tools and exploits methods includes dnscat2, PowerCloud, HITB DNS’ ex-filtration presentation, Defcon Russia DNS payload for metasploit, DNSExfiltrator, Cobalt Strike’s DNS Beacon 及 SIGRed (CVE-2020-1350)

Internationalized Domain Name

As you may also realize, you are able to use some Unicode domain name to access some website. However, when you use standard nslookup or dig tools, you cannot correctly resolve those DNS record. When you input the Unicode domain such as “中文域名.net” or “Bücher.example” in your browser, your machine will help you converting the domain name to something like xn--fiq06l2rdsvs.net. All IDN domain have prefix “xn--“, and the Unicode domain will be converted to ASCII using punycode. So when you review the log and search for Unicode domain name, you will not able to find anything. In this case, you may need to convert the Unicode domain to IDN format first. There is some online converter such as https://www.punycode.io/.

Windows DNS debug Logging

DNS Debug Logging is available since Windows 2000 (Logging tab for Windows 2000). The log format between Windows 2000/2003 and Windows 2008+ are different. In this post, we will only cover the information for Windows 2008+. Microsoft suggested to enable DNS analytics log instead of DNS debug log due to performance issue. We will discuss this later. However, ONLY DNS debug log provides parsed DNS DATA information, which is DNS reply from server. Those DNS answer provides additional value to your investigation, especially in the case attacker using DNS TXT record as C2 Covert Channel.

To enable Windows DNS debug logging, follow these steps.

• On your Windows DNS server, open “dnsmgmt.msc”
• right click the server and select Properties, then go to “Debug Logging” tab.
• Select “Details” to log DNS DATA (reply)
• The 2 options shown below both works, and it will not log duplicate packets. If you are in IR investigation, take a note of below 2 options to understand what is expected in the log file.

Also take a note that whenever the DNS server is restarted, the log file is cleared.

TrustedSec had an article discussed the structure of the DNS log file. In short, the log file provides many low level information, including the most important DNS reply.

TrustedSec also wrote a powershell script to parse the DNS log file. However, it do not work in our environment(Windows 2012R2 and PowerShell 5). We have also developed another powershell script(windows_dns_debug_log_parser.ps1) to parse the DNS debug log file in csv format.

DNS analytical log

DNS Analytical Log is available since Windows 2012 R2+. You will need to install KB2956577 for Windows 2012 R2 to use this feature. The performance hit of enabling DNS Analytical Log is low as suggested by Microsoft 網址.

There is no apparent performance impact for query rates of 50,000 QPS and lower.

Microsoft

To enable DNS Analytical Log, follow these steps:

• Open “Windows Event Viewer”, click on “View” -> “Show Analytical and Debug Logs”
• Navigate to “Application and Service Logs” -> Microsoft-> Windows -> DNS-Server -> Analytical
• right-click and select Enable Log

As a side note, you CANNOT directly access the real time log without disable it. Analytical logs are stored in event trace log (*.etl) format. If you are Splunk fans, you cannot directly monitor it as regular Windows Event Log. For Spunk monitoring, there is an app available in splunkbase. Basically, it includes a powershell script which copy the etl file to a tmp directory defined by $env:TEMP environmental variable. Then, the script will parse the temporary etl file and remove the etl file.

DNS analytical log format

Now, we are going to explore the log format. Firstly, we will perform an nslookup.

As you can seen below, the DNS analytical log provides some interesting field such as source, query and packet data, which is hex value of query or response.

We have include a comparison between Event Viewer and WireShark capture. Turns out, the PacketData is exactly the DNS payload right after the UDP header. The Event ID 260 contains exactly the same DNS payload as WireShark DNS request.

We have include another comparison between Event ID 261 and WireShark capture. The Event ID 261 contains exactly the same DNS payload as WireShark DNS reply.

Many industry expert including MENASEC suggested Event ID 256 and 257 are enough for security analysis. So, if we also consider analysis PacketData, Are these 2 Event ID provides enough information ? To answer this question, we will use python dnslib to analysis the packet data. Firstly, we will analysis the request packet.

As you can see above, the DNS request from Event ID 256 was decoded successfully and it contains all the request information needed.

As shown above, the DNS reply from Event ID 257 was also decoded successfully and it contains all the reply information needed.

A word about DNS header

We are not going to discuss too much about the DNS header. One good article is available 網址. There is a feature called DNS Pointer/offset/compression, which aimed to make the DNS packet as small as possible. In short, if the “word”(such as .com/.net) exists in any part of DNS reply packet, the reply packet give an offset point back to the location of the “word”. The sidestep command successfully shown that this technique successfully evade IDS alerts. After so many years, SIGRed further use this pointer technique to cause buffer overflow of Windows DNS server.

DNS analytical log parser

We have developed 2 version of DNS analytical log parser. The python version is fast and it is capable to decode most DNS Packet Data field, but the information is sometimes too verbose. The PowerShell version is slower but capable to decode and format TXT record, CNAME record and A record more friendly. We use both version during our IR engagement, and the PowerShell script sometimes make us easier to spot suspicious TXT record.

Common issue of DNS logging

We worked with many organization to help them establish continuous security monitoring. Certainly, DNS is a key data source. However, some organization may prefer to enable DNS logging on their Windows DNS server because they think they only allow DNS request from their DNS server. In many cases, it is not the story. We have experienced sysadmin simply configure google DNS as the DNS server of server inside DMZ. This greatly reduce the monitoring visibility.

In the above table, we have summarized some more options to log DNS payload for analysis. Zeek(formerly Bro) is a de-facto standard of network security analysis for many years. It had been adopted by many commercial vendors such as FireEye and Corelight. In addition, Security Onion had integrated various open source security monitoring including Zeek and ELK. As you can see below, Zeek parsed the dns packet into some meta data and store into dns.log file. We have also adopted hybrid approach which use log from DNS server as primary threat hunting source, while Zeek dns.log as the secondary threat hunting source.

DNS over HTTPS (DoH)

DoH is now a hot topic for security monitoring. Cloudfare had a great post explaining DoH 網址. While it can protect user’s privacy, but it also greatly increase the challenge of security monitoring. To deal with DoH in security monitoring, there is some options:

• Block dns-over-https using Palo Alto
• Blocking Firefox DoH with Bind
• Dealing with DoH: Methods to Increase DNS Visibility as DoH Gains Traction