A newly discovered bot from the author of Rustock utilizes new spamming technique making the SPAM it is designed to generate extremely difficult to spot and block.
But let's start from the beginning.
Two weeks ago ThreatExpert automation has received from our behavioral AV product ThreatFire a sample that was intercepted on a client machine.
The sample was noticed due to its attempt to connect to a remote host with the IP address 126.96.36.199 on port 443. The same behavior was observed with the loaders of Rustock.C. Previous variant of Rustock (B) is also known to be distributed from that IP, as seen in this report.
This time, however, the owners of Rustock decided to discard the old an unreliable SMTP client engine that caused so many troubles with the modern firewalls, and replace it with a new and modern Hotmail client engine.
The step undertaken by Rustock authors seems logical - while Rustock.C made extraordinary attempt to stay unnoticed by AV/firewall software operating within one given "zombie" for so long time, those who stood behind Rustock must have felt very unhappy with the outcome: "If the bot is so stealthy, how come the Rustock botnet is not the biggest in the world?"
Effective counter-measures against SPAM, such as firewalls and routers blocking port 25, black/white listings, rule-based filtering, and many other techniques is the answer why we can still use email these days.
No matter how well Rustock used to be hidden from AV/firewalls within any given "zombie", its SPAM traffic was still intercepted as soon as it left the infected host as it was still a normal SMTP-compliant traffic.
In order to be free from the firewall-imposed obstacles, Rustock changed its protocol into HTTP (TCP port 80) and DHTTPS (TCP port 443) - a "dummy" HTTPS.
The new variant of Rustock calls itself "Hotsend":
Thus, it will be referred in this write-up as "Rustock-Hotsend".
While the previous variant of Rustock injected a code into the usermode process winlogon.exe, Rustock-Hotsend runs as a usermode process while still relying on Rustock.C driver and communicating with it via INT 2Eh.
The method of deploying this bot is unknown (most likely, it is downloaded by other malware), but the filename it is dropped under is known to be %windows%\temp\[8 random HEX characters].exe.
For example, in three observed "in-the-wild" cases the deployed filename was:
When run, Rustock-Hotsend attempts to contact its command & control server with the IP address 188.8.131.52 (hosted by US provider McColo) on port 443. All communication with the server is encrypted with SHA1 (identical to Rustock.C):
Its backdoor component is also identical to the botdll.dll code injected by Rustock.C into winlogon.exe:
Static analysis reveals that the bot may accept the following 8 commands from the C&C server:
- "smtperr" - currently not used by the bot
- "waittme" - parameter that specifies the number of minutes to wait between C&C communication sessions
- "smtptrd" - parameter that specifies the number of concurrent SPAM mailing threads (limited to 100)
- "smparm" - command to trigger SPAM routine:
- download SPAM template from C&C server and save it as tmpcode.bin
- harvest email addresses from the files stored on the local computer
- start mass-mailing the previously received SPAM template to all harvested contacts in multiple concurrent mailing threads (up to 100)
- the mass-mailing routine uses Hotmail to send out SPAM
- "wfiles" - receive an arbitrary file from the C&C server and save it on the local computer
- "update" - command to update the bot with the binary previously received and saved with the "wfiles" command
- "btclean" - flag for the "update" command - forces Rustock.C driver self-removal by passing the special parameters with the "INT 2Eh" instruction
- "taskidd" - report to C&C server the number of the latest active task to perform, e.g. report "6" in case of the active "bot update" task; otherwise, pass this value to the Rustock.C driver as a parameter of the "INT 2Eh" instruction - the driver will receive this parameter as the ID of the task to perform
NOTE: "INT 2Eh" instruction is used for communication between the mailbot's userland code and the kernel-mode driver via the system interrupt (IDT) hooks.
When Rustock-Hotsend is instructed to launch its mass-mailing threads, the command "smparm" will have additional parameters delimited with the ":" character. These parameters are login credentials for a valid Hotmail account - login name and password.
Having login credentials in hand, the bot contacts "http://mail.live.com" and signs in with all the necessary communications performed by its Hotmail client engine.
Rustock's thread that signs in to Hotmail account is executed recursively until the bot can log on, construct a new message based on a SPAM template and then submit it from that account.
Obviously, the reliance on a valid Hotmail account supplied by the C&C server assumes that some other password stealing malware must play its role in the Rustock global combination. This missing puzzle - the password-stealing trojans - are required to deliver the feed of stolen credentials into the central congregated database, from which Rustock's automation would deploy the credentials into the clients compromised by the new Rustock bot.
If Rustock is unable to contact the IP 184.108.40.206, it will attempt to resolve the new IP by generating a random domain name [16 random HEX characters].biz and then trying to retrieve host information corresponding to that host name.
For example, the generated names could be:
Most likely, the generated domain names are pseudo-random. That is, all possible combinations could be pre-calculated by the author who uses the same algorithm. In this case, as soon as one of the newly generated pseudo-random domain names goes live, the clients would be able to resolve its IP, successfully connect to it and receive instructions for a new SPAM campaign.