After a year long battle, W32/Virut.A finally lands in top spot – surpassing Netsky. This parasitic file infector proves to be quite virulent, and has generated enough activity to land in our malware top 10 for twelve solid months. On top of infecting multiple local files on a PC, the virus can spread through file shares and/or removable media such as USB thumb drives. Additionally, it has a rather unique capability to propagate through other worms in a hybrid form – read here for more info.

Conficker, conficker, conficker. The notorious worm which has made headlines across the world continues to evolve with a new variant, Conficker.C. While it remained in fourth position in our Top 10 Exploitation list, exploit activity of MS08-067 (detected by FortiGuard IPS as ‘MS.DCERPC.NETAPI32.Buffer.Overflow‘) actually decreased since we recorded a peak of activity on February 12th, 2009. Even with slightly deflated exploit levels, the worm has certainly established a strong global foothold and with the development of Conficker.C, the authors intend for it to stick around for a while. Conficker.C is quite simply more robust and effective – it boasts a new domain generation algorithm, and uses an enhanced cryptographic hash function (MD6) to validate the authenticity of its own malicious code. Most notably, after April 1st, 2009 it will attempt to communicate with a larger set of rendezvous points than previous variants used.

It is yet to be seen what happens after April 1st, though it should be pointed out that this code simply becomes active on that date and will remain active afterwards. Given the amount of attention Conficker has received, it is likely the authors will attempt any sort of strike at a later date when it is less anticipated – and more Conficker.C variants are spread. That said, always be aware and keep your protection up to date. Conficker is best blocked through layered defense, such as intrusion prevention, web content filtering, and antivirus. We continue to monitor this threat in the lab.

There were 30 new vulnerabilities rated as ‘Critical’, up from last period’s count of 25. So far, active exploitation of these has been low. However, as we have seen before, critical vulnerabilities are highly sought in the digital underground and typically have long lifespans; it may take some time before successful exploits rise. This should be seen as a good opportunity to keep up to date with the latest patches before the vulnerabilities become larger issues.

Social engineering attacks continue to become more sophisticated. A form of Location Based Services (LBS), spam and attacks custom tailored towards a recipient’s geographical location have become more mainstream. Two examples from this edition include a spam campaign from Waledac, providing links to fake news sites serving up malicious variants of the Waledac family. The fake news sites (posing to be Reuters) had dynamic headlines which cited explosions in regions that were close to the geographic location (geoIP) of the victim who would follow these links. The other example comes from the Canadian Pharmacy gang: spam driving traffic to the vast network of fraudulent domains owned by this group is shown this edition, localized in Japanese. Canadian Pharmacy employs LBS, offering different content based on the geographic location of the would-be customer.

That is the purpose of this post. While not delving into the depths of reverse engineering Conficker, it aims at providing a few tips to whomever may want to participate in the community efforts, for a better understanding of the infamous worm variants. And the best part is that part of these tips apply to other malware pieces.

1. Equipment

The first thing to note is that Conficker is encrypted/compressed by a custom “run-time packer”, which is a very common strategy to prevent static analysis. Indeed, should you load a copy of the worm in a disassembler, all you’ll see is the assembly code of the said run-time packer, and a bunch of compressed data.

The first thing to do, therefore, is to unpack it, to reveal the actual assembly code of the worm.

The following gives some insights that may be useful to achieve this, using OllyDbg and IDAPro.

Note: It is assumed that doing this in an isolated and safe lab machine is required to avoid possible infection of internal networks.

2. Loading the malware into the debugger.

The Conficker worm is in fact a DLL file, sometimes obfuscated by a first layer of UPX run-time encryption/compression. Thus it’s a good idea to give it a first pass of unpacking with the appropriate UPX version, before loading it into the debugger.

We all have our own methods for debugging DLLs, and my personal choice is to modify the DLL bit flag to turn it into an EXE to the eyes of the debugger. Among other PE editors, CFF Explorer from ntcore is a tool that allows to do that.

Now open the file in OllyDbg and ‘Step into’ the DllMain() function.

3. Choosing the unpacking method

Run time packers are commonly hard to trace due to many anti-debugging tricks being employed by the malware authors. Yet all of them will certainly undergo some stages before jumping to the actual malicious code.  We can roughly divide the unpacking process flow into the following simplified flowchart:

Conficker follows roughly this sequence, decrypting byte by byte and saving the data in non-contiguous location, before reconstructing it again to copy somewhere in memory. That said, there are really two methods to unpack the actual malicious code:

• Either you reverse-engineer the unpacking algorithm, re-implement it in a scripting language, and run the script on the packed file (long and tedious)
• Or you let the run-time packer do the unpacking job for you, and catch a break right before the execution flow is passed to the actual malicious code

The latter method is the one we’ll explore here; while it is quicker, it has a drawback: it implies defeating the anti-debugging tricks scattered over the unpacking code, which are precisely meant to prevent the code to run inside a debugger.

4. The Good, the bad and the branch

Surprisingly, defeating the anti-debugging tricks in Conficker’s run-time packer code is not that difficult, once you’ve noticed something: Throughout the code, “decision-making” code blocks are frequently present at the end of its basic blocks. A “decision-making” code bit looks like this:

call    sub_100014A0    ; Unknown function
test    eax, eax
jz      loc_1000128E    ; branch 1
jmp     @loc_10001698   ; branch 2

This is very easy to formulate in English: If the “unknown function” returns 0, then go to branch 1, otherwise go to branch 2. The question therefore is: what does the “unknown function” do? Examples of such functions called in “decision-making” code bits can be seen below:

A specialist eye would quickly spot the RDTSC instructions and the nuisance API calls, very typical of debugger detection strategies implemented by malware authors. Consequently, the “unknown functions” mentioned above really are debugger detectors, returning 0 if the code runs in a debugger. We can thus label the “decision-making” code blocks as such:

call    sub_100014A0    ; debugger detector function
test    eax, eax
jz      loc_1000128E    ; bad branch
jmp     @loc_10001698   ; good branch

Where “good branch” leads to the following of the unpacking process (until the next decision-making code block), and “bad branch” leads to the exit door (after more or less deceptive circumvolutions).

Therefore, all we need to do to get the unpacking code to run properly is to set breakpoints over each decision-making code block, and force the good branch (either by manually setting the EIP right to it, or by mingling with the registers), hopping over the bad branches in rhythm.

Tracing this malware thus reminds me about Tinikling (an indigenous Filipino dance), where dancers need a coordinated jumping to avoid being hit by the bamboo poles by two other people tapping and sliding the bamboos.

5. Dump!

Now we know how to fence over the anti-debugging traps, the last remaining question is: when do I know I am done with the unpacking process? Again, there are various methods for that; the one we will use here consists in identifying when the code flow reaches the “Resolve APIs” phase in the unpacking sequence.

As a matter of fact, to access the services provided by the Operating System, modern compiled code typically resorts to function pointer tables (aka IAT in the Windows executable format): the addresses of imported API functions are stored in a table with a static location, and API calls in the code are done via an indirection through this table. It makes the relocation process easier: when a dll exporting API functions is dynamically loaded in the process memory space, the Windows loader only needs to update the function pointer table with the imported functions addresses, rather than fixing all the calls to the said API functions throughout the code.

As a matter of fact, once unpacking is complete and the actual malicious code reconstructed, a run-time packer will play the role of the Windows loader, and engage in a relocation process on the Malware’s function pointer table. In other (simple) words: it loads the needed dynamic libraries, and writes the addresses of the API functions used by the Malware in its function table. To obtain such addresses, the run-time packer will typically call the Windows API function GetProcAddress().

You have probably already inferred that a breakpoint astutely set on this function will be reached in the “Resolve APIs” phase… At this point, the malware code is fully reconstructed and stands, bare, in memory. Save it, like shown below:

Although not necessary for further analysis in IDA, at this point, it is a good idea to turn this data file into a working Win32 executable file, by reconstructing the proper PE headers, for a “clean” result. Various tools may help in that (eg: ShellCode2Exe )

Once this is done, you’re set to load your brand new, unpacked worm copy into IDA and engage in a new battle: understanding the malware actual features. This is left as an… exercise for the reader.

Guillaume Lovet contributed to this report

New vulnerabilities (NVC) were up nearly three fold, with 117 posted in comparison to 43 from January’s edition; 25.6% of these new vulnerabilities were detected to be actively exploited. Two new high-profile zero-day exploits (CVE-2009-0238 and CVE-2009-0658) affecting MS Excel (XLS) and Adobe Reader (PDF) have since been disclosed. Given these facts, and Conficker’s success, there is no better time than now to underscore patch management and effective security to battle these threats.

Conficker is still running strong. Our systems showed exploitation of the well known MS08-067 vulnerability displayed the highest recorded activity to date on February 14th, 2009. As of writing, volume levels are still quite high; a new variant has been discovered in the wild that allows malicious payload transfers through a backdoor port opened on an infected machine – without relying on the domain generation algorithm. Since the algorithm that generates the list of domains Conficker contacts to download code has been reversed/put in the spotlight, this latest functionality can be seen as a counter move by Conficker’s authors.

Waledac, a relatively new botnet in town, went on a long run using a Valentine’s Day campaign to dupe users into downloading a malicious executable which was, to no surprise, a copy of the Waledac trojan. The campaign used a variety of domain/sub domain names, safe-haven registrars, and fast flux. As a result, the domains are still resolving to malicious servers hosting the sites and executables. Sadly, this proves how durable and effective such campaigns can still be using not-so-new methodologies such as fast flux. As of writing, the campaign is still alive but is using a different theme dubbed as the ‘Couponizer’. This social engineering hook offers online “coupons” to the victim. One thing we noticed with Waledac is that, aside from coming in the usual shifting variants (server side polymorphic), the served malicious executable’s filename shifted frequently as well. Names such as ‘reader.exe’, ‘start.exe’, and ‘lovekit.exe’ were used.

Movement on the mobile front: After new variants of Flocker surfaced in January, targeting accounts with Indonesian operators, we reported on Yxes.A in February — the latest and greatest SymbianOS threat — aka “Sexy View”. While mobile threats are certainly low profile in terms of prevalence (compared to non-mobile threats), this is an area to keep a close eye on. The biggest threat posed by SymbOS/Yxes.A is its ground-breaking propagation function; with the capability to spread through SMS by providing malicious URLs, a bridge is created from mobile telecommunications to the the Internet as we know it. In turn, this opens up a range of possibilities, effectively allowing the authors more control over their creation. With more control and functionality added, Yxes.A proved that we may not be far away from a mobile botnet.

Spam levels remained consistent after crawling back from a sharp decrease late 2008 thanks, largely in part, to the McColo take-down in November 2008.  Phishing and scam emails are popular as ever in play with the economic crisis, as our spam traps harvested loan and job scams showing up in localized languages to various regions.