DNS is an unsung hero among protocols during a network investigation. It’s almost universally used by other protocols such as HTTP, SMTP, and the like. It’s also a plaintext protocol, which can benefit an incident responder who cannot otherwise examine the contents of an encrypted connection. However, passive DNS monitoring (also known as DNS logging) is still somewhat rare in most environments. Adding a standalone means of logging DNS activity can be a relatively simple and inexpensive process. Red Canary also uses DNS activity records collected by the Carbon Black platform to aid in our threat detection service.
What Is Passive DNS Monitoring / DNS Logging?
Put simply, passive DNS monitoring is a method by which a traffic monitoring station examines the contents of DNS queries and responses, then logs that information in a standardized format to text files or other long-term storage mechanisms. The data points logged vary based on the software used. However, given the example query-and-response exchange below, most passive DNS logging software would record some common key points such as those listed below the graphic.
Why Is Passive DNS Monitoring Important in DFIR?
These data points would be of extreme value during an incident response investigation. The hostname/IP address associations can help characterize NetFlow observations, which have no layer 7 context. Additionally, the server’s IP address can be useful in identifying clients that make direct requests to servers outside the environment. Such behavior might indicate a misconfigured resource, a platform with a hard-coded DNS server IP address, or a rogue actor that is ignoring internal DNS server directives assigned by DHCP or a domain hierarchy. When observing the DNS responses over time for a known Command and Control IP hostname, a skilled investigator can observe the different phases of an attacker’s campaign based on when the C2 IP addresses change from one region to another, or go from null-routed to operational IPs.
Passive DNS Monitoring for Threat Intelligence
Perhaps the clearest use of such DNS log evidence would be to support findings that incorporate threat intelligence. The use cases here are numerous, but examples include flagging heavy query activity for newly-registered-domains or identifying a newly-observed domain from a list of the top 5,000 typically queried within your environment. Further, maintaining such logs for an appropriately long period of time can quickly aid an investigator to find the earliest evidence of compromise after a domain or domain-generation algorithm is identified as malicious or suspect. Again, since DNS activity is present in nearly any communication exchange, regardless of the eventual protocol, the baselines established from DNS observations can be almost universally valuable.
Four Approaches to Creating DNS Log Evidence
1: Use the DNS Server for DNS Logging
The DNS server itself may provide a means of logging such data. However, this functionality is often limited to queries only, which omits the critical fields present in the responses. Additionally, impact to the server is a concern raised by many administrators, so load testing is important before operational employment.
2: Deploy Passive DNS Monitoring Software
Another option is to deploy passive DNS monitoring software, which can be installed on the DNS server or onto a separate system that observes the DNS traffic through a network tap. Options for this observation model include the venerable BRO IDS, the tiny-footprint PassiveDNS project, and many others. Some infrastructure devices such as Palo Alto firewalls can perform such a function during the normal course of their operation as well.
3: Outsource DNS Service
Larger organizations might use an outsourced DNS service such as OpenDNS (now part of Cisco). These services may provide some of the reporting an investigator would find useful for baselining and anomaly detection, but might not provide per-query/response fidelity. As with any potential, pre-collected source of evidence, it’s critical to evaluate its usefulness before an incident is underway. Users of these services should also be wary of any NAT actions that are being performed on their perimeter, as that may lose per-client awareness in the hosted service’s reporting.
4: Collect Network Activity on Endpoints
A final option is to collect network activity on each endpoint, then aggregate to a central location for analysis. This is the model Red Canary leverages, through our use of the Carbon Black sensor/collector platform. The endpoint sensor logs network connection metadata, including the destination IP address and requested hostname. This differs from native DNS logging in that it does not reveal blocked or failed requests, nor other context specific to the DNS protocol. However, it does provide valuable context related to the process that initiated the connection.
Red Canary also uses a number of intel feeds in our process – to include Farsight’s most excellent Farsight’s Newly-Observed Domains (NOD) list, which we apply against all observed domain resolution activity. This immediate and universal intel application allows our analysts to quickly characterize a domain alongside the other behaviors for each binary execution event. This intelligence layer is included for all Red Canary customers – so they get the benefit of Farsight’s NOD against every single one of their endpoints from the moment Red Canary is operating in their environment.
Another Tip: Improve Your Incident Response with Autonomous System Numbers
If you’re not already collecting passive DNS log evidence in your environment, there are a lot of options at various price points and deployment scales. If you’re already collecting DNS queries and responses, congratulations! We’d love to hear what use cases you’ve found for this valuable data store. However, whether you choose raw, low-level collection or continuous semi-automated analysis to your incident response process, you’ll certainly see the immediate value it has to your information security posture.
*Editor’s Note: A previous version of this article incorrectly stated that Red Canary uses Carbon Black to collect the DNS activity on each endpoint. We use Carbon Black to record network connections, which are an alternative to DNS logging. Thanks to our astute readers for the correction.
Related Articles
The CrowdStrike outage: Detection and defense in depth