Maximizing Your Defense with Windows DNS Logging

Improve Defense via Targeted DNS Logging

The aim of this post is to introduce you to log collection on the Microsoft Windows platform. We will start with an illustration of a Windows source-only log deployment, followed by a collection of chosen fields from log samples and a brief description of these sources. The last part will be on audit logging, as it holds an important role in ensuring infrastructure defense.

Windows Log Deployment Scenario

In order to begin the investigations covered in the second part of this post, analysts and incident responders need to be armed with the relevant DNS and domain logs, thus giving them visibility over relevant events occurring on the network. Your organization may already be deploying a form of centralized logging at some sort of scale similar to the one shown below. If not, there is always room for improvement!

From Source to SIEM

On the left-hand side are possible log sources. I defined a small portion of a sample log deployment, even though the actual number of unique log source endpoints is much more than what has been illustrated here. Then as we move to the right of the diagram, we see how logs may be forwarded through to a log management server or data lake, then on to a SIEM for further actions.

From These Event Sources…

The source-side of the diagram on the left illustrates a few potential sources. A client machine is shown to represent that there are events occurring client-side that need to be collected. I have added labels to show a few samples of the types of events to collect —such as events generated by Windows Sysinternals System Monitor (Sysmon), any subscriptions to high-value EventIDs, and channels. There are also other log sources not using Windows Event Log telemetry, such as file-based logging, and other log sources which are grouped in the “other predefined collection processes” area such as (represented in icons) Windows firewall, Powershell logging, ingress logging.

There are three servers that have been defined in this example:

An on-premise mail server, the Exchange server. It is set up to collect Exchange Message Tracking Logs that, in the metadata, contain IP, and hostname information.
The Windows DNS server. Log collection is set up on the DNSServer Windows EventLog Analytic channel, as well as audit logging. Collection may also be manually enabled and set up to collect DNS Debug log events.
The Active Directory server. This server is a high-value target for many reasons. Log collection is set up to collect GPO or Group Policy Object logs, as well as Audit logs.

There are many other log sources that provide valuable intelligence for DomainTools investigations and integrations, like logs sourced from firewall events, Windows IIS server logs, ingress authentication attempts, and more. You may even deploy a baseline collection as well as an option to enable suspected baseline collection which would entail a more verbose or expanded collection of a suspected target machine.

…to the SIEM for Integrations, Automation, and Analysis

Windows subscriptions may be deployed to pull only Windows EventLog events (via WEF, Windows Event Forwarding). From these client/server sources, such events are forwarded to a Windows Event Collector.

Another collector, either provisioned by the SIEM or a third party, will also be deployed to collect more events, to expand the visibility, and to ensure that other types of logs are not left behind—such as file-based logging.

These events may be eventually forwarded to a data lake or a log management server. All logs do not make it to a SIEM for reasons such as storage, infrastructure and licensing costs, and that not all events may not have a SIEM supported use case.

The process of log normalization is important, seeing as the entries are not written in a standard format. In addition to normalizing the logs, parsing and enrichment of these events are applied. These processes are done on transit by the collector and/or on disk on the source itself or on the log management server.

Once the logs reach the SIEM, they are used for additional integrations, to furnish any other actions to be done (triaging), enrich analysis, trigger alerts, and so on.

Windows Event Log

So far we have covered a log deployment example. The following are example fields from selected Windows DNS logs to give you an idea of the types of information provided. Note that these are already enriched/written to another format and they are only snippets and not the full log itself.

Windows DNS Client Sources

Windows DNS client event sources specific to DNS events include:

Windows Event Log channels (DNS Client Events – Operational)
Sysmon Event ID 22 DNSQuery
Event Tracing for Windows (Microsoft-Windows-DNS-Client ETW Provider)

Sysmon Event ID 22 DNSQuery Sample

"Hostname": "sld.tld."
"Severity": "INFO"
"EventID": 22
"Source": "Microsoft-Windows-Sysmon"
"ProviderGuid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}"
"Channel": "Microsoft-Windows-Sysmon/Operational"
"Domain": "NTAUTHORITY"
"AccountName": "SYSTEM"
"UserID": "S-1-5-18"
"AccountType": "User"

In the above example, we can see that this event is from an instance called “sld.tld.” Since we know the originator of this event, it is then useful for finding the source should an investigation be made for IR. The fields for Domain, the Account Name, and security identifier (SID) (or UserID S-1-5-18) may also be useful.

"Message":
Dns query:
RuleName:
UtcTime: 2020-10-29 11:32:43.274
ProcessGuid: {b3c285a4-5f1e-5db8-0000-0010c24d1d00}
ProcessId: 5696
QueryName: example.com
QueryStatus: 0
QueryResults: ::ffff:93.184.216.34;
Image: C:\Windows\System32\PING.EXE

Included in Windows events are the Message field. From the Message field (which had been parsed here), we can see that Sysmon Event ID 22 DNSQuery event was emitted due to the ping command used with example.com.

What is a sample application of Sysmon Event ID 22 logging?

Let’s say that example.com is a link of high interest. One of the app features is enriching results with a Risk Score, and in this case, example.com obtained a high risk score of 90. With the logs that have been collected, we can trace back to the date, time, hostname, account, the utility program, so on. Further incident response actions such as finding the originating source, can help with isolation/containment measures of an instance as well as providing a use case to begin more extensive logging as a targeted machine. Assuming that 600 million events per day are collected, then isolating such incidents to a specific timeframe range may also help reduce MTTD/MTTR to obtain and find other IOC EventIDs.

The sources for DNS server events are:

Event Tracing for Windows (Microsoft-Windows-DNS-Server-Service, Microsoft-Windows-DNSServer ETW Providers)
DNS Debug log file
Windows Event Log channels

ETW / Windows DNS Service Provider Source

The following is a snippet from the Microsoft-Windows-DNSServer/Analytical channel for Event ID 260. It is only a portion of an event tracing example in key-value pairs.

"Source": "Microsoft-Windows-DNSServer"
"ProviderGuid": "{EB79061A-A566-4698-9119-3ED2807060E7}"
"EventId": 260
"Severity": "INFO"
"Domain": "NT AUTHORITY"
"AccountName": "SYSTEM"
"UserID": "S-1-5-18"
"AccountType": "User" 
"TCP":"0"
"Destination": "destination.IP"
"InterfaceIP": "interface.IP"
"RD": "0"
"QNAME": "subdomain.sld.tld"
"QTYPE": "28"
"XID": "17271"
"Port": "0"
"Flags": "0"
"RecursionScope": "."
"CacheScope": "Default"
"PolicyName": "NULL"
"BufferSize": "76"
"PacketData": "0x437700000001000000000001096C6F63616C686F73740975732D656173742D320D6563322D7574696C697469657309616D617A6F6E61777303636F6D00001C00010000290FA0000080000000”

QTYPE means that it was an A record, an IP address.
QNAME: is from my own instance.
AAAA: 28 indicates a 128-bit IPv6 address record. Most commonly used to map hostnames to an IP address of the host.

If you are making a comparison between Event ID 260 and the WireShark DNS request packet for the same event, you will note that the same fields are captured in the DNS payload when compared with the full Event Text (ex. PacketData, QNAME, DestinationIP, etc.).

There are also other sources for ETW to log other relevant events. From F-Secure Consulting in their labs note another ETW Provider, Microsoft-Windows-WebIO, which provides analysts with visibility of web requests made by some system processes.

About ETW / Windows DNS Service Provider

In brief, ETW has four main components which are:

Provider—a supplier of information to event tracing for windows sessions.
Session—a collection of in-memory buffers that accept events through the Windows ETW Provider API.
Controller—starts and stops the ETW sessions.
Consumer —receives events from ETW session from a log file.

ETW holds a valuable source of Windows telemetry. It is out of scope for this post, but you can learn more about the Windows DNS ETW in their documentation portal.

Windows DNS Server Debug

The following is an example test snippet from the Windows DNS Debug Log File. This type of logging should only be run in a temporary timeframe, due to its verbose nature which affects the performance of the server, amongst other potential issues. Logs must be parsed to extract the relevant metadata (such as the IP address or the protocol) as part of log collection. This sample has been added to show how raw logs on its own is definitely not ready for use and requires further enrichment to be usable.

10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A286DE90 UDP Rcv 172.31.21.66 16df Q [0001 D NOERROR] NS (0)
10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A34544B0 UDP Rcv 199.7.83.42 de78 R Q [0084 A NOERROR] NS (0)

DNS Server Shutdown Event Snippet in XML

The following is a snippet of Windows DNS Shutdown Event in XML View from the Windows Event Viewer. While this is structured data, you can see how it deviates from a data format that can be consumed in another system, such as a SIEM. An event source connector is needed such as a direct connector, an input module, or a log agent to normalize the XML formatted XML log.

<Provider Name="Microsoft-Windows-DNS-Server-Service" Guid="{71a551f5-c893-4849-886b-b5ec8502641e}" /> <TimeCreated SystemTime="2020-09-23T21:33:21.512036500Z" /> <Channel>DNS Server</Channel> <Computer>ec2-xx-xxx-xxx-xx.us-east-2.compute.amazonaws.com</Computer> <Security UserID="S-1-5-18" /> </System> <EventData Name="DNS_EVENT_SHUTDOWN" /> </Event>

Discussing log collection involving DNS is not complete until we also include audit logging on DNS infrastructure. Audit logging not only helps to meet auditing and compliance objectives, but it also provides the event data for defenders to help incident responders in obtaining more information about a DNS infrastructure attack. Logging the server also serves the need for any other operational and troubleshooting issues involving the infrastructure.

These event sources include:

Windows Enhanced DNS server auditing events (Windows-DNSServer/Audit channel—Windows DNS Logging and Diagnostics – Audits events page)
Windows DNS server analytic events (see the Windows DNS Logging and Diagnostics – Analytic events page)
Microsoft Active Directory (see AD Events to Monitor resource and Microsoft Audit Policy recommendations)
Microsoft DNS Windows Group Policy logging (see DNS Windows Group Policy settings associated with the DNS Client service)

Enhanced Windows DNS Event Logging Options

The source for these events includes the Microsoft-Windows-DNSServer/Audit EventLog channel, and the Event Tracing for Windows provider. The types of events that are covered in audit logging on the DNS server include:

Cache operations—Purging a cache.
DNSSEC operations—Key rollover events, export/import DNSSEC, trust point related events.
Policy operations—Events for the client subnet record, zone level policy, forwarding policy, client subnet record were created, deleted, or updated.
Server operations—Restarting server, clearing of debug logs, clearing of statistics, changes to listen events.
Resource record updates—Resource Record (RR) creation events such as deletion or that a record was modified.
Zone operations—The zone was deleted or updated, a zone scope was deleted or updated.

Final Questions

Note: One item that you may notice from the Source to SIEM diagram is that I included log sources that are not covered in this post—for example, the Exchange logs as well as logs from other collection processes. We will be covering these in the final post of this series in a bit more detail.

With this post, you have been introduced to a sample Windows log collection deployment, the types of events that can be collected on Windows DNS server and client, and the types of logs. Feel free to go back to the beginning and check whether your deployment has covered the following:

What monitoring information on DNS and domain activity can be obtained from your existing sources?
Which areas need to be expanded in order to improve your logging visibility, in particular for metadata containing domain and DNS logs?
What other opportunities are there to increase your log collection scope overall?
Which of these sources lead to better intelligence for your own use cases?
Is your current log deployment meeting your final phase needs in terms of intel for threat hunting, incidence response, orchestration, automation, etc.

While it is out of the scope to dive deep into actual deployment details (such as configuration samples, or instructions on how to enable audit logging), you can check the Microsoft documentation as well as your own log agent and SIEM documentation to see what configurations need to be applied and what options are available.

Use DomainTools integrations and APIs to further enrich relevant events with DNS and domain intelligence—Domain Risk Score—as well as use domain IOCs with the Iris platform. Use DomainTools as part of your proactive and reactive defense, in addition to targeted logging.

Learn More