In-depth analysis of malware shows different methods of obfuscating their codes. They employ different tactics to hide themselves to harden analysis. They also dynamically load functions that they will be using. Those functions more often times called API (Application Programming Interface) are commonly loaded when we run an application.

Malware authors also use dynamic function loading to enable itself to adapt to different operating system. They use it to enable their program to run on Windows XP, Vista, Windows 7 or other platform.

Common practice is to list all function names as an array of strings to be loaded once the application is running. They used a combination of LoadLibrary and GetProcAddress functions to get the proper addresses. Still some try to use other techniques of getting those addresses without even using those two functions.

Let’s take a closer look at how W32/Bredolab.AC!tr.dldr resolved its API addresses.

W32/Bredolab.AC!tr.dldr did not use a list of API strings,  instead it uses a list of hash values equivalent of the APIs. The hash is computed as below:

These are the steps how the malware got the right API  addresses without using LoadLibrary and GetProcAddress functions.

Step 1:

It first copies the DLL file that it needs in a “%temp%” folder with TMP??.tmp as the filename(?? is a 2-digit number).

Step 2:

It then loads the TMP??.tmp to its address space.

Step 3:

After loading the tmp file which is the equivalent dll file, it can now work on parsing it.  It parses its content, technically in the export table to get the list of function names. It then computes a hash value for each name and compare it to its own list.

Once it gets the right hash value, it then gets the address of the function. And it starts back on Step 1 till it gets all the addresses it needs.

This technique of getting API addresses is not new. But it still serves as a basis of how malware works. Malware authors go to some lengths just to try to make analysis harder. I imagine that this is not even half of what the malware does.

Overall malware volume returned to pre-October levels this period, after two months of record activity driven by ZBot, Bredolab and Pushdo/Cutwail. Nonetheless, the Bredolab loader returned to top spot with a vengeance this period, accounting for a whopping 66.5% of total detected malware activity. Again, as we have seen time and time again these attack campaigns typically do not last longer than a couple of days, but can return quickly in mass volume. The seeding engines (largely the Cutwail spamming trojan) behind Bredolab certainly have a lot of horsepower as we have observed over recent months – so much that a single Bredolab seeding campaign can manipulate Threatscape volume like a puppet on strings. Of course, sheer volume is not everything and such a drop should not create a false sense of security. In fact, this period we saw a rise in distinct malware, meaning more unique pieces of malicious code. ZBot attacks continue over the holiday season through the busiest time of year for online shopping – and likely online banking.

Exploitation of MS08-067 (made infamous by the Conficker worm) remains our most active attack, with Waledac botnet traffic being the second this period as listed in our Top 10 Attack list. December was a busy time for zero-days and vulnerabilities – we covered 147 new vulnerabilities and detected nearly 1/3 of those to be actively attacked. In December, FortiGuard Labs disclosed ten zero-day vulnerabilities that discovered and responsibly reported to the associated vendors: Microsoft (Indeo Codec & MS Project), Adobe and Cisco. On top of this, hackers continued to find ways to exploit zero-day attacks: CVE-2009-4324 (advisory here) was one observed through Adobe Reader/Acrobat and Javascript – an increasingly common attack vector. Current workarounds include utilizing the Javascript Blacklist Framework or simply disabling Javascript functionality. Another zero-day was addressed by Microsoft (Internet Explorer – advisory here) through MS09-072 on December 8th; as always, users should keep their software up to date when patches are released. FortiGuard Labs continues to discover new vulnerabilities and work with partner programs to develop advanced zero-day protection to mitigate threats such as these.

2010: The Perfect Storm
The large spike of activity we observed from September to November 2009 was a familiar trend to one from 2008. As you can see here, we saw a similar trend in 2008 during the first large wave of Scareware that hit cyber space. Scareware was also a major component detected during this wave in 2009, though overall volume had significantly increased to record levels over 2008. So, what do we know? We know that Scareware has flourished over this time frame, not at all shaken by any take-down attempts: affiliate programs continue to make and pay out money. In December 2009, the Internet Crime Complaint Center (IC3) issued an alert that said the FBI is aware of an estimated loss (due to Scareware fraud) in excess of $150 million USD. In 2008, a hacker by the name of NeoN posted affiliate program details showing earnings of top affiliates in excess of $150,000 USD in one month for one individual. High profile botnets continue to stay alive – Conficker, Waledac, Pushdo/Cutwail, Virut, Bredolab and of course multiple Zeus/ZBot networks. To stay alive and effective, some are beginning to enhance their malicious code and communications (see our Pushdo analysis here) – a ZBot attack was recently observed to leverage database services in the cloud (Amazon RDS). The end result is a widespread, robust and healthy infrastructure available to cyber criminals leading into 2010.

With more digital convergence undoubtedly to occur in 2010 (for example, the US Government backing digital health records and Asia’s e-Government initiative), there will be a wealth of opportunity for cyber crime. There is certainly no shortage of targets from governments and enterprise to end users and thriving social networks. There is also no shortage of infrastructure available to deliver attacks – as outlined above, malicious networks are firmly in place for use in addition to a growing array of legitimate services which can be leveraged. Finally, there is no shortage of vehicles through which to execute attacks. In 2009, we saw frequent exploitation of document formats (DOC, PDF, XLS) with many zero-days discovered and attacked in the wild. Crime services and crimeware continue to evolve and adapt, adding to the array of tools and techniques available to cyber criminals and their recruits. For example, CAPTCHAs are becoming less and less effective due to crime services leveraged by botnets like Koobface. For some more examples, refer to our blog post on adaptive crime services. With strong seeding engines in place as observed with Pushdo & Bredolab, already rampant Scareware can now quickly shift to Ransomware in high volume – leaving a potentially damaging trail in place. Digesting all of this, it becomes apparent that we are in for a wild ride in 2010 — all the elements are in place for a perfect storm in cyberspace.

Since my last post on Jane Doe and Bredolab, John has been slightly jealous of her fame. He told me that, he too, as a manager of the returned material service, was dealing with plenty of parcels and that he could have been the perfect target. As I was curious to see what a genuine shipment company e-mail looked like (to compare them with Bredolab), I asked him if I could have a quick look at his mailbox.

I had hardly started reading his e-mails, that I ran into one that had me immediately start.

For those of you who do not speak French, I have highlighted the most important parts: a sales rep from a legitimate company (censured :) is asking John Doe for his login and password on their website on behalf of some administrative reason ! This email is genuine (I mean it is not a spam nor a joke). I can’t believe it. This looks straight out of the books “Things One Should Never Do In Security”. The main reasons not to do that are:

1- Counter-educative. If legitimate companies start asking for user logins and passwords, how will we tell the difference with phishing emails ? Asking for credentials really is bad practice, and it should be banned from all policies.

2- Passwords are personal. Giving one’s password is always a bad idea, because, for mnemonic reasons, we often use similar patterns in all our passwords. If I use ‘darthvador’ on a website, there are strong chances I will also use it on another website, or something similar, such as ‘lukeskywalker’ or ‘r2d2′. By the way, those passwords are weak because they are straight out of the English dictionnary (or quite).

3- Separating roles. Administrative tasks should be performed by a dedicated account, or, if necessary, a super user account. Otherwise, it is impossible to tell the difference between administrative actions and those of an authenticated user.

As a side note, all decent authentication systems are designed so that the administrator cannot know – and does not need to know – user passwords. For example, on any Unix system, the system administrator can only reset user account passwords. The /etc/passwd or shadow authentication file do not store the plaintext password but a password digest – where digests cannot be reversed.

John, for this e-mail, you absolutely deserve a blog post, and even better, glory for not having answered the sales rep. Congratulations.

And if you, readers, one day receive a similar e-mail, please remember this one should go straight to your trash.

– The Crypto Girl.

Today, I feel like telling you a true story that happened at Fortinet, the story of Jane Doe.

Jane Doe works for Human Resources at the reception desk, so she is used to receiving lots of mail, UPS or DHL parcels for the company. Some time ago, Jane received an e-mail from DHL, notifying her they had been unable to deliver a parcel (see figure below). She does handle plenty of DHL parcels every day, consequently, she did not give this e-mail any particular attention and, quite absent-mindedly, tried to open the attachment. Fortunately, she did not manage to unzip anything because the attachment had been removed by FortiMail. Only then did Jane realize there was something strange about the e-mail.

Figure 1. Bredolab spam example. Apart from the sender, they look real. Click on the image to enlarge.

Apart from covert advertisement for FortiMail ;) this example just perfectly illustrates the efficiency of targeted spamming. Forge a plausible e-mail (as a matter of fact, UPS or DHL often include attachments in their e-mails to track this or that parcel) and send it to the right mailbox (a person expecting DHL parcels): this is close to guaranteed infection. Proof: it would have worked even at Fortinet where employees are particularly well-aware of the dangers of viruses. So, spammers, please don’t do this: it is an unfair blow.

Incidentally, we had a look at the stats of our scanning system. There was a large spike of DHL spam, October 13th being the largest (around 3,000 spam mails collected by our system), and recently tapered off. This increased from about 50-100 spam mails per day in mid-late September. This spam campaign infects victims with Bredolab.

Guillaume Lovet, Derek Manky, Doug McDonald, Alexandre Aumoine and Jane Doe are the main contributors to this blog entry. Many thanks !