We would like to introduce an additional method of security monitoring: capturing all DNS requests that are made within your network. This post will be the first of a two part series that covers the collection and analyzation of DNS requests. Our second post will focus on automatically flagging bad actors by integrating threat intelligence databases with Graylog.
Let’s dive in!
Why monitor DNS requests?
If a computer is infected, in most cases, the malware or attacker will do one of three things: try to load more code, open a backchannel to exfiltrate data, or wait for further instructions. Typically, the attacker will be using a domain name instead of a hard-coded IP because it offers more flexibility. To our advantage, this will result in a DNS lookup that can be easily spotted.
Another benefit of using this technique is that we can spot attacks instantaneously. For example, a user that clicks on a phishing link will be caught the moment the browser performs the DNS lookup to open the “fake” website. The same happens when infected machines try to call their command and control hosts.
How to capture the data?
The classic approach to collect all DNS requests is to write all requests the DNS servers receive to a log file and then to transfer those logs into Graylog. However, there are at least 3 issues with this approach:
A new approach is to simply listen for all DNS requests that go through your cables. By listening to the wire data that goes to your DNS servers and that leaves your networks to the internet, you will be able to spot every DNS request. A span port or network tap will allow you to detect all DNS requests, regardless of final location or logged format.
An architecture using this approach is demonstrated below:
We’ll be using Packetbeat to listen to all wire traffic with destination_port:53 and the default DNS packet decoder to parse important information out of the raw traffic.
Configuring Packetbeat
This tiny Packetbeat configuration file is all you need:
interfaces:
device: any
protocols:
dns:
ports: [53]
include authorities: true
include additionals: true
output:
logstash:
hosts: [“graylog.example.org:15999”]
It instructs Packetbeat to …
Lastly, we need to instruct Graylog to receive and parse the messages from Packetbeat.
Configuring Graylog
First, install the Graylog Beats input plugin and start a Beats Input on the port you configured in your Packetbeat configuration.
You should see messages coming in immediately after starting the input if Packetbeat is already configured and running.
You will notice that the messages have several standard fields, most of which we will not need.
Let’s build a Processing Pipeline rule to remove all the unneeded clutter and to format the messages nicer:
rule “rewrite raw packetbeat DNS logs”
when
has
name);remove
ip);
remove
setfield(“dstaddr”, $message.packetbeatip);
remove
field(“packetbeat_ip”);
setfield(“dnsflagsauthoritative”, tobool($message.packetbeatdnsflagsauthoritative));
remove
field(“packetbeatdnsflags_authoritative”);
setfield(“dnsflagsrecursionallowed”, tobool($message.packetbeatdnsflagsrecursionallowed));
remove
field(“packetbeatdnsflagsrecursionallowed”);
setfield(“dnsflagsrecursiondesired”, tobool($message.packetbeatdnsflagsrecursiondesired));
remove
field(“packetbeatdnsflagsrecursiondesired”);
setfield(“dnsflagstruncatedresponse”, tobool($message.packetbeatdnsflagstruncatedresponse));
remove
field(“packetbeatdnsflagstruncatedresponse”);
code);
remove
class);
remove
type);
remove
code);
remove
port));
remove
setfield(“srcport”, tolong($message.packetbeatclientport));
remove
field(“packetbeatclientport”);// Remove fields we don’t need or want.
remove
in”);
remove
authorities”);
remove
count”);
remove
answers”);
remove
direction”);
remove
responsetime”);
remove
error”);
remove
transport”);
remove
method”);
remove
resource”);
remove
status”);
remove
type”);
remove
query”);
remove
disabled”);
remove
additionals”);
remove_field(“facility”);// Remove trailing . if there is one
let fix = regex(“(.+?).?$”, to
question));
set
string($message.dns_question)));end
Now that you have every DNS request coming into Graylog, let’s look at real-world analysis use-cases.
Analyzing the captured data
Let’s assume you want to see which DNS servers are being used in your network. Most likely, you will want to make sure that only your internal servers are being used.
Start by searching for all DNS requests:
type:dns
Now run a quick values analysis on the dst_addr field to find all destination addresses of DNS requests (remember, we searched for type:dns)
As you can see, there have been 229 requests made to DNS servers not under our control. In this case, it is the public Google DNS servers, but we should still investigate and make sure that the machines that use those servers are re-configured.
To find out what machines were making those requests, we will need to run a new query:
type:dns AND (dst_addr:8.8.8.8 OR dst_addr:8.8.4.4)
Now run a quick values analysis on the src_addr field:
This is how fast you can get the result. The machine with the IP address 172.31.99.210 is using Google DNS servers instead of your own DNS servers for some requests.
Next steps could be:
This is only one example. Another useful thing is to just scroll through the actual hostnames that were resolved via DNS to see if there is anything suspicious going on. See the last paragraph of this post about automatic enrichment with threat intelligence data to automatically detect machines communicating with malware command and control systems.
Legal aspects
Note that you should first consult with HR or an attorney to make sure that you are not invading privacy by collecting DNS requests and that employment agreements allow this practice.
Next steps / Enriching the data
Due to its size, you can see that it will become difficult and time-consuming to manually sift through DNS data. To improve efficiency, you will want to implement an automatic enrichment that can mark requested domains as an indicator of compromise. Consider this, a Windows workstation is sending a DNS request for a known malware command & control host. If that request was automatically marked with threat_indicated:true, you could quickly filter through and be alerted of this incident.
So how do we automate this process?…
Our next blog post will look at integrating threat databases with Graylog to automatically flag DNS requests of domains that are known bad actors.
Subscribe to our newsletter or follow us on Twitter to be notified when it is released!As we continue our discussion on security monitoring, we find there are multiple ways to defend attackers on the outside network perimeters and to detect intruders that have landed inside your network. The combined force of virus scanners, firewalls, IDS systems, and a log management system is a great way to protect your network.
