2009-06-14:

Banker trojans - a return to the past

re:security:easy:malware
It happened so that I got back to reversing banker trojans the other day, and celebrated it with a 24-hour marathon with many different foreign malware entities. Looks like that when I played with other stuff, the malware authors have also not slept! They thought of newer ways to make their malware more... weakly constructed ;p

But before I start, I would like to state that the malware which I analyzed was for sure NOT a representative piece of the malicious environment, and that I do know that there are some hi-tech almost state-of-art trojans out there. The ones I analyzed were similar to ones I analyzed back in the old days (I talked on SekIT conference about them), so I am, after all, able to do some environment comparation :)

Let's start with the huge ones - the delephants - banker trojans made in Delphi or Visual Basis, weighting from 5 do 15 MB each. They are still popular, and they still "harvest" much blood, or should I say... much money, from the unsuspecting users. The way such a trojan works is simple - it waits until a user enters a site of a bank, and then it displays a window INSIDE the window of the Internet browser (usually IE). On the displayed window the user will see a screen shot of a bank page with "edit" (input) fields in proper places (it's hard to know the difference). If the user won't notice (there are a couple of ways to do that - the simplest one is to right-click near the edit field and check if the browser popup will appear and looks the same as always), then he will enter his user id and password, which will get later sent to the evil-database, and the trojan will display another image wanting some more informations (like CVV2, pins, expiry date, etc).
Once I even stumbled upon a trojan that pretended to actually log in, but it showed a fake account with lots of money, and enticed the user to make a transfer (and steal some more passwords in the process of course).

Btw, I've found this picture in some trojan binary (do they want us to envy them or sth ?;D):



This part didn't change at all - the trojans still have screenshots embedded in BMP (hence their size) and JPEG formats, and they are still extremely large. But I must note that they almost never now show a bank page in the notepad (it was common for older trojans to create a window inside anything that had a bank page's title in the window title, so one could save a document in notepad named the same as a bank, and get a bank page in the notepad in the process - great! new notepad features ;D).

The thing that changed are the ways to transfer stolen data back to the evil-server - a few malware authors figured some new <sarcasm>great</sarcasm> ways to do that!

Normally malware uses one of these protocols:
- SMTP: e-mail via some difference SMTP servers to many different e-mail accounts
- HTTP: to receiving PHP scripts, which placed them in some SQL/text database or have send them to some other place

However someone <sarcasm>had a break-through</sarcasm> and said 'hey! why the hell do we write PHP scripts, when we can transfer the data to an SQL database without the middle-PHP-layer?'.
Yep. They linked in some MySQL or MSSQL libraries, included username, password, host and database name in the binary, and when they steal some user credentials, they do a few INSERT SQL queries. And yes, it is possible to log in with this information using any SQL manager (with respect to SQL family) and do SELECTs/DELETEs/UPDATEs/etc.

The second <sarcasm>great</sarcasm> way was to upload the data using FTP - same story here - everything in the binary, user/password/host. And of course any FTP client using this data allows one to access the server, do some uploads/donwloads/etc. Once it even happened that an FTP user/pass matched SSH user/pass on a server.

Of course, the trojan binaries are "encrypted". They use UPX (sic!), or some more secure protector, but as one may know, you are not able to keep safe anything that needs to be decrypted to be used or executed. One just has to run the trojan, make a memory dump, and look for text strings with passwords OR one has to run a sniffer and wait for the trojan to send some data (of course this is not true for MySQL >4.1 which is challenge/response authorized).

OK, Let's stop with the SQL/FTP transfers and megabytes of BMP screen shots. In the collection I've analyzed there were also trojans that worked with more grace. These ones played with domain name resolving in one of two ways:
- they appended evil-IPs paired with bank names to c:\windows\system32\drivers\etc\hosts file
- OR they changed the DNS settings of the system
And I must admit, the bank collection they gathered was astounding.

But as an end-note I'll tell you the truth - the fact that these trojans are weakly constructed, weight 10 mb, show bank pages in notepad and give free passwords to their servers.. changes nothing! Users run them anyway, enter their credentials, and loose their money. And the malware authors just count their income, and laugh their heads off reading posts of researched that say that their code is weak...

And thats it!

Comments:

2009-06-17 15:49:52 = PintSizedCat
{
Hey, great article as always.
I'm pretty curious about your setup for doing malware analysis, do you use VMWare or something similar?
}
2009-06-17 20:56:29 = Gynvael Coldwind
{
@PintSizedCat
Yep, I use a virtual machine. As for 'which one', it depends on the malware - sometimes Bochs (for example for the Sinowal MBR family MBR analysis), sometimes Virtual Box, sometimes Virtual PC, etc ;>
}

Add a comment:

Nick:
URL (optional):
Math captcha: 6 ∗ 5 + 1 =