Banking Malware Hosted on Amazon's Cloud

Security researchers from Kaspersky Lab have discovered a piece of Brazilian banking malware hosted on Amazon Web Services (AWS) and the cloud provider failed to respond in a timely manner.

The malware installer was distributed from an account on Amazon's Simple Storage Service (Amazon S3) as a .scr (screen saver) file.

Once executed, it installs a rootkit which prevents several security products from running, including avast! Antivirus 5, AVG Antivirus, ESET NOD32 and Avira AntiVir.

It also disables a browser security add-on called GBPlugin which is commonly distributed by Brazilian banks to their customers.

The malware is designed to steal financial information from nine Brazilian banks and two international ones, login credentials for Microsoft's Live Messenger and digital certificates used by eTokens.

In addition, it reports back with information about the infected computers, such as their name, CPU type and hard drive volume numbers.

"[...] This information is being used by some Latin American banks during login sessions to the banks in order to authenticate customers," explains Kaspersky Lab expert Dmitry Bestuzhev.

The malware siphons information via two methods: by sending it to a special Gmail address or by uploading it into a remote web database.

Brazilian banking malware has been increasing in sophistication during recent months. Just last month one such threat was found bundling a rootkit that is capable of infecting 64-bit Windows systems.

Cyber criminals commonly abuse web hosting services, normally free ones, and their ability to respond quickly is critical to the number of potential victims. Unfortunately, it seems that Amazon did not give this incident a high enough priority, because, according to Mr. Bestuzhev, the infector was still live twelve hours after the company was notified.

This is not the first time that AWS is abused by cyber criminals. In late 2009, security researchers found a ZeuS command and control server hosted on the platform. In both cases, attackers most likely used stolen credentials instead of paying for the service themselves.