The Domain Name System (DNS) is one of the key foundations of the internet. The DNS acts as a sort of phone book by translating user-friendly names like “Google.com” into numeric IP addresses that computers use to move packets of data over a network.
The phone book of the internet isn’t stale, though — it changes frequently. You can track these changes with a process called passive DNS replication. By understanding the significance of changes in the identity of the systems that communicate with your network, you can more capably build a timeline of events when you enact your incident response plan.
What Is DNS Logging?
A DNS log is one of many data sources through which you can detect security incidents and start your incident response plan. DNS log monitoring can be done in two ways: by looking at the content of the logs and checking for malicious activity, or by analyzing anomalies in the volumes, frequency, and types of requests and responses.
There are essentially two types of DNS logs concerning client behavior:
- Request logs, which record which system requested the resolution of which name in a given time frame.
- Response logs, which track which numeric IP address the requested name resolved to at a particular time.
Knowing when, where, how and by whose request each event in the DNS log occurred is crucial when building timelines. This also means that a time field is essential. That’s where passive DNS replication comes in.
How Does Passive DNS Work?
Passive DNS replication can happen in several ways. You can run a passive sensor that sniffs the DNS traffic and records the answers. Or, you can attach it as a module to an existing network monitor service, use it as a plugin with a name server or extract the data from stored network captures.
The data compiled by DNS replication gives you a historical overview of DNS responses, showing exactly where a certain domain led in the past. The technique was invented in 2004 to reconstruct a partial view of the data available in the global DNS into a central database where it can be indexed and queried.
It’s important to note that it is not necessary to register client IP addresses when storing the replication data, so it’s very effective at protecting the privacy of individual users.
When to Use DNS Data
Consider that you are investigating a compromised machine and you’ve been handed its DNS request and response logs. You have a rough idea of when the infection took place, which was well before the initial steps of the investigation were started.
The DNS logs show that during the suspected time frame, the machine completed multiple queries for a single domain. This is most likely the domain used by the malware.
You can use this data to extract additional information by looking at the intrusion detection logs. You can also track other infected machines. It’s important to note, however, that in this example, the intrusion detection system (IDS) doesn’t resolve domains; it only stores IP addresses of the captured events.
When you resolve the domain during the investigation, you get the response “8.8.8.8.” This IP address corresponds with one of Google’s public DNS servers. It’s highly unlikely that an attacker used these servers to further host malware. In this case, without additional logs or data, it’s very difficult to know to which IP address the malicious domain pointed during the time of the infection.
From an attacker’s point of view, these changes in domain resolution are put to use by registering a domain and first having it point to something less suspicious.
During the dormant phase (before the malware campaign is launched) in the schema above, the domain points to 9.9.9.9, the Quad 9 DNS services. Then, when the campaign is launched, the resolution is changed to an attacker-controlled host (1.1.1.1, for example). This is the operation phase. Notice that the time to live (TTL) value can influence the success of the campaign. A TTL instructs the client how long to cache a given result. If the TTL is set too high, it’s possible not all infected clients will get the “new” information.
Once the campaign is completed, the attacker can abandon the domain and have it point to nonrelated infrastructure. Without passive DNS replication data, there would be no record of that activity. But, if DNS traffic and IP address information has been tracked, you can follow the attacker’s crumbs back the source.
Unifying Passive DNS Methods
There are many implementations of passive DNS software that all have their own, custom output format. Having different schema can make standardization and automation very difficult, especially if you need to exchange that information across networks. To mitigate this, the Internet Engineering Task Force (IETF) published a document describing a common output format for passive DNS.
Build Your Own
Your own internal data is a treasure chest of information that can be used to detect security incidents or supplement ongoing investigations. If you want to consume passive DNS, you can start with the queries done in your network. There are a number of open source and commercially available solutions that can help you with this, such as Zeek and passivedns-client.
Bro (Zeek)
The Zeek network security monitor, formerly known as Bro, is an open source software framework for analyzing network traffic. Zeek can be extended with plugins, such as Passive DNS for Bro, which uses the Bro DNS logs to build a database of unique query+type+answer tuples. You only need the Go compiler to build the component and a postgresql database to store the data. Once set up, run it regularly to index the DNS logs and update the database.
You can then use standard SQL commands to search for historical information (there is also an HTTP API interface). An example referring to the use case above could consist of:
CODE pdns=# select query, answer, first, last from dns where query='malwarec2.cc.aoo'; query | answer | first | last ------------------+---------------+---------------+------------ malwarec2.cc.aoo | 9.9.9.9 | 2016-10-05 .. | 2017-08-25 .. malwarec2.cc.aoo | 1.1.1.1 | 2017-08-25 .. | 2017-08-27 .. malwarec2.cc.aoo | 8.8.8.8 | 2017-08-27 .. | 2017-12-10 ..
When deploying DNS monitoring:
- Make sure all clients use the same internal DNS server and prevent the use of other, nonapproved, DNS-servers by filtering outgoing DNS requests;
- Monitor your internal DNS servers as closely as possible;
- Do not forget to include the DNS requests from your servers; and
- Be aware that certain virtual private network (VPN) implementations might tunnel DNS traffic over the VPN; you’ll only see the VPN traffic, not the DNS traffic.
In some situations, it is impossible to conduct a live inspection of the traffic. Instead, do a packet capture on the most important network exits or routing points, record the DNS-related traffic, and then read the PCAP files with Bro and do the analysis.
passivedns-client
Whereas the Bro module generates the records (server), the passivedns-client allows you to query for results from a multitude of sources. As the name implies, this is the client part of a setup. It is a Ruby application that allows you to query:
- BFK.de;
- CIRCL;
- DNSDB (FarSight);
- Mnemonic;
- PassiveDNS.cn (Qihoo 360 Technology Co., Ltd);
- PassiveTotal; and
- VirusTotal.
An application programming interface (API) key is required to access VirusTotal and PassiveTotal, for example, whereas accessing the service of CIRCL requires that you contact them first. The client can export to CSV, XML, JSON or YAML format.
Use Ready-Made Solutions
The following open source and commercially available solutions can also deliver access to historical DNS resolution data.
PassiveTotal
One of the primary data sets of PassiveTotal gives access to historical DNS resolutions. The set is built from various sensors located around the globe, producing an extensive picture of historical resolutions. The additional pivot possibilities within PassiveTotal make it very useful for computer security investigations.
PassiveTotal partners with other sources, such as as Kaspersky, Alienvault, Virustotal and CIRCL.lu, to enrich the data. And you are not limited to the web interface; you can also get access via your own tools through the API.
VirusTotal
Similar to PassiveTotal, VirusTotal provides an extensive set of historical DNS resolutions. This data set is also integrated with other pivot information as connected malware samples and malicious files downloaded from a domain. You can access the VirusTotal database via the web interface, but you can also integrate it with your own tools via the API.
DNSDB
DNS Database (DNSDB) is a database that stores and indexes both the data available via Farsight Security’s Security Information Exchange and authoritative DNS data that various zone operators make available. Whereas access to PassiveTotal and VirusTotal is free (at least for a restricted set of queries), DNSDB is only accessible to authorized users.
Improving Incident Response and Threat Intelligence
There are a few scenarios in which you might implement passive DNS information in both your incident response plan and your threat intelligence processes.
For instance, a resolution information alert can flag IPs associated with domains that are outside of your organization’s control or that belong to well-known malicious network blocks. You can enrich recorded domains with the date on which they were registered; an increase in requests for newly registered domains could indicate a malware outbreak.
Ultimately, the more data you have at your disposal, and the more meaningful context within which you are able to analyze it, the more efficiently you should be able to detect anomalies and build defenses for known threats or respond to active breaches. Such enriched knowledge is invaluable to every aspect of your security program.
The post How to Use Passive DNS to Inform Your Incident Response appeared first on Security Intelligence.
