Cut the Cutwail....!

As Srizbi and Rustock are (temporarily) shutdown, there are only a few botnets left which are still able to communicate with their CnCs, and hence are able to send SPAM. This group of Botnets is some portion of Pushdo/Cutwail and Bobax/Kraken.

Marshal TRACE's recent analysis of SPAM distribution with respect to different botnets shows that currently Pushdo is the main source of worldwide SPAM in the absence of Srizbi and Rustock. Shutting down Pushdo (even temporarily) would mean more days without SPAM, just as we saw with the earlier shutdowns.

As we have already seen in the case of Srizbi and Rustock, stopping any botnet from executing its payload requires a shutdown of its master Command and Control server, or CnC.  In this article I will shed light on Pushdo's CnC architecture and its fallback mechanism (in the case where the primary CnCs become unavailable).

The term "Pushdo" is normally used to refer to the complete botnet, but physically Pushdo is comprised of more than one binary component.  The main service uses the HTTP protocol and is more like a generic download/dropper mechanism. This is the service which in the past was seen to communicating with McColo servers. The sole purpose of this binary is to download further components, such as a SPAM engine.  The Pushdo SPAM engine component is normally referred as 'CutWail'.  The main binary component and CutWail exist as independent executables on the infected system. This implies that even if the Command and Control servers of the main binary are shutdown, like in case of McColo, the Cutwail component can still communicate to its secondary CnCs to download new SPAM templates. This is exactly what's happening today.

Note: There are some exceptions to the above, as in the case recently where I saw Cutwail being distributed without the help of Pushdo, and instead using Trojan.Exchanger as the download service.

CutWail – SPAM engine

--------

My initial analysis revealed that Cutwail contacts one fixed IP address which is hard-coded in the binary image. This means that shutting down this server (or servers depending on different samples) would stop the distribution of spam templates, and hence worldwide SPAM from Cutwail.  But what will happen if these main servers ever become unavailable or are shutdown? To find this answer I tried to decipher Cutwail’s fallback mechanism.

In the case where the main CnC becomes unavailable, Cutwail has a set of hard-coded IPs which it further contacts to find the applicable name servers for a set of different domains. From a technical perspective, this means that it does a lookup for the 'NS' record for different TLDs, using public nameservers.  More on this later.

       

Pushdo – download service

-----------------

Now let's examine the CnC architecture of the primary binary component 'Pushdo'.  If the Cutwail secondary servers become unavailable, the primary binary component may come into play to update Cutwail to point to new secondary CnCs. As with Rustock and Srizbi, Pushdo also uses hard-coded CnC IPs. In Pushdo's case, this list of IPs has contained both McColo and non-McColo IPs.

In both cases we can see that Pushdo literally has no working fallback mechanism to recover when the main CnC becomes unavailable. In my next article I will reveal those non McColo servers (mostly hosted in US) which are still serving Pushdo and Cutwail. With a combined effort by the security community, as well as the hosting companies, we can shutdown Pushdo like we did with Rustock and Srizbi. Let’s start dreaming of a world without any SPAM.

Atif Mushtaq @ FireEye Malware Intelligence Lab

Comments/Questions: research SHIFT-2 fireeye DOT COM

Comments

[Dave]

The machine needs to recurse the domain hierarchy in order to work out what glue NS to send the queries to. It looks like it's doing a DNS lookup from first principles to me.

Unless I've missed something above the screenshot it appears to be looking up the NS for .com aka the TLD name server. The query section would contain the domain if it was asking the TLD nameserver for the nameserver of the domain.
($ dig ns com ) Etc.

Make your DNS answer the NS query for the TLD and you may then see the domain perhaps?

[Morten]

Nice analysis. And a beautiful dream (I dream it every day too) but I don't think that's going to happen in our lifetime. ;-) Keep on rockin'.