Let’s crack RSA! Yoo-hoo!

Ransomware is a known type of malware that is a clear demonstration of how pathetic the scriptkids become sometimes in an attempt to make a few bucks (for an ice cream?).

On the other hand, a fresh sample of ransomware gives AV vendors a unique opportunity to spin an interesting and flashy story, as general public is probably too tired of constant “mobile threats” or “invisible rootkits”.

This time, however, it sounds like the drama around Gpcode.ak went too far with the new initiative to join the world’s best minds in an attempt to "crack" the RSA encryption algorithm with a 1024-bit key and finally decrypt the files encrypted with Gpcode.ak.

This initiative sounds a bit awkward considering the ratio between the malware forces and the number of analysts who combat them. It completely ignores the fact how easy it is to release Gpcode.al, Gpcode.am, etc. etc. where slight tweaks in the code would render developed decrypting solutions useless.

To put it simpler – by stripping off RSA encryption completely, a new variant of Gpcode might firstly delete the files, then lock machine asking for ransom to be paid before the deleted files are permanently wiped out from the hard disk. Any attempt to "mess" with it (power off, terminate process), and the files are gone forever. In this case scenario, all the efforts to recover the damage from one particular variant ("ak") would turn to be a huge (unaffordable) waste of time.

It all rather boils down to another initiative – to be a bit more practical.

A good sobering reminder about the current situation in AV industry is the following picture:



Image Copyright: IKARUS

New Rustock Switches to Hotmail

It is a known fact that spambots and mass-mailers don't really like firewalls and other network-based host intrusion prevention systems, as it's a trivial task for them to detect and block SPAM traffic that flows via SMTP port.

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 208.66.194.215 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:

• C:\Windows\TEMP\ef6b4d09.EXE


• C:\Windows\TEMP\e5bb9ff8.EXE


• C:\Windows\TEMP\ac27cfb5.EXE

Backdoor Commands

When run, Rustock-Hotsend attempts to contact its command & control server with the IP address 208.66.194.215 (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.

Mass-mailing

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.

Fail-Safe Feature

If Rustock is unable to contact the IP 208.66.194.215, 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:

• bb464c5a19294446.biz


• cd5c5f7ab21e26f2.biz


• 82fb906e14bfb839.biz

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.