Microsoft and FireEye give inside story of Rustock botnet shutdown

The team behind the shutdown of the Rustock botnet have been giving details of how they were able to identify and take out the key command servers behind the network, and the legal precedent the case has set.

The Rustock botnet was responsible at one stage for more than half of the world's spam; its demise last week has cut global junk email levels significantly. It is made up of more than one million PCs which were infected over a period of years and remain so, with the possibility it could still be reactivated if any backup systems remain.

Microsoft's Digital Crimes Unit (DCU) has been taking increasing action against botnets over the last few years. As the Waledac botnet shutdown was being completed, the team moved onto the next botnet on their wish list, recruiting staff from malware specialist FireEye and researchers at the University of Washington.

"Rustock is a much higher class of malware development that Waledac," TJ Campana, senior program manager at the DCU told V3.co.uk.

"It was very well put together and definitely well written, in that it was difficult to reverse engineer. The original programmers had put in a lot of software tricks to fool static analysis."

Static analysis looks for malware on an infected machine's hard drive but the team also used dynamic analysis, which involves allowing the system to run in a virtualised environment and monitoring its behaviour and data traffic.

FireEye was tasked with collecting all of the samples for the analysis and monitoring of encrypted connections between command and control servers. It found the spam engine used by Rustock was being sent out disguised as a driver for Windows, and installed like a legitimate piece of code.

The malware used hard-coded IP addresses and communicated to command and control servers via peer-to-peer. These communications made it essential to finding all of the botnet command servers, since just removing one would alert the owners of a problem and not harm its operation.

"Any move on the connection had to be co-ordinated," Alex Lanstein, a security analyst at FireEye told V3.co.uk.

"There were a number of backup systems, with domain generation algorithms to re-establish control if the principle signal was blocked. We had to make sure all those domains were blocked."