After McColo was shut down, the Srizbi botnet (major source of spam and over 300,000 strong) was effectively quieted, but not for long. Spam levels eventually started ramping back up. How’s that possible with no command and control servers? Read on to find out.


I mentioned in my article “Botnets: Web-Hosting Site Closed Down and Spam Drops 50 Percent” that security experts were fairly certain the botnets controlled by the McColo servers would be back up and spamming eventually. Just as a reference, the following diagram (courtesy of SpamCop) depicts the dramatic decline in reported spam when McColo was shut down:

I mentioned that the experts felt Srizbi would be back. Still, everyone thought it would take time to rebuild. An entirely new botnet would have to be formed using bot code that contained the appropriate command and control server information. That wasn’t the case though, the original Srizbi botnet started coming back online approximately three weeks after McColo was shut down.

How is it possible?

Botnet researchers were initially unable to explain how the estranged bots were able to find new command and control servers. Analysts also speculated that even the botmaster wasn’t initially aware of the capability, as mentioned by Julie Wolf of FireEye:

“These backup DNS names were not registered, which made everyone ask: “Who would code a backup DNS name into a bot, and then fail to register that name?” I speculated that it may have been an unknown feature of the code base that the bot author used, assuming that they didn’t write that much of the code, or even read any of it.”

Well, that question is now answered, at least for the Srizbi botnet. I must admit in all honesty, the how is amazing.

Here’s how

The people at FireEye Malware Intelligence Lab have been on top of this from the onset. Atif Mushtaq and Alex Lanstein in their FireEye blog “Srizbi Control Regained by Original Owner” give a high-level view of how the bots were able to reestablish communications with new command and control servers:

“Srizbi had a mechanism to dynamically generate the C&C (command and control server) to which it would communicate based on a seed (magic number) in the binary, and a variation of the Julian date of the infected host. This dynamic DNS generation mechanism was the main reason why they were able to regain control, even though the primary IP, hosted at McColo, was and is still not routable. The Botnet owner swooped in and began registering domains, as he was able to predict which would be in use today.”

Julia Wolf also published a very comprehensive explanation of the renaming process in her blog “Technical Details of Srizbi’s Domain Generation Algorithm.” Make sure to read the blog comments as they help explain the situation even further.

It’s pretty impressive

The person who came up with Srizbi had enough foresight to develop code that takes into account the removal of the command and control servers. The bot code is so designed that stranded bots will periodically generate new domain names and try to communicate with servers having that domain designation. The botmaster can also determine what domain names the bots are trying to reach. Then, all that’s required is to register the domains, set up command and control servers using those domain names, and restore communication between the bots and the command and control servers.

Some of the new domain names that have been used to restore the Srizbi botnet command and control function are:


If you read Wolf’s explanation, the unusual domain names start to make sense as they are the results of an automated process. It uses calendar events hashed by an algorithm to eventually come up with eight character domain names. Wolf further explains the initial function call:

“There is a call to KeQuerySystemTime, and then RtlTimeToTimeFields to get the current year, month, and day. This is done in a loop four times with a call to the function at the bottom of this post. The date is swizzled around in various ways, such as if there are more than 12 months, the quotient is converted to years, and leap-years are calculated, and other transforms like that. The returned day count is rounded down to the nearest third day. (i.e. Julian days which are even multiples of three.)”

Need an ISP

In order for the botmaster to regain control, a willing colo host is required. You might ask why go through all that trouble. Why doesn’t the botmaster just set up a command and control server? Well, that would more than likely lead to the botmaster’s early retirement. Using rented servers allows the botmaster to remain relatively anonymous.

To FireEye’s credit

The Srizbi botnet would have been back online a lot sooner if it hadn’t been for FireEye. When Wolf reverse engineered the Srizbi bot code, it gave FireEye the ability to determine the domain naming sequence. After which they registered several hundred domains in order to prevent Srizbi’s botmaster from doing so. Still, it’s an automated process and became cost prohibitive for FireEye to continue buying domain names. So, finally the botmaster was able to register the appropriate domain names and the Srizbi botnet came back online.

The following diagram (courtesy of SpamCop) displays the amount of reported spam for the past several weeks. It’s still significantly less than the McColo time frame, but the number of messages per second showed a distinct increase during week 47. That’s when the Srizbi botmaster was able to obtain the correct domain names:

Who’s hosting the command and control servers?

Starline Web Services was reportedly the Internet service provider that was hosting the command and control servers during week 47. Apparently the Srizbi botnet is once more without command and control servers. It’s almost dizzying at how fast the situation changes. Jeremy Kirk from ComputerWorld in his article “Estonian ISP Cuts Off Control Servers for Srizbi Botnet” has all the details of how Starline Web Services was shut down.

As of today, SpamCop is not showing any definitive downturn in spam messages per second, as shown in the following diagram:

That fact is likely due to the revival of the Rustock botnet, which also had command and control servers at McColo. The botmaster of the Rustock botnet found a Swedish ISP that provided McColo Internet access just long enough for the Rustock botmaster to send new instructions to the Rustock bots, pointing them to command and control servers in Russia. Evidently Rustock bot code doesn’t have automated domain renaming.

Final thoughts

What’s amazing, yet disheartening at the same time, is the sophistication of the malware being created to form botnets. I’m told by the experts that this is certainly solvable. I suspect so as well; I’m just worried about the cost.

Need help keeping systems connected and running at high efficiency? Delivered Monday and Wednesday, TechRepublic’s Network Administrator newsletter has the tips and tricks you need to better configure, support, and optimize your network. Automatically sign up today!