Introduction
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:
- DNS and Domain Logging: A Bird’s Eye View
- How Targeted Log Collection Strengthens Your Client and Network Defenses
- Maximizing Your Defense with Windows DNS Logging
- Increase the Visibility of Your Linux DNS Servers with Log Collection
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.
Challenges
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:
- 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.
- 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:
- https://github.com/Azure/Azure-Sentinel/tree/master/Detections/DnsEvents
- https://github.com/Neo23x0/sigma/tree/master/rules
- SOC Prime Threat Detection Marketplace (closed, registration only, with Community subscription option). TDM contains a number of rule detections as/for Sigma, Elastic, Azure Sentinel, CrowdStrike, Splunk, QRadar, PowerShell, Regex, RSA NetWitness, ArcSight, Carbon Black, Sysmon, and many more.
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.
