Evolution of the Brazilian banker trojans

Brazilian banker trojans are essentially password stealing trojans that come in two main flavours. Both monitor the sites you visit in a web browser for certain Internet Banking web addresses. The first type will lift your bank login credentials directly from the internet banking login form as you type them in. The second type draws a fake internet banking login form over the top of the real form in the web browser to capture your credentials. Both then send their findings to the criminals.

Today I found the newest iteration in this attack and in analyzing the latest variant, I started to consider how the attack has evolved over the years.

The distribution method is fairly consistent. The attackers spam out an email, in Portuguese, explaining to the recipient that they’ve received a love letter e-card (they do use other subjects but love letters have been most common). The email contains an e-card picture linking to the malware. Other methods may be used, but the email campaigns have certainly been the mainstay. The following image shows some of the more recent spam messages:

Brazilian Banker Trojan Email Collage

When they first started sending these, the e-card picture was linked directly to the malware containing the payload – the actual functionality that does the monitoring, stealing and sending. The malware was usually hosted on a free file host, also Brazilian and the targets were customers of certain Brazilian banking establishments.

To draw the fake internet banking login form the crims decided to use the bitmap image format. But doing so caused two problems. First, the presence of those images was a fairly strong indicator that the file was malicious. Second, bitmaps are fairly large so downloading malware with lots of embedded bitmaps on a slow link (eg. dial-up) was time consuming. To get around this the crims started using packing engines to compress and hide the contents of the exe file.

Even compressed, for anyone not on broadband the files would still take a while to download. So the next iteration saw the banker crims writing a smaller executable file called a downloader Trojan – to silently download and run the real payload. At about the same time they started using other, less obvious executable file extensions for the malware, like .scr, .com, etc.

Next, they stopped linking directly to executable files in the email, preferring to host a page that used one of several different methods to autmatically redirect to the hosted malware.

Fast forward to today’s effort (its the big red heart in the picture above).

An email arrived containing a link to a page on a popular free hosting site. The page contains obfuscated javascript (javascript that is decoded on the fly by the browser, making it difficult to read). The javascript dynamically writes a Visual Basic Script that tries to exploit a known vulnerability in Internet Explorer. The page also sets the window title to an Anti-Spam message (it didn’t translate very well :-). It also contains a link to tinyurl.com (a free url shortener site) that links to a downloader trojan stored on a second free webhosting site and a link to yet another page on a third free webhosting site that has a copy of the original email.

The page on the second free webhosting site contains encrypted javascript that is further obfuscated (using character-encoding techniques). This function tries to exploit the same vulnerablity in Internet Explorer, though the decrypted functions differ in the way they construct some of the required strings. And just incase that all doesn’t work, there’s also links to the same tinyurl.com redirector.

The malware in question was a downloader trojan with a .scr extension (typically used by Windows to identify screen saver applications) that downloads a .swf file (usually reserved for Shockwave Flash files). This extension renaming is fairly common in malware. It serves two purposes, one is to prevent the file being blocked by proxies that deny access to files with executable extensions. The other is to hide the fact that the file is executable from the hosting companies.

The downloader copies the .swf file to the system folder and gives it a .exe extension. It executes it and also sets a key in the registry to ensure the payload starts automatically at login.

The payload itself is the kind that tries to pinch your credentials as you’re logging in. Both the downloader and the payload were packed with a couple of different types of packers but under the hood, they’re almost exactly the same as the bazillion previous examples we’ve seen.

Basically this group of malware authors haven’t really had a new idea since they started using the second kind of malware (the one that draws over the original form). Instead, they’re just finding new (and occasionally interesting) ways to wrap it up and convoluted deployment mechanisms. Where will they go from here?