Detect C2 Traffic over DNS using Sigma
In this blog post, I will introduce another Sigma Use Case detecting Command & Control (C2) traffic over Domain Name System (DNS). DNS is used to translate human-friendly computer hostnames into IP addresses. The domain name www.test.com belongs to the top-level domain com. Each label to the left specifies a subdomain of the domain to the right. In our example, test is a subdomain of the com domain. In this blog post, we will define parent domain as the subdomain of the top-level domain.
DNS is the perfect C2 channel because of several facts:
- DNS is usually not blocked outbound.
- It is usually not monitored.
- A DNS C2 channel can work over DNS proxies.
Normally, a parent domain has a limited number of subdomains, which results in a limited number of DNS queries. If you see in your environment a huge number of DNS queries for a single parent domain, this is an indicator for malicious C2 traffic. In this case, DNS is used to transfer data instead of its intended purpose. There exists a good write-up for tunneling traffic using DNS, which can be found here.
Sigma Use Case
In order to detect big number of DNS queries for a single domain, the Sigma distinct count aggregation operator is used:
title: DNS C2 Detection
status: experimental
description: Normally, there exists a limited amount of different dns queries for a single parent domain. If a huge number of dns queries were performed for a single parent domain, this can be an indicator that DNS is used for transferring data.
references:
- https://zeltser.com/c2-dns-tunneling/
author: Patrick Bareiss
date: 2019/04/07
logsource:
product: dns
detection:
selection:
parent_domain: '*'
condition: selection | dc(dns_query) by parent_domain > 1000
falsepositives:
- Valid software, which uses dns for transferring data
level: high
tags:
- attack.c2
- attack.t1043Thank you for reading and I hope this Sigma use Case helps you to detect malicious C2 traffic in your company.
Hi Patrick,
Your article is interesting :). However, you write “If you see in your environment a huge number of DNS queries for a single parent domain, this is an indicator for malicious C2 traffic”. It’s not true because you can see a lot of requests to “google.com” and its not used for C2 traffic over DNS. Moreover you don’t explain why you used a distinct count instead of a simple count.
If you explain these two points your article will be better :).
Pablo
Hi Pablo,
thank you for your comment. I will try to make it more clear in the future.
Yes you are right, big companies such as “google” needs to be whitelisted.
I use a distinct count to get the unique amount of dns queries instead of the normal count, because I’m not interested in multiple same dns queries within a company.
Best regards,
Patrick
Thank you for sharing this. My opinion on your rule is that I expect it is not really a good catcher for C2 traffic. In my experience vendors like TrendMicro, FireEye, McAfee, etc. use such DNS behaviour for normal communication with the vendor (check for updates / signatures etc.). C2 has the following behaviour: beaconing like same size in a regular (timely) manner like every 30 seconds. An infected host doing C2 with no task from its C2 server would “phone home” e.g. with the same request every beacon. With your rule you would never detect it. Have you performed some tests in a real world / production network? Just my 2 cents 😉
Hello Bob,
thank you for your feedback.
Yes you are right that some vendor use dns to update their signatures, which is not a good design by the vendors in my opinion.
The vendors using that technique for updating is limited, which makes it easy to whitelist during tuning phase.
Yes we already found some stuff with that and SANS as well, which recommend to use that Use Case.