Practical DNS covert channel detection

Immunity makes outstanding offensive security products and one of my favorites is Innuendo.  Immunity recently demonstrated in a email linked to a video an effective method of exfiltration over DNS channel called ‘INNUENDO DNS CHANNEL Video‘https://vimeo.com/115206626 as pointed out, DNS is not ideal for exfil but more for command and control. Last year I saw Cobalt Strike had incorporated similar capabilities that started me thinking about detection. http://www.advancedpentest.com/help-beacon

 

Several papers have excellent example of the entire different DNS covert channel available on the market today and offer some concepts or proof of concept for detection. I am going to cover only the ones that have appeared to be effective and efficient in my own implementation.

 

Let me start with the end in mind: The detection engine I use today pulls all new domains from the previous or current day, not linked to a trusted DNS record by the last two zones, that have a common IP address linked by count, to the number of unique domain, that exceed a preset entropy threshold. 

 

Not everyone is going to go code up solutions and very few commercial solutions can demonstrate an effective means at detection unless the attackers are banging on DNS.  Probably the quick and cheap solution in detection is to count the number of unique domains that point to a single IP address daily.  If you have the means to calculate through a SIEM for example, you are already ahead of most.

 

Having buckets of domains that all point to a single IP address is the most valuable indication of a highly resilient domain or covert channel.  What is the cost in having a human go look at it every day?  Expensive but imperative if your Sony Entertainment Group a few months ago along with locating beacons and other signature free detection.  If you establish a nuanced set of conditions and leverage automation and notification, you can avoid wasted analytical effort.  

 

Improved detection starts with the means to collect and I generally use a custom implementation of passive DNS previously discussed. The point is to have a local understanding of DNS transactions over time.  A very important detail in tracking requires that IP addresses and domains are stored in an unlinked way. Waste the space and write two records, one for the domain and the subsequent IP and also write a record for the IP and the reverse DNS. If a new domain appears and it points to a different IP, that record will change for the domain, while the new IP record might also be updated.   

 

A need exist to track over days or weeks, it is easy to peruse the domains and count the IP addresses reversed domain queries and come up with a summary count. Content providers along with CDNs can have thousands of domains pointing to a single IP address, very important to have the means to exclude or tag.  Correlation around timing could be included but I prefer to tag domains as ‘trusted’. Some examples of false positives that would trigger include the following.

 

• 00000000.r.msn.com

• googlehosted.l.googleuserconent.com

• gizmodo.com

• tumblr.com

 

Reviewing all domains and IP relationships is expensive for expansive enterprises but extremely useful. Decision trees / filters ensure you don’t examine all the records, best to look at new domains not previously seen and correlate back against the full set.

 

I don’t have the desire to explain entropy here but I do use  a bit of python code to calculate the entropy of the new domains and alert on it.  If the entropy (based on the score I use) threshold exceeds ‘5’ and is not already trusted based on some factors, it   In a quick example ‘google.com’ has a score of  ‘2.646439’  and ‘http://deviantpackets.blogspot.com’ has a score of ‘4.113362’ because of more characters.

 

Entropy alone will lead to a large list of false positives or, that one covert channel you have no other way of detecting. Many sites use excessively long string of random looking or high entropy in the DNSs 3^rd zone plus, even security firms like Tenable Networks use it with the Nessus product. In finding covert channels, entropy is part of a decision tree or a correlation factor.

 

• Entropy score:5.06236611109

• Domain:xyz32322-ADSLogge-6Z9K99JF3441-377B035B8.us-west-1.elb.amazonaws.com

• Entropy Score: 5.01349441779

• Domain:ZZ-TAC-WebServerho-ZA8QRTMQS29O-1968B81422.us-east-1.elb.amazonaws.com

• Entorpy Score:5.05400630712

• Domain:trk327-us-ADSLogge-1MD7A4JGBS8FF-803889B11.us-east-1.elb.amazonaws.com

 

Evaluation of the DNS record type is also useful with TXT records having the ability to convey the most information.  Browsing TXT records once in awhile is part of being vigilant, along with low TTL but I don’t find either are useful alone.  Stumbling on the DNS Covert Channel is not as valuable as a useful workflow.

 

I know that most of the larger security firms have solutions similar to the above that are used much in the same way but I don’t see solutions in the managed security service space.  If you know of a comparable commercial solution I would love to hear about it.