THREAT HUNTING OF DNS QUERIES & ANOMALIES

The goal of this hunt is to review DNS logs to baseline common domains queried by endpoints in the environment as well as identify potentially infected endpoints by looking for evidence of DNS tunneling,rogue communication, or data exfiltration, over DNS channels, domain generation algorithm (DGA) domains, and traffic to risky top level domains (TLDs).

Almost all APT threat actor groups have demonstrated indicators relating to the use of DNS as a covert channel.

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.

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

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.

For instance:

L72.8572Y8.AA.KLMXHRO.Y8ZW19283OLPDL20PPLPOLK.PLEC.test.xyz

4.?Domain Length

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

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.

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 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. Unusual domain name requests

The domain names to the C&C servers are usually random like 'asdggj.com' or '12.345.672.hujist.com'. If such domain names are encountered in the logs, they should be immediately blacklisted. Also, top level domain names such as .tk and .ru are suspicious and should be looked into for malicious activity.

11. Abnormal volume of DNS?

When a large number of DNS queries occur in a short span of time to unusual domain names, it is a sure sign of malicious activity. If these queries occur at odd hours, it's possible that the querying systems are infected.

12. Unusual DNS query failures?

Suspicious domain names can be blocked upon discovery. As a way around this, attackers use Domain Generation Algorithms (DGA) in their malware. The DGAs generate a large number of domain names everyday, a few of which could be used to successfully connect to the C&C server. . Since not every name is a successful connection, monitoring your logs for failed DNS queries can lead you to the infected systems.

13. high volume of uncommon resource record types (TXT, NULL, CNAME, etc.).

C2 channels may utilize less common record types to support different commands or functions. For example, a C2 channel may utilize TXT and CNAME requests to retrieve additional information, malware, or commands to execute.

14. Explore uncommon TLDs (.xyz, .me, .biz) and TLDs for geographical regions in which your organization does not regularly operate.

The proliferation of TLDs has made it easier for attackers to continually add new domains to their infrastructure to evade threat intel lists, as well as register doppelganger domains for common websites. Requests for TLDs of geographical regions outside of your organization’s point of presence should be considered suspicious and reviewed, especially regions synonymous with cybercrime and anonymization.

15. Filter on DNS application logs listing the response code NXDOMAIN (domain does not exist) to review hosts seen with a high volume of DNS resolution failures.

There are many benign reasons for failed DNS queries; however, abnormal volume can be a strong indicator of possible threat activity. For example, malware utilizing DGAs will cycle through multiple generated domains until a valid reply is received. Since most of the domains requested will not exist, it will generate a high volume of NXDOMAIN responses. In addition, abnormal NXDOMAIN volume could highlight hosts requesting malicious domains that are no longer active.

16. Look for hosts with high DNS request volume for multiple sub domains of a single parent domain.

A common method of communicating data is by including it in the query string itself in place of the subdomain (commonly encoded using Base64). Identifying requests of multiple suspicious subdomains for a specific domain could help to highlight this method of communication.

17. Identify suspicious requests by reviewing queries of domains that are abnormally long, or domains with a high level of entropy.

Highlighting abnormally long queries with high entropy could help identify encoded data hidden in query strings as well as evidence of DGA domains.

18. Review process names for any unusually named processes or processes that are not regularly seen generating logon requests.

Attackers can simply register new domains to evade detection by threat intel lists. Identifying newly registered domains could help to easily identify suspicious activity.

19. Familiar or misspelt domains

DNS Tunneling Utilities & Detection        

Iodine – A popular DNS exfiltration tool is called Iodine. https://github.com/yarrick/iodine.. It lets you set up an SSH shell between the target and the route computer.This tool allows you to exfiltrate data via IPv4 using DNS therefore bypassing firewalls.

1.Detection:HIGH RATE OF NULL REQUESTS

Same source IP, over 50 requests (Sum / Count) within 1 minute

Record Type = NULL

2.DO – EXFILTRATION?

Another popular DNS exfiltration tool is D0-EXFILTRATION. https://github.com/samratashok/nishang/blob/master/Utility/Do-Exfiltration.ps1.

This tool lets you exfiltrate data using DNS TXT records, so that is exactly what we are going to look at for our rule.

3.Detection:HIGH RATE OF TXT REQUESTS

Same source IP, over 50 requests (Sum / Count) within 1 minute.

Record Type = TXT

4.COBALT STRIKE

Cobalt Strike C2 is a common method this days.

https://www.cobaltstrike.com

Detection:

Queried domain is ‘aaa.stage.*’ or ‘post.1*’

5.QUERIES WITH BASE64 ENCODED STRINGS

Standard DNS queries will not contain Base 64 encoded strings in most cases, however threat actors do use this method to exfiltrate data from a network. This tool from https://github.com/krmaxwell/dns-exfiltration is a good example

Detection: BASE64 ENCODED & Query matches expression ‘*==.*’

6.BACKDOOR USING DNS TXT QUERIES

Attackers use DNS TXT queries?to send commands and powershell scripts to a backdoor. For Example : https://github.com/samratashok/nishang/blob/master/Backdoors/DNS_TXT_Pwnage.ps1

Detection:

Record Type = TXT

Answer contains ‘IEX, Invoke-Expression or cmd.exe’

7.HIGH DNS BYTES OUTBOUND FROM SAME SOURCE

Malicious actors commonly use DNS to exfiltrate data. To do this, they have to send large amounts of bytes of data over port 53 (DNS).

Detection:

Destination Port = 53

In Firewall Source Type:Same source IP, over 300,000 bytes message size (Sum / Count) within 1 minute.

In DNS Logs :Same sourc IP, over 300,000 bytes question length (Sum / Count) within 1 minute.

You will need to add legitimate source / destination /Domain combinations to the white list.

8.HIGH DNS REQUESTS FROM SAME SOURCE

Another unusual behavior exhibited by malicious DNS traffic is a large amount of DNS requests from one source IP in a short space of time

Detection:

Destination Port = 53

In Firewall Source Type:Same source IP, over 1000 port 53 connections (Sum / Count) within 1 minute.

In DNS Logs :Same source IP, over 1000 requests (Sum / Count) within 1 minute.

You will need to add legitimate source / destination /Domain combinations to the white list.

Other DNS Tunneling Tools:

OzymanDNS – Dan Kaminsky’s DNS tunneling project written in Perl. You can SSH with it.

DNSCat2 – “A DNS tunnel that won’t make you sick”.?Creates an encrypted C2 channel to let you upload/download files, run a shell, etc.

DNS Monitoring Utilities for detecting tunneling attacks:

dnsHunter?– A Python module written for MercenaryHuntFramework & Mercenary-Linux. Reads .pcap files to extract DNS queries and performs geo-lookups, which helps in analyses.

reassemble_dns – A Python tool to read .pcap files and reassemble DNS messages.