FirstWatch has discovered a new variant of TDSS Rootkit that beacons to specific online hosts. We will dissect the behavior in a moment, but first everyone should run this Custom query back to the middle of August to look for hits:
alias.host begins update,report && filename='<none>' && directory='/' && query exists && query length 100-u
This looks for hostnames that begin with update or report, with no filename, in a root directory with a query length of 100 characters or longer. You should also convert this query to a rule to push to your decoders. Call it TDSS Botnet Notification Beaconing. If you got hits on this, you might want to quarantine your victim hosts. Good luck with that.
Now let's take a look at what we've found, and discuss its utter weirdness.
In our sandbox, beginning on August 19, we started seeing unusual update servers with a rotating Alias.Host name. There are no two hostnames alike. Here is a screenshot using the custom drill above:
If you try to resolve any of these update servers via DNS, you will find that none of them return an IP. We suspect that these hostnames are generated on the TDSS infected host by modifying a local hosts table- and the randomized characters in the hostname are likely unique identifiers representing time, host, or something more.
Make no mistake, these hosts are indeed communicating over port 80 to these hosts. But if you try to connect to the host via destination IP directly on port 80, you are blocked. The hosts in question, screenshotted below, are preventing researchers, web crawlers and everyone OTHER than the TDSS bots to connect to it. I'm not sure how they manage to do this, but there is a hardcoded user-agent string of a beta version of Firefox that each of the above connections have in common. Perhaps the hosts at the destination IP addresses are using a rotating .htaccess file to only allow a specific UA string, or maybe it validates the hostname format in the inbound connection. I'm not sure.
Even URLQuery has seen this activity and they also have no screenshot of a valid connection. They also don't know what it is. Maybe someone should tell them it's TDSS rootkit.
So we know this is TDSS rootkit because we were able to pull the source files from our sandbox. VirusTotal agrees that this is a TDSS Variant. The first time they saw this file was on August 24th, about a week after we spotted it.
Next, check out the queries from the beaconing. Normal HTTP traffic only performs queries against a file, like a PHP file, and then passes a query to a backend database. In this instance, there is no filename being called. The query is actually against the root directory. This oddness also helped this traffic stand out against normal activity.
In summary, this new botnet beaconing from a rootkit is doing its best to hide from researchers. You can't browse the destination host. Each hostname is different, rendering watchlists and feeds void. The queries are wildly varying, making it very difficult to write a signature for detection. But with RSA's Security Analytics, you can still write a simple rule capturing the hostname beginnings, the filename, directory, and a query length, and you can detect this malicious traffic.
By the way, the destinations are now part of NWLive, so all clients subscribing to RSA FirstWatch content will have detection capability.
Happy Hunting!
