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 3rd 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.
