7 WAYS TO DETECT MALICIOUS DNS TRAFFIC USING SIEM

DNS is the backbone of the Internet. It converts hostnames (e.g. www.blueteamblog.com) into computer readable IP addresses (e.g. 192.168.1.1) and vice versa.

At the same time however, malicious actors use it very regularly as part of malware and other nefarious activities. This blog post will show you X ways to detect this malicious behaviour using your SIEM. If you would like to learn more about DNS before diving into this, I would recommend this article by cloudflare which sums it up perfectly – https://www.cloudflare.com/learning/dns/what-is-dns/

Most of these rules will require DNS logs, which I highly recommend onboarding to any SIEM. Some of them will also work with Firewall logs. I will split these into “Firewall / DNS Versions” throughout the article.

If you have any issues implementing any of the below rules, contact me at https://blueteamblog.com/contact-me

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). To detect this we can make a simple rule :

Firewall Log Version

  • Destination Port = 53
  • Log Source Type = Your firewall type
  • Same source IP, over 300,000 bytes message size (Sum / Count) within 1 minute.
  • You will need to add legitimate source / destination combinations to the white list, these will depend on your business.

DNS Version

  • Log Source = Your DNS logs
  • Same source IP, over 300,000 bytes question length (Sum / Count) within 1 minute.
  • You will need to add legitimate domains to the whitelist, these will depend on your business.

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. To detect this we can do the following :

Firewall Log Version

  • Destination Port = 53
  • Log Source Type = Your firewall type
  • Same source IP, over 1000 port 53 connections (Sum / Count) within 1 minute.
  • Exclusion for your DNS servers as a source.
  • You will need to add legitimate source / destination combinations to the white list, these will depend on your business.

DNS Version

  • Log Source = Your DNS logs
  • Same source IP, over 1000 requests (Sum / Count) within 1 minute.
  • You will need to add legitimate domains to the whitelist, these will depend on your business.

IODINE TOOL DETECTION (HIGH RATE OF NULL REQUESTS)

A popular DNS exfiltration tool is called Iodine. https://github.com/yarrick/iodine.

This tool allows you to exfiltrate data via IPv4 using DNS therefore bypassing firewalls. Luckily for us, the tool regularly cause a pattern which we can detect.

DNS Version

  • Log Source = Your DNS logs
  • Same source IP, over 50 requests (Sum / Count) within 1 minute
  • Record Type = NULL
  • Some whitelisting may be required as already mentioned above.

DO – EXFILTRATION (HIGH RATE OF TXT REQUESTS)

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.

DNS Version

  • Log Source = Your DNS logs
  • Same source IP, over 50 requests (Sum / Count) within 1 minute.
  • Record Type = TXT
  • Some whitelisting may be required as already mentioned above.

COBALT STRIKE BEACON DETECTION

blank

This blog post from 3 years ago from Gigamon is the basis of our next rule – https://atr-blog.gigamon.com/2017/07/25/footprints-of-fin7-tracking-actor-patterns-part-1/

The threat group Fin7 continue to use Cobalt Strike C2 as a common method till this day. To detect Fin7, or other groups using Cobalt Strike (https://www.cobaltstrike.com/) we have a simple rule which either works with DNS logs or proxy logs.

DNS Version

  • Log Source = Your DNS logs
  • Queried domain is ‘aaa.stage.*’ or ‘post.1*’

Proxy Version

  • Log Source = Your Proxy logs
  • URL contains ‘aaa.stage.*’ or ‘post.1*’

DETECT 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. They do this to get past firewalls and also to hide what they are exfiltrating within the actual queries. This tool from https://github.com/krmaxwell/dns-exfiltration is a good example. The way of detecting this is quite high on resources, but does work.

DNS Version

  • Log Source = Your DNS logs
  • Query matches expression ‘*==.*’

DETECT BACKDOOR USING DNS TXT QUERIES

blank

This rule is a bit different from the previous which have mainly looked at ways actors exfiltrate data. This time, it is for infiltration.

In this case, we are going to set up a rule which detects strings which are sent using DNS TXT queries. These strings in turn are used to send commands and powershell scripts to a backdoor. The inspiration for this rule came from https://github.com/samratashok/nishang/blob/master/Backdoors/DNS_TXT_Pwnage.ps1

DNS Version

  • Log Source = Your DNS logs
  • Record Type = TXT
  • Answer contains ‘IEX, Invoke-Expression or cmd.exe’

Thanks for reading the article and I hope you learned something today. If you have any DNS rules I didn’t mention, please comment below. If you are having any issues making the rules I mentioned above, contact me and I will try to help. Thanks again for the continued support.

Leave a Reply

Your email address will not be published. Required fields are marked *