useful sources of domain and dns logging


This final post is about other log sources for DNS and domain logs that are not otherwise covered in the previous two posts. This post then ends with a note of challenges to anticipate as well as ideas for the next steps beyond logging.

If you have not done so already, have a look at the previous posts in this series:

Other Sources of Relevant Log Data

There are additional event log sources that contain valuable metadata. From IDS/IPS tools to firewall and mail exchange logs, use the metadata to extract IP addresses, hostnames, and other metadata to further inform IR and threat hunting work. IP addresses can be used to trace back and investigate infrastructure, or use the data to conduct a reverse IP to hostname check to pivot towards associated domains and find the Threat Profile and Risk Score. The first half of this section covers other sources briefly and provides in-depth examples in the final half.

Managed DNS Providers

Amazon Route 53 DNS Query Logging and CloudWatch

Configure Amazon Route 53 to log information about the public DNS queries that Route 53 receives (see the Developer Guide here). The available metadata is similar to other sources of DNS query logging: Domain or subdomain that was requested, date and timestamp, DNS record type, DNS response code, and the Route 53 edge location that responded to the DNS query. If you use Amazon CloudWatch Logs to monitor, store, and access the DNS query log files, you can also stream these logs to your LM and SIEM instance.

Google Cloud DNS

Google Cloud DNS logging tracks queries that name servers resolve for VPC (Virtual Private Cloud) networks. 

Other managed DNS providers are available, check their documentation to see how to set up query and response logging.

Proxy Server Logs 

Proxy server logs are a common source of information for domain metadata. These logs contain requests that are made within the network from both users and applications. 

DNS Packet Logs

In addition to capturing and listening to packets on network analysis tools, it is also possible to set up packet logging and configure it to only collect packet logs of certain protocols such as DNS packets. However, packet capture and packet logging only provide the DNS-related metadata. It is not possible, for example, to obtain more details about the host in which this event had originated, or which specific user or user action triggered that event.

Logs Generated from IDS/IPS Tools

Logs generated from IDS/IPS tools, such as rules and alerts, can be collected and forwarded on to your LM/SIEM. Examples are:

  • Zeek (formerly Bro) DNS Query and Response logging to collect and obtain DNS query and responses. Also used in conjunction with Domain Hotlist
  • Snort DNS rules that inspect DNS query responses and take action based on the response back. 
  • Suricata DNS rules to log and collect related events, create event-based actions such as matching DNS queries to a blocklist (ie, Domain Hotlist), or writing log events to collect DNS query and response logging.

Mail Exchange Server Events

There are a few use cases to leverage logs generated by your mail exchange server:

  • Detect known phishing/spam email infrastructure.
    • Sent by known phishing or bad infrastructure.
    • Example: “Call me at 1-888-382-1222 to set up your VPN – Matthew (from Tech Support).
  • Detect known phishing/spam links in the email body.
    • Contains phishing links, but a user action has been performed based on subsequent event logs (ie user clicks on the link, the domain that is queried appears in the logs).
    • Example: “Click here to download your VPN cert – Matthew (from Tech Support).
  • Further investigate yet-unknown phishing indications.

Event Sources for Exchange logs:

  • MSExchange Management channel on EventLog (called “MSExchange Management”)
  • Message Tracking Logs, where the default location is at %ExchangeInstallPath%TransportRolesLogsMessageTracking

The MSExchange Message tracking log has fields that are populated with metadata for threat hunting and DomainTools investigations. They include:

  • client-ip: The IP of messaging server/client that submitted the message.
  • client-hostname: The hostname/FQDN of the messaging server/client that submitted the message.
  • server-ip: The IP of the source or destination server.
  • server-hostname: The hostname/FQDN of the destination server.
  • A source value field includes DNS as a known source.

The client IP and client hostname answer the questions of “which infrastructure sent this message,” which the analyst uses to seek out more information about the infrastructure. 

The server IP and server hostname is the target address. This answers the question of “to whom was this message aimed at.” 

Proactive Defense Note: Use DomainTools API products or the Iris investigation platform to further investigate the metadata captures in these fields. An example working with Iris:

  • Hostnames are extracted from the client-hostname field out of MSExchange logs.
  • The domains are extracted with the subsequent domain list then imported into Iris.
  • The Domain Risk Score associated with each domain indicates the risk level for that domain.
  • Further decisions:
    • Correlate between the client-hostname and the server IP.
    • Isolate that target server IP, or even set up more logging to find other IOCs (EventIDs and other events that could be generated to indicate further compromise or lateral movements).
  • Add to blocklist, in addition to using Domain Hotlist

Windows Firewall Logging

Other sources of log data holding valuable IP data include firewall logs from the Windows Firewall EventLog Channel. 

Proactive Defense Note: Use the Domain Hotlist as a blocklist on the firewall network perimeter. 

Finding Advanced Attacks and Malware With Only 6 Windows  EventID’s” by Michael Gough (aka Malware Archaeologist) provides additional information of the lifecycle of these EventIDs that signal an attack. Event ID 5156 is fired when the Windows Filtering Platform allows a program to connect to another process (on the same or a remote computer) on a TCP or UDP port. The valuable metadata of this event source indicates the command and control or origin of the attack and what application was used to communicate with the external or internal IP address. 

Proactive Defense Note: Use DomainTools Iris Investigate API, Classic Tools APIs, or the Iris investigation platform to further investigate this IP. Results include – finding IP infrastructure information, revealing connected infrastructure, finding connections of this IP address, reverse lookup of the IP address.

Windows IIS Server Logging

<13>Sep 9 17:38:25 IIS-SERVER 2020-09-09 17:38:25 MALICIOUS_CLIENT_IP_HERE GET /welcome.png - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:69.0)+Gecko/20100101+Firefox/69.0 http://localhost/ 200 0 0 11

The above example features a Syslog-formatted log event generated by a locally-hosted (test) IIS server.

For example, if there is an unusual number of requests from a client IP (indicated by MALICIOUS_CLIENT_IP_HERE), an analyst may want to verify if the associated IP is malicious.

Proactive Defense Note: Conduct a reverse DNS check (aka conduct a check to find the associated hostname/s to a client IP). From the reverse DNS check (to find the hostname), check the infrastructure or associated Risk Score or Threat Profile either on Iris or with the API.


Increasing SIEM and LM Storage Requirements and Costs

Related to infrastructure issues are your storage and licensing challenges as the capacity may need to be increased due to the additional logging requirements. However, there are solutions to workaround these. They include targeted logging (selectively only collecting certain EventIDs, or logging channels), deduplicating logs, dropping unnecessary metadata fields of a log event, batch compression logging, and more.

Other related costs that may also increase include:

  1. Subscription cost. These are instances where the log agent or the LM/SIEM incorporate data ingestion-centered subscription costs. There may be users or customers that are using Community Edition or free agents that have event ingestion limitations.
  2. Personnel cost. Administrators or other specialized personnel may be required to deploy on instances or deployment scenarios that require agent-based logging. Certain endpoints also require additional work, for example, an endpoint that requires additional settings to be configured to deploy logging.

Logging-Related Infrastructure Issues

It is problematic to log queries and/or requests due to issues such as server performance degradation (with the additional processing work required), storage issues, and more. In terms of processing-related issues, each time a query or a response event occurs, the DNS server will not only interpret the telemetry event as a log source to collect, but it also needs to write the events to a log file (in a format that is specified) and then send to an external destination. There are also additional parsing, or other enrichment, required that may provide more performance-related impositions over the resource. 

Logs Need to be Structured and Normalized

Event logs need to be ingested by the SIEM suite, which has its own SIEM fields and schemas. Additional specialist modules and add-ons may be required (in addition to what is offered by the log collection agent) in order to properly ingest and enrich the logs. For example, the Message field in the Windows Event Log may have valuable information about the event itself, which needs to be extracted. Linux DNS logs can be written in a number of formats, which also need to be normalized for ingestion into a SIEM. This normalization process can add an additional performance burden.

The Next Steps… 

…is to build the configurations to collect, parse and enrich events from these sources.

While it is out of the scope of this post to cover the maze of setting out event source configurations for the myriad of available platforms, it is worthwhile to reiterate a few ways to leverage these. 

Craft Sigma and Other Detection Rules

There are Sigma rules available that have already been crafted for scenarios such as detecting C2 servers or detecting a high number of queries to a single domain. Sigma rules drive consistency in threat detections, after a Sigma rule is crafted, it is then shared (or converted) so that whichever endpoints that need to consume the rule, such as a particular SIEM platform, can do so.

Other resources for detection rules are also available. There are other detection rules that are crafted and shared online so below is a small list:

Develop with DomainTools API Products

Effective event source coverage will mean that investigators will be able to make the most of and take advantage of what DomainTools integrations have to offer. For example, go beyond relying on proxy logs when you can also extract valuable domain and other metadata in other event sources. In addition, DomainTools API products can be used to develop your own integrations. Get started with the API documentation here including no-charge sample queries.

Use DomainTools Integrations with your SIEM

In addition to APIs, use DomainTools integrations to find threat intelligence in your domain metadata.