On a popular Bittorrent site during the last weekend there appeared a package that allegedly contains Avira AntiVir Premium and a so called keygen. A keygen is a tiny piece of software that calculates a license number for a commercial software, for free.

Now upon starting the assumed keygen, instead of providing the user with a serial number, it infects the system. It drops three files on the hard disk:
<%AllUsers Profile%>\Local Settings\Application Data\scvhost.exe
C:\Sys.exe
C:\autorun.inf

The dropped scvhost.exe also gets added to the autorun registry keys so it gets executed after every reboot. The autorun.inf and sys.exe aren’t only created on the system hard disk, but also on all removable drives. This seems to be the spreading mechanism of the worm.

If you take a closer look at the malware, one thing sure catches attention. At the end you find the strings “VaQxiNe-steam=1firefox=1cookies=1sandboxie=1zonealarm=1
wireshark=1anubis=1virtualpc=1keyscrambler=1startup=1usb=1task=1″. This hints that the Vaqxination toolkit got used. The construction kit has some features interesting for cybercriminals:

Fig. 2: The Malware Toolkit used to create the worm.

Further Features of the toolkit according to the advertisement of the Toolkit programmer:
- Vista UAC Bypass
- Run-as-admin Bypass
- Fully stealth
- “Legit” Windows Process
- Stronger output encryption
- Only 15 US-$ for the Toolkit.

That string seems to be the configuration that the malware creator used with the Malware Construction Kit. The features seem to work as described, for example the malware is undetectable by the Anubis sandbox system:

Fig. 1: The autorun-worm uses some anti-sandboxing tricks.

The Vaqxination Malware Construction Toolkit currently steals passwords from Firefox and Steam and also logs all keystrokes. Those log files get sent to the email account the creator has chosen before building the malware.

Avira detects the bogus key generator as Worm/Autorun.sxa with VDF version 7.01.06.18. For malware authors, keygens are a simple way to infect user PCs for a longer time already. If an antivirus solution warns from malware within such a keygen, this is nearly always a correct detection – the probability of a false positive detection is extremely low. Also the websites where such keygens usually are offered often try to infect PCs via drive-by-downloads. So be very careful when searching for software like this!

Dirk Knop
Technical Editor

The Risk Level describes the current phishing- and malware threats that we receive in real time from our sources in Internet. These threats are valid and can be accessed by any user in the Internet.

The levels are computed by comparing the amount of threats (malware and phishing separately) received in the last 24 h (called 24h threat value) to the average value from the last 30 days (called average threat value). These levels are computed every 15 minutes.

This is how the graphs with the values per day for the last 30 days looks like:

Fig. 1: Statistics per day, last 30 days

The graph with the values per hour for the last 24h:

Fig. 2: Statistics per hour, last 24h

Level 1 – Normal (Green)

Risk: Low – there is much less activity than the average we have seen in the last 30 days. This condition corresponds to no discernible malicious activity for the type of threat for which the risk level is issued. The Avira products should function and should be updated using the default settings.

Level 2 – Average (Yellow-Green)

Risk: Low to Moderate - there is relatively less activity than the average we have seen in the last 30 days. This condition corresponds to some malicious activity for the type of threat for which the risk level is issued. The Avira products should function and should be updated using the default settings. This risk level is usually “the calm before the storm”, so we advise our customers to keep an eye on our website for information and updates.

Level 3 – Suspicious (Yellow)

Risk: Moderate – there is the same activity as the average we have seen in the last 30 days. This condition corresponds to clear signs of malicious activity for the type of threat for which the risk level is issued. The Avira products should function with heuristics and generic settings enabled because it might be possible that there is a new variant of a known malware. This risk level means that some unknown malware might be starting to spread, so we advise our customers to keep an eye on our website for information and updates. Please keep the logfiles of the security products under careful observation.

Level 4 – Alert (Orange)

Risk: High – there is the more activity than the average we have seen in the last 30 days. This condition corresponds to known malicious activity for the type of threat for which the risk level is issued. The Avira products must be updated more often than the default. Do not forget to update both the signatures and the engine. This risk level means that known malware are spreading, and we strongly advise to keep the logfiles of the security products under careful observation.

Level 5 – Outbreak (Red)

Risk: Very High – there is much more activity than the average we have seen in the last 30 days. This condition corresponds to known malicious activity for the type of threat for which the risk level is issued. The Avira products must be updated more often than the default. Do not forget to update the signatures, the engine and the products. This risk level means that known malware are currently active, creating a severe risk to the infrastructure and normal operations. We strongly advise to keep the logfiles of the security products under careful observation.

Sorin Mustaca
Manager International Software Development

A common technique to make debugging harder and more time-consuming is scrambling the virus code and inserting “random” junk code that doesn’t really do anything useful. One example is the W32/Virut family. Despite already being a couple of years old, it is still one of the most active file infector families around. Its author(s) frequently update the way it tries to hide itself both from AV software and researchers.

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

According to http://www.internetworldstats.com/eu/de.htm, 61.1% from the Germany’s population in 2007 had Internet access. From these users, 56% are online every day or almost every day. Having such a widespread Internet usage, it is no surprise that there is quite a lot of activity in the Germany’s Internet scene.

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

While refining and improving our detection of the W32/Tobin file patcher malware we analysed its “infection” algorithm closer. Upon execution, it drops a DLL (usually “nikitob.dll”) and modifies executable files on the system so that they load the dropped DLL once they get started. So far nothing new or unusual.

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

While analysing a recent version of the often adapted Trojan Dropper CeeInject we stumbled over following message in the malware (in plain text):

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

Malicious exploitation of older security vulnerabilities target users of Adobe Reader and Acrobat Professional versions before 8.1.2. The vast majority of todays PDF exploit samples still target an old buffer overflow vulnerability which the Common Vulnerabilities and Exposures project lists as CVE-2007-5659, but Exploits targeting an input validation weakness described in CVE-2008-2641 are also likely to appear soon. Which means: Update your Adobe Reader and Acrobat Professional as soon as possible!

To exploit one of these vulnerabilities, the attacker just needs to execute malicious JavaScript code embedded within a PDF document on the JavaScript virtual machine (VM) of the interpreting reader. Adobe introduced JavaScript as a part of the PDF document specification with PDF 1.3. They equipped the Reader with event handlers that can invoke JavaScript functions embedded in PDF documents. The malicious JavaScript code inside the PDF gets usually triggered by the OpenAction event handler to load it immediately when the document is opened.

The OpenAction event handler is often used in malicious PDF files. Usually it follows right after the PDF Header.

By design, PDF documents should be platform independent, so PDF is not a pure binary format. A PDF document consists of objects that are referenced by an index at the end of the file, the cross reference table. The objects themselves describe what they are and how the data between their tags should be interpreted. Adobe has published the specification for the PDF document format that can be obtained in version 1.7 from Adobe’s PDF developer center

In May ‘08 most malicious PDFs made use of the PDF format’s own security mechanisms to deliver their embedded payload. Today’s PDF exploits renounce this kind of invasion technique and start using obfuscation techniques usually known from web-based malware. Script packers as well as custom obfuscation functions made their way into malicious PDF documents. The challenge for AV vendors is now the extraction of the JavaScript Object and the detection of an exploit attempt in (sometimes) highly obfuscated script code. The relationship from malicious JavaScript code in PDFs to malicious JavaScript Code found in malicious websites makes it possible to face this kind of thread with similar generic/heuristic rules.

Scanning scripts “hidden” in PDFs is as easy as scanning scripts from webpages for Avira because of the modular architecture of the engine. One of the advantages of the new AV8 engine design is the close cooperation of the modules: Prior to the AV8 Engine our HTML heuristics were only able to detect malicious code in websites. Any file can be dissected into it smallest parts, ready for extensive examination by specialized components – the modules – of the engine.

As we explained before, PDF files consist of objects like images, texts and scripts. They can be used as a simple example for this new engine ability and it’s advantages.

• First, a file is passed to our scan engine for analysis. As it is a PDF file, it may be dangerous.
• After a first quick scan with patterns of malicious software the central control decides to forward the PDF file to a part of the engine which is able to extract the single parts (like texts, pictures and scripts) from the PDF.
• Very often the scripts are ZLIB compressed. In these cases the module also decompresses the scripts.
  

  Zlib-compressed JavaScript object of an exploit PDF from the ElFiesta web-exploitation toolkit.

  

  The AV8-engine decompresses that object which contains a slightly obfuscated JavaScript exploit.

• All the extracted parts of the PDF get returned to the central control which is now able to decide how to further process these parts.
• The scripts are passed to the standard generics detection,
• After that they are forwarded to the html and script heuristics.
• The script heuristics was written to detect exploits in web pages and to find drive-by-download attacks before they enter the browser on the users’ PC. And of course it is able to process and judge the probability of malignancy of the embedded script of the PDF.
• The script heuristics identifies a JavaScript, analyses it and recognizes a shellcode being build as well as an exploit.
• Sufficient data to alert this as HTML/Shellcode.Gen?

Other PDFs containing malware get detected as “HEUR/HTML.Malware”, “HTML/Rce.Gen”, “HTML/Shellcode.Gen” or “HTML/Crypted.Gen” depending on the exact method the malicious scripts use to hijack the victims computer.

A more detailed insight into the html malware heuristics will be subject of a future article.

Emanuel Somosan
Thorsten Sick
Web-based Malware Team