In those forums there were links embedded in the posts which lead to a JavaScript on a Russian website. A google search with the URL revealed that already more than 100 web pages, especially forums, got infected with that malicious link – the infection rate is increasing fast. Later another URL with the malware script was identified, which Google reported on more than 16.000 obviously infected web pages.

Fig. 1: The JavaScript is encrypted and obfuscated in several layers.

The JavaScript is trying to exploit several vulnerabilities to silently install malware on affected users’ computers. Among these are exploits for Microsoft Video ActiveX Control Vulnerability (CVE-2008-0015), Microsoft Internet Explorer XML Parsing Vulnerability (CVE-2008-4844), Microsoft Internet Explorer Malformed CSS Memory Corruption Vulnerability (CVE-2009-0076) and some PDF exploits for Firefox and the Internet Explorer. All these exploits are already known and security updates are available. The malware writers obviously assume that a lot of Internet users do not update their systems.

Fig. 2: Decrypting the JavaScript needed some brute force, too.

That malicious JavaScript is hosted on a fast-flux’ed domain – the Internet addresses to which the embedded link points resolves to different locations every few minutes (fast flux as abbreviation from fast fluctuation, see Wikipedia). So it doesn’t help to take down one server as there are plenty of them. Usually infected computers serve the malware.

Fig. 3: The domain the JavaScript was loaded from was a fastflux'ed domain.

The servers are GeoIP-aware. Trying to access them directly with an IP from Deutsche Telekom network resulted in an “access denied”, while using a proxy in the USA made the bots deliver the malware.

Fig. 4: The shellcode in the JavaScript finally leads to a FakeAV infection.

But this malware – Avira detects it TR/FraudPack.ams – is just another downloader. It is encrypted with some layers as well.

Fig. 5: The crypter author sends out greetings to Sunbelt.

One of the encryption layers contains greetings to the company Sunbelt.

Fig. 6: Contents of the FakeAV downloader svcst.exe.

It accesses a set of “double fast-flux’ed” domains to fetch the actual malware, a FakeAV and a ftp password stealer which sends the data to guest books on the Internet. These are detected by Avira with generic detection as TR/Crypt.ZPACK.Gen and as TR/FakeAV.RK, while the password uploader gets detected as TR/Downloader.Gen.

Fig. 7: The FakeAV disguises itself as Antivirus Pro 2010.

The WebGuard of the Avira Premium and Professional blocks the URLs from where the malicious JavaScript is included and also the malware download URLs. Avira AntiVir also protects users from the downloaded malware.

(Article updated on 6th October to add more details about the malware.)

Emanuel Somosan
Moritz Kroll
Engine R&D

Dirk Knop
Technical Editor

This time Tõnu Samuel found such a database and counted the passwords. While he tried to spot differences between male and female password choosing habits, for me the most interesting part is the overall view. The top ten passwords are:

So the best guess for a user password is still 123456. This isn’t coincidence – just take a look at the ‘Top 500 worst passwords of all time’.

When it comes to choose a password, you should always have such statistics in mind. Also dictionary attacks are quite usual – with all permutations like word combination, backwards spelling, capital letters in all positions, ‘leet substitution’ (31337) and also adding numbers.

A good password doesn’t contain words that you can find in a dictionary. Try to take the first letters of the words of a sentence that you can remember. Make some of them capital and add special signs and numbers. An example: ‘My two Children are getting up at 7 a.m. in the morning.’ could result in ‘M2Cagua7amitm’. There are still special signs missing, but you get the point. This password is also long enough to make brute force or rainbow table attacks less likely to be successful.

Dirk Knop
Technical Editor

It is polymorphic and has been manually adapted and extended by its author(s) multiple times. While analysing one of the latest W32/Virut variants, we came accross a block in the virus code that couldn’t be properly disassembled by the used debugger. Looking closer, it turned out that the problematic block of code contained a relatively unusual multi-byte no-operation instruction (NOP).

Fig. 1: Even modern disassemblers and debuggers can't decode the length of the NOP correctly (OllyDbg 1.10).

The usual NOP instruction of x86 processors is one byte long (opcode 0x90). But there is also a multi-byte NOP with the opcode 0x0F 1F which is used in the virus code. The multi-byte NOP can take up to 9 bytes. NOP instructions can get used for padding the code to align it to 8 or 16 byte boundaries – on modern processors this can speed up the code, mostly for caching reasons.

Intel officially documented this multi-byte NOP in 2006, but it has already been present in older processors for quite a while – apparently since Pentium Pro, but not the Pentium MMX.

Fig. 2: Older disassemblers and debuggers don't cope well with the multi-byte NOP instructions (older IDA variant).

The author(s) of the W32/Virut malware now use(s) the fact that these multi-byte NOP instructions are still quite unknown to complicate the analysis and to trick disassemblers and emulators. Some commonly used disassemblers and debuggers don’t support these opcodes. They cannot calculate the correct length of the instruction and as a result aren’t able to properly “translate” the code beyond this point.

Markus Hinderhofer
Engine Research & Development

Dirk Knop
Technical Editor

We predicted that the use of polymorphic file infectors will increase again. This became true: W32/Virut, W32/Sality and W32/Almanahe are celebrating a comeback. The authors spread new variants of their polymorphism-engines. It seems that even older versions of those polymorphic viruses are still widespread, but W32/Virut is releasing the most updates – several dozens in the first six months of the year. The good news is that our detection routines withstand these bypass attempts.

Spreading malware via manipulated PDF documents still is one of the top threats on the Internet. In the last months the amount of exploit PDFs showing up for the vulnerabilities in PDF readers significantly increased – in the first half of 2009 we received several thousand samples. Every week the malware authors spread around ten newly obfuscated exploits, which in turn got used for plenty of PDF files each. We’re regularly releasing updates for new modified PDF exploits when necessary. Users should update their PDF readers regularly anyhow as this mitigates most of the threats.

As attack vector for infections of computers web-borne malware is further increasing. The malware gets more and more installed via drive-by-downloads, where the attackers hack into web servers with legitimate content and add references to their malware servers. Those servers then install for example trojans and/or bots on the vulnerable computers. It seems that there are plenty of construction toolkits out there with which anyone can produce malicious JavaScript simply by the click with the mouse: Malware-features like encryption, heap-spraying and shellcode seem to be more modular and repeating in parts of the malicious web pages we analyzed.

The usage of a recent antivirus product will help protecting from these threats. The WebGuard of our premium products additionally very efficiently remedies the web-borne malware distribution.

Dirk Knop
Technical Editor

Our statistics show that 14.43% from the Phishing and 15.04% from the Malware URLs (for which we have geo IP information) are hosted on servers located in Germany. The numbers of malicious URLs which are advertised in Germany (not necessarily hosted) can’t be computed, since no one is able to count all the emails which contain the URLs.

Fig. 1: The countries where phishing URLs are hosted

What do we do to stop them?
The most common way of spreading the URLs is the email. Avira is actively in fighting these threats in two different ways:

Avira’s security products

• detect the phishing emails and mark them as such.
• block the access to the URLs which point to phishing and malware websites.

Fig. 2: The registrars which receive notifications to remove dangerous files

Our Labs collaborate with institutions and organizations which send warning information to the registrars and ISPs hosting the dangerous files.

We actively monitor the most phished institutions and issue alerts to the readers of this blog (Figure 3). Of course, not all the names on the list are relevant for the German Users, but once Avira has reached the users all over the world, these information will be very useful.

Fig. 3: Most phished institutions

Sorin Mustaca
Manager International Software Development

Fig. 1: The new import table

W32/Tobin adds a new section named “.lenna” at the end of the PE file. This section consists of an import table – such import tables are used by the Windows loader to dynamically load DLLs and provide the corresponding function from them to the started program. The new import table references the dropped DLL “nikitob.dll”. At the same time, the import data directory entry in the PE header gets modified to point to the newly attached import table. If there is a bound import table in the executable, W32/Tobin “removes” the entry from the data directory by setting it’s RVA and size to 0.

Fig. 2: Original data directory address

Fig. 3: Patched data directory address

The dropped DLL “nikitob.dll” just exports one function, “NikitaTob”. Upon calling it, it shows a message box with the text “NikitaTob”. The actual virus code is executed automatically when the DLL is loaded.

Fig. 4: The malware dll exports just one function

Among other things, the import address table is rebuilt to make the patched executable work. In our analysis we didn’t find further malicious routines in the malware.

Fig. 5: W32/Tobin just shows a message

In one of the W32/Tobin samples we found the reference to “C:\NIKITA\Soft\black_soft\29a\nikitob\Release\nikitob.pdb”. A short search in our archives turned up an old magazine of the VX group 29A. In the issue from January 2005 there is proof-of-concept code which exactly infects files the W32/Tobin-way. The new section there is called “.senna”, and a message box shows the text “PayLoad”. It looks like some malware writers used the Proof-of-Concept virus to learn new techniques.

Removing this kind of malware from an infected system isn’t as simple as it may look on first glance. Simply deleting the dropped DLL doesn’t work: The infected executables depend upon the DLL now and won’t start anymore. Most likely the whole system wouldn’t start up anymore. Since W32/Tobin stores the address of the original import table at the end of the executable, it is possible to restore that value and disinfect the system gracefully.

Dirk Knop
Technical Editor

Hi Dear sniffer
If you want to find the net
You better put some effort in doing it
Because anubis wont do the job for you
Bitch.

Anubis is a sandbox system reachable on the Internet where you can upload suspicious executable files to. Those are run in a safe environment and changes done to the system during that run are shown after a few minutes. Obviously, malware authors are upset about those sandboxes and now start to prepare their binaries so that the malicious activity is not detectable by them anymore.

Dirk Knop
Technical Editor

When an infected file is started, the virus code takes control and may infect other files. As a rule, control is passed back to the original host program after the virus has done its dirty work, so the user doesn’t notice anything wrong. Sophisticated techniques such as encryption, obfuscation, polymorphism and stealth capabilities are often used by this kind of malware to make detection harder and to hide its presence.

While detection isn’t necessarily more difficult compared to other types of malware, removal is usually a less trivial task (which may be the motivation for malware authors). In many cases, files cannot simply be deleted as this would affect the stability or even basic functionality of the operating system and other software.

Instead, the infected host program must be disinfected by removing the virus code from it and by carefully restoring the original contents and file structure if possible. The threat posed by this type of infection seems greatly underestimated nowadays, as the frequency of trojan infections is much higher. However, one must keep in mind that an infection with a static trojan binary is usually limited to one or very few systems in a networked environment. For file infectors, which nowadays often come with worm-like spreading routines, this is not the case. A full network-wide infection, including network shares and sometimes operation-critical software, can prove to be a much bigger issue to deal with than a single trojanized workstation.

This means detection and removal are still an issue for antivirus software. As an example, this blog entry discusses the removal of the Almanahe virus that appeared in 2007 in different variants. Almanahe is a polymorphic virus that infects Windows executable (PE) files on the local system and spreads via network shares. It has also rootkit capabilities to hide its presence on the infected system. The variant covered here is detected by AntiVir as W32/Alman.BB.

When infecting an executable file, the virus performs the following modifications to the host file:
It overwrites parts of the original code section (about 1400 bytes) and redirects the entry point to the start of the injected virus code. The original code, which has been overwritten, is compressed using a run-length encoding algorithm (RLE) and is appended to the last section, along with the dropped component, which is also compressed (roughly 36 kB in size). It modifies the PE header to reflect the changes made to the file. Since most of the virus code is encrypted, it also sets the writable flag on the code section, so the virus can decrypt itself when it is started. To prevent multiple infection of the same file, the virus inserts an infection marker into the MZ header.

Layout of infected PE file

In order to disinfect a file infected by this virus, the following steps must be performed:
First, the original code, which has been appended to the last section, must be located and decompressed. Then, the original code can be restored by overwriting the virus code in the code section. The entry point has to be redirected to its original location. The data appended to the file is cut from the file and the original size of the last section is restored. Last but not least, the header values need to be adjusted and the infection marker is removed.

Doing this is not as trivial as it may sound at first, because the data is encrypted/compressed and the offsets and sizes are different for each file. So let’s have a closer look on how disinfection works:

The virus entry point code starts with about 200 bytes of randomly generated junk instructions in order to prevent detection by a simple signature. At the end of this non-encrypted block, there is a simple decryption loop that decrypts the remainder of the virus code injected into the code section upon execution of the file. The decryption scheme is a simple SUB, ADD, or XOR operation with a single byte key. So as a first step, we need to decrypt this code.

The decrypted code contains the decompression routine for the data appended to the last section. In the next step, we locate the code where the decompression routine is called:

Call(s) of decompression routine

As we can see, the decompression routine is called twice. With the first call, only the first part of the data appended to the last section is extracted, which is the original code from the code section. In the second call, the dropped file is extracted (which is static). What we need to do is to locate the first call and extract the parameters for the decompression routine. That is the relative start offset (0xFA00h) and the decoding length in bits (0x27AAh).

As already mentioned before, the (de)compressor is some kind of run-length encoder (RLE). If there are recurring byte sequences, only the position and the length of the (previous) byte sequence is stored in the encoded data. When decoding the data, a single bit signals whether the next byte is directly extracted from the encoded data or if an already extracted byte sequence must be copied to the current position in the destination buffer. In the latter case, only the position and the length are encoded in the input stream. The following picture illustrates the decoding mechanism:

Decoding mechanism (output stream)

Now that we have located the offset and size of the compressed original code, we can restore it by decompressing the first part of the data appended to the last section. We write it to its original location in the code section, and thus overwrite the virus code.

We still need to restore the original entry point RVA, which we can also extract from the decrypted virus code:

RVA of original entry point

In the next step, we truncate the file to its original size by cutting off the appended data and adjusting the size of the last section. We also adjust the header values to the appropriate values where possible. Unfortunately, not all header values can be restored to the original values since some information is irretrievably lost. Therefore it is not guaranteed that all repaired executables will run again, although most will. This is particularly the case if the integrity of the binary is checked using a checksum or digital signatures. Finally, the infection marker in the MZ header is removed.

After performing these steps, all parts of the virus code are removed and the original contents of the file are restored except for some of the mentioned header values. Of course, the other modifications to the system caused by the virus, like dropped files or registry entries, must also be revoked. This, however, is beyond the scope of this blog entry.

Although antivirus software today is fairly sophisticated, it should be mentioned that it is not always possible to completely restore a system to its pre-infection state. In general, it’s always recommended to reinstall the system from scratch after a virus infection has been discovered.

Markus Hinderhofer
Engine Core R&D