The Latest in IT Security

In recent days, the avast! Virus Lab has observed a high activity of malware distributed through exploit kits. Most cases of infection are small websites which usually provide adult entertainment, but there was also news about one of the top 300 visited websites being infected.

Infection chains ended dropping a final payload in a form of an executable file with a constant, not wide-spread name like 1SKKKKKKK.exe. After a closer look, we found that this filename is shared among aggressive malware threats – banking Trojans like Win32:Citadel, Win32:Shylock/Caphaw, Win32:Ranbyus, Win32:Spyeye; stealthy infostealers like Win32:Neurevt (a.k.a. BetaBot), Win32:Gamarue, Win32:Cridex, Win32:Fareit; and even file infectors like Win32/64:Expiro(infected dbghlp.exe).

We received ~1000 unique samples in the last 10 days which possess suspicious filenames, polymorphically covering ~30 malware families with many different packers. Researching infected iframes in our databases, we discovered an infection chain which leads to a payload with a strange name that looks like this:

As mentioned in our recent blog about small hacked websites, an exploit kit starts with a test of possible vulnerabilities of the victim’s system. This can be done by detecting versions of software in which exploitation is available (denoted as Plugin Detect in the scheme). To avoid signature detection, an obfuscation level containing the proper script is added:

The proper script changed after putting in a detection signature. We can see a window lasting for a few hours where it was detected in the wild:

Internet Explorer exploit

Let’s start with the branch affecting Internet Explorer. Similarly, as in the case of the plugin detect script, the exploit itself is evaluated after extraction from a wrapper JS script:

The target of the exploit named CVE-2013-2551 are versions 6 through 10. The analysis of the mechanism has been described by VUPEN Security. We tried to reproduce those interesting methods manually and we got the following gate to the shellcode:

An execution is controlled by overwriting a crucial pointer with a precious manipulation that is used in the procedure COADispatch::AddRef(). The call redirects flow to the first appearance of the gadget (byte sequence 0x8B 0?01 0xFF 0?50 0?04) in vgx.dll library which represents “mov eax, dword ptr [ecx]; call dword ptr [eax + 4]” in x86 assembly. These two instructions redirects the flow into the sequence of gadgets located in ntdll.dll involving changing execution flags of memory area with shellcode. After that, the execution arrives at the proper shellcode:

A distribution we can roughly estimate by displaying hits with AVAST’s script shield. We see a massive interaction, with tens of thousands per week:

Oracle Java exploits

CVE-2012-1723

A good write-up of the mechanism of this exploit has been done by Symantec in July 2012. After the process of deobfuscation, we got a similar Java code as described here which helps up in the identification of the vulnerability. Basically, the first step is the break out of Java Sandbox and then exploit the vulnerability based on confusion between a static variable and an instance variable. The URL is obtained by the DecodeAndExec.decode method from the value of an applet parameter ur0l0 and it is downloaded in the final step. A constant pattern SKKKKKKK for the downloaded file name and the execution method is visible:

CVE-2013-2460

This branch uses Java Security Warning Bypass (a pop-up window that warns against launching an unsigned Java applet is disabled) by loading a JNLP script. The cause of vulnerability is an insecure use of invoke method of java.lang.reflect.Method class (documented and PoC coded by Security Explorations).

CVE-2013-2423

This branch is also uses the Java security warning bypass by loading a JNLP script.

Disabling the security manager is performed by changing Double.TYPE to Integer.TYPE and then using reflection to copy an integer field from one object to another, but because of the patched TYPE fields reflection thinks the integer field is a double and copies 8 bytes instead of 4 (more details here).

Adobe Acrobat exploit

This branch of exploitation is not new at all. The document contains an embedded XML script with a JavaScript defined as a XFA form template (it is called when the form is initialized). As described in the reference, obfuscated JavaScript (depicted as JS wrapper 3 in our scheme) decrypts the buffer obtained by concatenating two deflated raw streams of the PDF file. The result is another obfuscated JavaScript which finally realizes CVE-2010-0188 exploitation. The shellcode is obtained through this:

And the shellcode itself dynamically is similar to the IE case:

Calling the procedure starting at 0x6A from position loc_176 leaves the address of the following instruction on the stack (and indeed it is the offset of the displayed url). Popping the value into the ESI register makes it available for the urlmon!URLDownloadtoCacheFileA call.

Payload

Win32:Spyeye

This banking Trojan has been known for a very long time. The advantage of this fact is that the communication protocol is very well known so we could reconstruct the  data we received easily:

Using Config Builder, a tool that is available in the Carberp leak, we can see actual webinjects the Trojan uses to compromise remote banking pages (text boxes for Telephone Number and Signing Key should definitely NOT be there):

Win32:Viknok

This banking Trojan surprised us with advanced methods of stealthiness, like multiple code injection and persistence. Outer layers are custom packed as we are used to. Then a dropper part is extracted and it injects into the explorer process in order to execute Drive-by-download content which contains a proper payload. A brief explanation of functionality is here.

Conclusion

Knowing how infection chain works is necessary to understand how to be secure against it – no matter if attackers infect a small website with a small fan base or they manage to run a waterhole campaign on a mainstream portal. The first thing that helps against exploitation is an updated system and updated software products that are under permanent attack like those we mentioned. The second thing is an updated AV product. Nowadays, most of them have methods and technologies to prevent every step of the infection chain. Naturally, it is better to stop the initial malicious scripts, .jar archives and .pdf documents and to block compromised url. And often this is the case. Usually, we observe that the final executable payload does not have so many hits (considering a single signature, a checksum detection or any other non-algorithmic way of identifying malware). The reasons are obvious: The focus of attackers and distributors is to have files as polymorphic as possible and that, and this is positive fact, the chain of distribution quit on earlier steps.

Sources

SHA256 hashes of some selected samples and how they are covered within the AVAST engine:

Acknowledgements

Thanks goes to my colleague, Jaromir Horejsi, for cooperation on this analysis.