Windows DNS analytical log Event Viewer EventID 261 first reply

Windows DNS logging

| | | | |
ByKelvin Yip

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.
Windows DNS Debug Logging No Request
Windows DNS Debug Logging No Outgoing

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.

Windows DNS Debug Log Parser Result
Result of windows_dns_debug_log_parser.ps1

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.

nslookup result

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.

Windows DNS analytical log Event Viewer EventID 256

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.

Windows DNS analytical log Event Viewer EventID 260 first query
WireShark DNS request 1

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.

Windows DNS analytical log Event Viewer EventID 261 first reply
WireShark DNS reply 1

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.

Windows DNS analytical log Event Viewer EventID 256 2
python dnslib request

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

Windows DNS analytical log Event Viewer EventID 257 2
python dnslib reply

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.

Other Options of DNS logging

ProductImplementationFeatures
SplunkUF installed on DNS serverSimple & SIEM integration, Pre-parsed field, High license fee, May not capture all traffic
SplunkUF agent listen on network tapSimple & SIEM integration, Pre-parsed field, High license fee, Capture ALL DNS traffic if tapping on Internet gateway
PacketbeatInstalled on DNS serverSimple & SIEM integration, Pre-parsed field, No license fee, May not capture all traffic
Packetbeatagent listen on network tapSimple & SIEM integration, Pre-parsed field, No license fee, Capture ALL DNS traffic if tapping on Internet gateway
Bro/Zeekagent listen on network tapSupport by SIEM, Pre-parsed field text file, No license fee, Capture ALL DNS traffic if tapping on Internet gateway

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.

Bro/Zeek DNS capture

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:

相關文章

  • LAPS logging and Splunk

    ByKelvin Yip

    When I try to search it in Splunk, nothing comes out!! According to Splunk, Event Code 4662 is too noisy, and Splunk gives an example to filter all Event Code 4662. I realize I use the sample inputs.conf from Splunk. Below is snippet of default inputs.conf.

    It took me a couple of days trying many combination of inputs.conf, and finally I figure out the correct syntax.

  • | | |

    Import EventLog into Splunk

    ByKelvin Yip

    As Splunk also use native Windows API to process the exported evtx file, you must use a Windows machine with Splunk installed (either Universal Forwarder or any full Splunk instance including All-in-one Splunk instance or Heavy forwarder instance) to process the evtx file. In other word, the inputs.conf should be deployed or defined on a windows machine in order to successfully import EventLog/Sysmon Event Log into Splunk. You will need to use the sourcetype preprocess-winevt. If you do not explicit define it, Splunk will display garbled characters after import EventLog evtx file. You can find the working version of inputs.conf below

  • | | | | |

    Splunk local threat intel

    ByKelvin Yip

    Why yet another Splunk local threat intel article ? Obviously, there are many excellent articles: Unlike other articles, we mainly focus on common operational issues of Splunk local threat intel usage including: Before we start to discuss those operational issues, let’s explore the workflow of threat intelligence framework. Basically, it consists of 4 phases: Threat…

  • | |

    Dump password from exe(2)

    ByKelvin Yip

    This article is actually part two of “Extract/Dump password from exe” series. In part one, we focused on unpacking executable generated by script converter such as PyInstaller, Py2exe and AutoIt. In short, we will focus on executable compiled by Visual Studio and Delphi in this article. Basically, we will try to understand what information is…

  • | | |

    PowerShell Core Logging

    ByKelvin Yip

    Many security professionals know the importance of PowerShell logging. It give us great visibility for Incident Response and Threat Hunting process. FireEye wrote a great article about PowerShell logging here. As Microsoft already launch Power Shell Core, we also need to consider PowerShell Core (PowerShell 6/7) logging. As a side note, the executable name of PowerShell Core is pwsh.exe and therefore usually co-exists with the original powershell.exe executable. In reality, organizations are shifting more and more workload to cloud such as Azure. Both the developer and operation team trends to use more and more PowerShell to manage their cloud instance. I saw some developer and operation team install PowerShell Core on their own. This may be risky! So, I suggest we turn on the log before they install the tools.

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *