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 your 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 “22.214.171.124.” 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 126.96.36.199, the Quad 9 DNS services. Then, when the campaign is launched, the resolution is changed to an attacker-controlled host (188.8.131.52, 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 Systems Consortium launched a data-sharing initiative to establish a standardized output format for passive DNS.
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.
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.