Most of us know how the Domain Name System (DNS) is a critical piece of our network infrastructure and have at least one tool to keep DNS requests current and clear of potential abuses.

Previous blog posts here concerning DNS and malware have focused on how malware can introduce errors in BIND, the most prominent DNS software, and cause it to crash. Others have outlined how to find evidence of infections across your network by tracking malware to particular domains.

Sometimes a little common sense and knowledge of your system log files and the DNS requests contained therein can go a long way toward understanding when your enterprise network infrastructure has been breached. This is one such tale, care of the security researchers behind this post on Cisco’s Talos blog.

Inbound Versus Outbound Traffic

Let’s start with the moral of the story first, because then you will understand the context. Most IT managers are interested in inbound, rather than outbound, traffic, for good reasons. Inbound traffic can contain exploits, infections or indications of potential compromise. But you also need to look at what is leaving your network, because that traffic can contain potential issues.

This was the case with Wekby, an exploit discovered earlier this year that used the outbound DNS traffic to communicate with its command and control server. Other malware products are “exfiltrating data by using DNS tunneling tools to encode data and utilize outbound port 53 traffic to fly under the radar of many filtering tools,” Dark Reading reported.

Making Mental Models

Because you probably don’t monitor outbound traffic on this port, the aim of this post is to give you a reason to start looking and an understanding of what normal outbound DNS requests look like. That way, when you actually find something else, you will be able to act on it.

You can use any feature of DNS requests, such as the length of the domain name or the number of subdomains, to construct models of your network’s expected behavior, through which you can observe more closely.

You don’t need a fancy tool or some other expensive piece of networking gear to do this. You do need to first understand your own mental model of your network traffic so that you are in the right mindset when you come across something that isn’t quite right or that doesn’t fit this model. As the Talos researchers said, “We compare our expectations of normality with our observations, if the two don’t match we want to know why.”

Abnormal DNS Requests

So what would be an example of an abnormal DNS request? How about seeing hundreds of subdomains, or the case of very long (100-plus characters) subdomain names? Both could be an indication that something is amiss.

The researchers calculate the frequency of the number of characters in subdomain names and found that most contain just a few letters (like “www” or “server1”) and, in most cases, much fewer than ten letters in the name. So when you come across these extra long subdomains, you can immediately focus your attention on them and check them out.

Another clue: Some of these extra long subdomains are only accessed a single time. Again, this is suspicious. What is actually happening is that the malware is using the subdomain name to encode data that it is trying to send to its command-and-control server. There isn’t any actual host with that name, which is why it is accessed only once.

Get Smarter

Granted, just because a subdomain name is long doesn’t necessarily mean it is being run by a bad actor. But you should get smarter about finding the fingerprints from these attacks and start monitoring your DNS logs. As you can see, it is easy to use some simple techniques to make sure that an attacker hasn’t broken into your network.