Practical Passive DNS Example

I (along with many others) have blogged in the past about the tremendous value of passive DNS data.  Recently, I have encountered a practical example of an instance where passive DNS data may provide one of the only ways to try and stay on top of a threat.

Recently, some members of the community have encountered/been working with a piece of malicious code that has the following properties:

1) A malicious JAR file is delivered with a content type of text/html.  This JAR file assembles two executables on the victim host and infects it.
2) The infected vicitim host initiates a callback to a randomly generated four character sub-domain (e.g., ..com).  This traffic is encrypted (via SSL) and goes to the same netblock (a /24), regardless of the domain name (which changes regularly).

The purpose of this malware is not yet known, and it is not widely written about or particularly well understood.

Typically, as has been discussed on this blog and elsewhere in the past, it's much easier to look for artifacts of infection, rather than pre-infection activity.  Typically that involves creating monitoring/alerting for one of the following:

1) Looking for command and control URL patterns (which are much more reliable and have lower false positive rates than just domain names or IP addresses).  In this case, the callback traffic is encrypted, and thus, there is no URL pattern that can be monitored for (unless one intercepts the SSL traffic, but that is a separate discussion).
2) Looking for command and control domain names.  Here again, since the domain names change, this is not going to be very effective as a long term monitoring solution.
3) Looking for the malicious code payload delivery.  In this case, since it is a JAR being delivered with a content type of text/html, the noise is overwhelming.  Creating alerting based on this type of logic would inundate incident response personnel with alerts, the overwhelming majority of which would be false positives.  As I've learned, delivering a JAR via content type text/html is actually fairly common, even for legitimate applications.

So what does one do?  Well, since the callbacks all go to the same netblock, one can monitor passive DNS data for any new domains that are requested and resolve to that netblock matching the pattern described above.  That way, if the callback domains change (which they have been), and a host is infected, the incident response team can pick up on the new callback domain(s) and respond accordingly.  True, the incident response team is still one step behind the malware, but that's a lot better than being in the dark.

Pretty neat real world use of passive DNS data in my opinion.