Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2013 > July

RSA FirstWatch has detected a new Zbot variant that utilizes multiple cloud services providers to strengthen their command and control ability.  While malware in the cloud has been discussed and observed for years, what makes this variant of Zbot different is that it doesn't behave like most variants detected over the past 6 months.


For the past six months and more, Zbot has been using UDP packets for command and control.  Typically there are anywhere from 5 to 15 command and control servers, each listening on a separate UDP port.  Many of these servers are home computers. If one or more of these hosts gets taken offline the botnet will still be able to send and receive commands since the other hosts provide a layer of resiliency. It’s a safety in numbers game.


This latest Zbot variant uses a single UDP port of 80 to 5 servers, each of which is hosted in a high-availability cloud.  Instead of needing a dozen unreliable systems spread around the world, it only needs 4 or 5 that are high-speed and guaranteed by the hosting service to be up and active.


How did RSA FirstWatch detect it?

We eliminated all of our known intelligence, or app rules we have created to identify things that we already know about.  What was left was a recognizable pattern of filename requests that seemed highly suspicious.


Digging into these meta elements revealed several destination servers that were each receiving requests for these filenames, all of which returned an error for a bad request.



In addition to the normal HTTP requests were quite a few UDP connections on port 80 which contained command and control strings.



Our Reporter Engine has a daily report that looks for unexplained UDP connections.  We use it to identify new Zbot variants.




When we searched VirusTotal to see if they had knowlege of these IP addresses, they turned up in a report here, identifying the activity as Tepfir/Kazy/Zbot.


The oddest thing about this activity is that it has a layer of "plausible deniability" about it.  There are hundreds of HTTP get requests, and each of them returned "400 Bad Request" HTTP errors.  And UDP transmissions are a one-way stream.  There is no way to know by just looking at the packets if those hosts were actually listening on port 80 UDP.


If you subscribe to RSA Live feeds from FirstWatch, you have already installed detection capabilities for these command and control servers.

Happy Hunting!

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 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!

Filter Blog

By date: By tag: