RSA FirstWatch team shines a spotlight in the darker corners of the Internet to better understand online fraud and criminal trends. When possible, RSA FirstWatch members will use this space to share information about some of our findings.
It is getting tougher and tougher to be a botnet herder. As Intrusion Detection Signatures, AntiVirus Gateways, Next Generation Firewalls and Smart Proxies learn to recognize Zeus Command and Control queries and messages, running a successful botnet is getting more difficult. So how can a botnet herder get his C&C traffic past these control systems? By using DNS. Specifically, by querying a DNS server for TEXT records, reassembling the encoded messages, and providing a fast, reliable communication method that hardly any organization is blocking.
The RSA Live content delivery system has a great parser that will dissect DNS into common request and response types: a records, c records, no response errors, and what we will focus on here, TXT records. The TXT record in a DNS entry was originally created to allow someone to get some additional information about a server on the Internet. According to Wikipedia, "since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC DNS-SD" (
You don't tend to see very many TXT DNS record requests on a modern enterprise, so when they show up they tend to be worth investigating. For instance, we recently found a sample in our malware sandbox that showed over 400 TXT requests. It looked like this:
It is very unusual to see so many TXT records requested at once. What do we know about this domain? Well, for one, its pretty new.
Next, drilling into the contents of the TXT responses, we can determine if the contents of these records is human readable or machine readable.
As an aside, for those not accustomed to reading DNS responses in HEX, you can see at the top, a request for 185.57099.pf.alacartebelini.com followed by a response that confirms its IP address, and finally by what appears to be an encoded text string. So this TXT record was not put in place to provide helpful textual information about this host. The code is not human readable. I highlighted the same type of response from another query to this domain and opened it in WireShark, which looks a little cleaner:
So if we can't read the text code, how do we know this is Zeus? By refocusing our analysis on the source IP we can see some additional Zeus-type behavior, as well as secondary downloads of two additional pieces of malware.
We sent the av.exe and the 105.exe up to VirusTotal. You can access those reports by clicking the links for the names. Both files have good detection capability, but at the time of this writing, each were less than three days old.
To summarize, you do not have to understand how to decode machine readable TXT DNS queries. You should only understand that if it is not human readable, then it should be analyzed in context to other activity the source IP was engaged in at the time.
Finally, to detect this activity going forward on your own network, a simple rule would work.
Good luck and happy hunting!
