As a community, we've paid a good deal of attention to HTTP-based threats. This includes malicious downloads, callbacks, command and control, exfiltration of data, and other threats. To combat this threat, we've deployed proxies, firewalls, and myriad other technologies. A good deal of the threat feeds these days are dominated by HTTP-based threats, if not entirely focused on HTTP-based threats.
In some sense, the near-constant attention paid to HTTP-based threats is good. Looking at it from a different perspective though, it opens up organizations to attacks from other angles. We often pay an inordinate amount of attention to HTTP-based threats at the expense of other threats. One can't fault organizations for this -- there is still a tremendous amount of badness delivered via HTTP-based mechanisms of various different sorts and defending against it is very necessary.
In this post, I'd like to remind us not to forget about DNS. DNS is an incredibly flexible protocol that can move almost any amount of data in and out of organizations, sometimes undetected. For example, recently, I've seen DNS TXT records used for command and control of malicious code and even delivery of additional payload, rather than HTTP. Why would an attacker do this? Why not? When we learn of a malicious domain, what do we most often do? Yep, that's right -- we block HTTP-based communication with it (via proxy blocks, firewall blocks, or otherwise). But what do we most often do regarding DNS requests for those very same malicious domains? Yep, that's right -- nothing. So, can you blame the attackers for being creative in their exploitation and use of the DNS protocol?
Just another reason to stay diligent in the continual analysis of all types of network traffic -- not just HTTP-based traffic.
Wednesday, September 14, 2011
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment