Cybersecurity can be an exhausting job. Between the onslaught of ‘silver bullet’ tools that supposedly protect organizations, and the additional layer of tools needed just to make sense of the first group, even the smartest teams are finding themselves stretched thin. There are signals and control points on the network today that are under utilized from the cyber perspective — instead of adding net new, leverage what you have today.
Adversaries take advantage of blind spots, by focusing on the exact places security teams haven’t gotten around to monitoring. One of those places is DNS.
Until recently, the protocol was relegated to the IT infrastructure team, and dismissed as mere network plumbing. Now, understanding of DNS as a threat vector is palpable. It’s the topic of concern for the DHS, government organizations, telecommunications companies, and much more.
- Data Protection Day: Spotlighting DNS for all the right reasons
- When redundancy is a good thing: Creating a resilient DNS framework
- 72% of FTSE 100 companies are at risk of being taken off the Internet – is your company too?
This was bound to happen, since some ninety percent of malware relies on DNS for exploitation. It’s used for remote command and control to malware, data exfiltration to the outside world, and so many more nefarious plays.
The good news? Logically, DNS can then be used as a source of truth and ground for defense. Below are just a few ways cybersecurity threats can pop up in your DNS logs.
Threat 1 - machines performing actions they never would normally
Example: Spambot malware like Emotet
Most purpose-built devices, like factory machines, point-of-sale (POS) machines, and printers, produce a fairly anticipatable pattern of DNS queries. Anything out of the ordinary coming from one of these devices likely means trouble, even if it looks benign. For example, if the DNS queries originating from a POS machine at your store are looking up Google.com, you have a problem.
Even broader-purpose devices develop particular behaviour patterns. For example, user laptops do not typically generate MX query types–mail servers do that. If a user laptop starts acting like a mail server, that’s a sign it may be sending spam as a result of infection.
Threat 2 - using DNS to transmit information, not just make a connection
Example: DNSMessenger trojan, DNSpionage, Pisloader Trojan, and any other tunneling-based threats
Tunneling works by encoding information into query names, which are then decoded by malicious recipient servers. There are a few key signs, from a DNS log perspective, that this behaviour is occuring.
Because encoding information often results in what looks like the jumbling together of a series of characters, query names tend to be missing actual dictionary words and look more like randomly-generated character strings. Tunneling queries are also typically TXT and other query type, which aren’t typically generated in the frequency and periodicity necessary for exploit by employees during typical computer use. Tunneling queries tend to be generated at either regular intervals, or in suspicious bursts. It is important to be able to attribute queries to their source to see regular and bursts patterns.
Threat 3 - dynamically changing where queries are sent to, algorithmically
Example: Nymain, Locky Ransomware, Qadars Banking Trojan, Qbot Trojan, and any other DGA based malware
Domain Generating Algorithms (DGAs) are an adversary’s workaround to blacklists. They create a series of domains which a firewall wouldn’t recognize to block, and try them.
That said, DGAs require an adversary to actually register some domains. To save on cost, adversaries tend to choose uncommon top level domains (TLDs) from registrars with poor reputations like .biz, .work, .hello, etc. Like tunneling queries, DGA queries will also look like non-dictionary words, and try those combinations across a number of TLDs. For example, asdf.biz, asdf.work, asdf.hello, etc.
Threat 4 - hidden DNS Queries
Example: DNS over HTTPS (DoH) execution
DoH is pitched as a private way for individuals to surf the web by encrypting DNS queries and bypassing the normal DNS server chain. When on a corporate network, resolving DoH is dangerous because it cuts visibility for security teams. All of a sudden, risky behavior becomes harder to detect.
Often, even resolving DoH requires at least one DNS query over the corporate network–that first one to cloudflare-dns.com, or whichever other DoH service there is. If that address is known, spotting which device ‘just went rogue’ becomes easier. Corporations are blocking we’ll known DoH servers.
Threat 5 - infrastructure hijacking
Because hijacking involves an adversary inserting themself into the DNS resolution chain and alter the information passing through, examining DNS logs for queries and their respective responses can be helpful. If the response to a query changes, now pointing a client where it typically shouldn’t be sent to, it could be a sign of hijacking. DNS query answers obviously change over time, but less often to an IP address on a completely unrelated network.
Listening to your DNS logs
DNS is already in every network. The question is, are security teams listening to what it’s telling them?
A world of forensic insight opens up when organizations leverage their logs for protection. While there are tools to help act on all that data in a smarter way, there are basic steps that can be taken by any security team, even today.
For example, it’s best to limit queries on a network for uncommon domain types, like .biz, .work, etc, as they’re typically used by DGAs. Take notice when purpose-built devices attempt to do something atypical, and pay special attention to queries that look randomly generated (especially when they come in bursts or regular time intervals). Finally, keep visibility over your network by preventing employee resolution of DNS over HTTPS, which often still requires at least one DNS query, in order to keep valuable query data on your turf.
Andrew Wertkin, CTO at BlueCat
- We've also highlighted the best free and public DNS servers
