Let's assume I have a large enterprise network (thousands of nodes) and somewhere on that network there is malware communicating over DNS for C2. Let's assume the requests are designed such that the traffic is legitimate DNS and doesn't contain obvious commands or other strings that can be trivially detected. (Maybe it uses A records or AAAA to encode the data.)

It's possible to try to detect the traffic using several techniques:

  1. Look for regularly timed DNS traffic. (i.e., exactly every hour)
  2. Look for infrequently requested domains -- on a network this large, the malware requests should be the outliers. (But perhaps there's other traffic that's an outlier as well.)
  3. Look for DNS results that keep changing (but maybe it's DNS load balancing)

Are there other techniques I have not considered?

  • Looking for a list? ;)
    – schroeder
    Commented Jan 17, 2018 at 9:18

2 Answers 2

  1. Most malware that abuses channels (from my experience) includes some form of randomisation in connection timing. Even something as simple as 60 minutes + rand(-5,5) can defeat timing profilers. You will also find that people have some shockingly regular patterns in their browsing habits.
  2. From experience, frequency analysis will produce a lot of false positives in a large enterprise. Everyone's into their own thing and interests shift. Instead, analyse the domains for "infancy". Look up when the domain was registered and look for domains less than 3 months old. Then look for domains not owned by a * Inc. or * Ltd. or who have a "domain privacy shield" in place. Bubble those up for further investigation.

One thing you have not mentioned is comparing the domain with blacklists from a blacklist service. I assume you thought of that, but I wanted to mention it.

Remember that it is trivial for malware authors to adjust to any detection methods that you can devise (like timing analysis). The more robust detection processes require complex statistical analysis on both the destination and the requesting node compared the node's peers and general trends in the local environment (timing, time, frequency, content, bandwidth, mismatched peer profiles (a non-peer acting like a peer)). And even then, it will require further analysis to determine the true positives.

I have developed UEBA algorithms for just this sort of thing, and once you start, you will find yourself down a bit of a rabbit hole ("maybe I can tweak it this way and get better efficiency!"). For 80% effectiveness, focus on the "infancy" analysis that I mentioned above.

  • Thanks, that gives me a lot more to think about. It's amazing how trivial it is to make the analysis that much more complex!
    – David
    Commented Jan 17, 2018 at 16:15

Two other options:

1) Monitor the length of the DNS queries. C2 traffic, especially if exfiltrating data, is likely to have larger queries. If tracked over time this might show a possible tunnel

2) FQDN count by second-level domain.

Some of the specific payload analysis rules could be bypassed by a knowledgeable attacker. They could shorten the labels used and reduce the number of labels in an FQDN. However, they will always need to create a large number of unique FQDNs which are normally from a specific root domain.

This is from a SANS paper on detecting DNS tunnels which also gives several other possible indicators and covers specifically this second point in great detail.

  • I assumed your first point was covered by his "legitimate DNS and doesn't contain obvious commands or other strings that can be trivially detected". Are you thinking differently?
    – schroeder
    Commented Jan 17, 2018 at 9:57
  • I'm referring to just the size of the requests and replies, i.e. number of characters without regard to what they represent assuming they'll be encoded or encrypted. For example an A record request for MRZGS3TLEBWW64TFEBXXMYLMORUW4ZI.t.example.com
    – IamNaN
    Commented Jan 17, 2018 at 10:58
  • To me, that was covered by his preface (and the first thing to look for, anyway), but you're right that he did not specifically call that out.
    – schroeder
    Commented Jan 17, 2018 at 11:02
  • 1
    The issue with FQDN count by 2-level domain is that you'll easily run in a lot of false positives, because CDNs. An example: "cs2-wac.apr-8315.edgecastdns.net". Go figure.
    – ximaera
    Commented Jan 17, 2018 at 12:56
  • @ximaera but CDNs are well-known enough to be whitelisted, no? Even so, I still think the "infancy" analysis would prevent this false positive.
    – schroeder
    Commented Jan 17, 2018 at 13:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .