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 Jan 17 '18 at 9:18
  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.

| improve this answer | |
  • 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 Jan 17 '18 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.

| improve this answer | |
  • 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 Jan 17 '18 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 Jan 17 '18 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 Jan 17 '18 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 Jan 17 '18 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 Jan 17 '18 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.