Threat Hunting Concepts & Trigger Points: DNS Anomalies

As part of our Threat Hunting series, we aim to demystify Domain Name System (DNS) Anomalies, explore the benefits, reduce ambiguity, and provide the insights.

So, What Exactly is Threat Hunting?

Threat hunting is a collective term used to describe activities, usually performed by security analysts, to proactively search out anomalies that lead to a positive detection of a malicious actor. These techniques are distinct from automated alert-driven detection, in that they are part of normal Security Operations Centre (SOC) operations, and almost always use machine analytics tooling, such as Security Information and Events Management (SIEM) or Endpoint Detection and Response (EDR).

Moreover, threat hunting requires a structured and strategic approach. Both in terms of the data/queries that are searched for, and in terms of the regularity of the task. In other words, it should not be an ad-hoc activity, performed randomly, infrequently or without a determined goal.

‘Good threat intelligence will include technical, tactical and strategic intelligence that provides leadership with finished information to facilitate decision-making and mitigate risk.’ – Cyber Defence Magazine

A successful hunting process should be operationalised. And queries should be progressively transformed into automated detection, to allow analysts to improve and add complexity to the hunting concepts over time.

How Does Threat Hunting Work?

The hunting procedure starts with a hypothesis which is presented as an expected event or series of events that are likely to be present under specific compromise scenarios. In an ideal world, the best hypothesis will consider elements such as the environmental conditions, including your expected user activity, applications used, network traffic, the inbound and outbound flow, running processes and the topology of the network.

Through our explorations, you will find that there are many different types of hunting techniques, that cover a spectrum of data sources.

But today we start by looking at the following hypothesis: Adversaries will communicate using DNS to avoid detection by blending in with existing traffic.

It’s not rocket science, if the DNS is set up correctly, it is easy to record rogue communication, or data exfiltration, over DNS channels.

Almost all APT threat actor groups have demonstrated indicators relating to the use of DNS as a covert channel. So, this is a good place to start hunting. And begs the question of what query concepts are out there?

1. DNS Should Not Query Unusual Destinations

Best practice dictates that all traffic should be directed towards your configured DNS Service provider (e.g. Cloudflare, Cisco Umbrella) or your Internet Service Provider. In a perfect scenario, searching for outbound traffic over Port 53 will, at best, yield misconfigured systems. Or, at worse, potentially malicious traffic.

2. DNS Traffic Should not be Bypassing your DNS Forwarding Servers

Traffic is expected to be forwarded to your Internet Service Provider (ISP) or DNS Service Provider, from internal hosts, via a DNS forwarding server. On you firewall, expect the source for the outbound DNS to be the IP for your forwarding server. If other hosts are detected, be proactive and investigate further!

‘Proactive. Hunting is about looking for an intruder before any alerts are generated. Proactive in this context refers to taking action before the intrusion alerts, not before intrusions occur.’ – Gartner

3. DNS Queries Should not use Multiple Subdomains

Whilst not a new tactic, this was made famous by APT32, which uses Cobalt Strike’s C2 functionality to blend with network traffic. It sneakily camouflages with the groups backdoor exfiltrated data. How does it do this? Well, by encoding it in the subdomain field of DNS packets. Since DNS queries do not normally use subdomains (there are exceptions, such as content delivery networks) simply craft your queries as an expression which identifies a high number of dots.

For instance:

L72.8572Y8.AA.KLMXHRO.Y8ZW19283OLPDL20PPLPOLK.PLEC.ipad.client

These 7 dots, sprinkled throughout this expression, can be detected with a simple query.

4. An Easier one to Spot is the Domain Length, which Should not be Excessive

If an adversary is going to use DNS for exfiltration, then the process may involve dissecting data for transit and reconstructing the data on receipt. Thus, the length of the Quality Network Solutions (QNS) query is likely to be excessive. Therefore, monitoring the length of a DNS query is crucial, as the longer the payload, the greater the risk of malicious activity.

The previous example of 62 characters appears to be a long query. But when you consider that DNS queries can be up to 253 characters in length, 62 is relatively small.

Your query should be a select statement, which takes the top 100 or so queries by payload length, and then works backwards.

By combining both the character length and sub domain concepts, each subdomain length may be 63 characters in length. If a query is maximising this parameter and has multiple sub domains, it is likely to be malicious.

5. Ideally, DNS Queries Should not Include a Mix of Upper/Lowercases

For your delight, see the below example of a base 64 encoding.

(Image sourced: James Condon)

6. DNS Queries Should not Include Alphanumeric Characters

Regular DNS queries are expected to contain only numbers, roman alphabetical letters, dots and hyphens. Not unlike the example of mixed case lettering, non-alpha numeric strings may indicate base 64 encoded strings. Which would be an unusual event.

Domain registrars allow for non-English (ASCII) characters in domain names. And are defined by the Internationalized Domain Names such as an Input Distribution Network (IDN) for Applications framework. The purpose is to allow countries to customise services with their own alphabets.

Punycode is a representation of Unicode characters into ASCII. This is used for hostnames, which allows for IDNs. While DNS lookups can still be performed using ASCII characters, the threat actor groups may use characters that reflect the actor origins. For instance, Cyrillic characters (mostly found in Eastern European countries), Iranian, Chinese, or other regions.

The table below, from Wandera, highlights a selection of real-life examples of Punycode attacks in big brands. Attacks which, according to Wandera, have seen a 250% increase in the last 12 months.

Brand	What the user sees	The Punycode
Adidas		http://xn--addas-o4a.de/
Aerlingus		xn--aerlngus-j80d.com
Aerlingus		xn--aelingus-of0d.com
Air France		xn--airfrnce-rx0d.com
British Airways		xn--britishairays-541g.com
British Airways		xn--britishirways-of2g.com
Google		xn--googe-95a.com

7. Allowed Traffic on Port 53 Inbound Transition Control Protocol (TCP)

This port is used for zone transfer and should only be allowed between primary and secondary DNS servers. This requires normalisation of those DNS servers. Exceptions to those IP’s should be used as a trigger point for investigation.

8. Outbound Traffic, Other than 53 and 123, Should not be User Datagram Protocol (UDP)

Genuine services often rely on TCP. So, if any outbound communication is made to any port on the UDP, this should be a trigger point for investigation.

9. Lookout for Fast Flux DNS

DNS fluxing is a technique used by attackers to hide an actual phishing or malware domain behind constantly changing compromised hosts (IP) which are acting like proxies. To accomplish this, the Time to Live (TTL) for DNS is set very low (close to 5 min) so that the changes made in DNS will reflect quickly over the internet. Because it is constantly changing, this makes it hard to identify, and take down, the actual source.

• DNS query for domain, having a TTL less than 5-10 mins, should be one way to hunt.
• Then getting different IP addresses for the same domain is also a way to hunt.

10. Domain Generation Algorithm (DGA)

Domain generation algorithms are used by many malware families to create a large number of domain names that can be used as a rendezvous point with C2. For example, the compromised host would generate 10000 DNS queries per day, out of which it would query 200. C2 only has to register 1 out of those queries, but both use the same algorithm for DNS name generation.

Controllers only have to register for a single domain out of the several created, which bots would query every day.

• This makes it difficult for law enforcement to take down bots.
• It can be detected based on a myriad of non-responsive DNS queries from the source towards Randomised Domains. For randomise domain detection every SIEM has its own way to detect it.

So, now what? Well, the main takeaway is that we suggest you check for the above DNS anomalies, understand the methods and directions attackers may go down and, as a result, protect your data, products, processes and people.

If you want to find out more about SecurityHQ’s threat hunting services, contact us here.