As time has progressed, monitoring has moved further and further inside the enterprise. Once upon a time, an enterprise could monitor only its perimeter and still be in decent shape. Then, attackers started moving up the OSI stack (as has been discussed previously in this blog and elsewhere). Now, with attackers using legitimate domains/sites, encrypted command and control, and a whole host of other techniques to hide in the noise/legitimate traffic, it is getting increasingly difficult for the defender to keep pace. It appears to me that the only long term monitoring solution is to go all the way to the endpoint somehow (in tandem with instrumenting the network for monitoring of course). I'm not sure I see how else we can obtain the visibility on the interior segments of the network that we so desperately need.
A sad reality I fear.
Thursday, January 3, 2013
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.
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.,
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.
Subscribe to:
Posts (Atom)
