The Latest in IT Security

Fallout from Nuclear Pack exploit kit highly toxic for Windows machines


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


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:



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).


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.



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):




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.


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.


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

Plugin Detect 24F1FA4FEA50DDF0C14F89246B0C9CFD8A16E9E0F
JS:Nuclear-A [Expl]
IE exploit D891EC6EC3AF19E7C4F010BFB9A253076258AE173A
JS:CVE-2013-2551-B [Trj]
Java exploit 5FD371442F63FDCAFD82B7E45AE142C199AC5BC088C
Java:CVE-2013-2460-A [Expl]
Java exploit 76C3ABFBACA39985361CA4B0AB497CFE62070422A30D
Java:CVE-2013-2423-BM [Expl]
Java exploit A0500CB7903E4ADD3682E0B301D258CE3C195C20CE76
Java:Agent-GWC [Expl]
Acrobat exploit DE908D5EEB398F68E35B5FBDD7E0AF20922657E42450
JS:Pdfka-BXT [Expl]
Win32:Spyeye D0F919B897F20B9644E9935790EC448423C2CFC1005
Win32:Expiro 1D808F88D4B8044A9291B71AAA2C4DEC0A3E0FDD747
Win32:Expiro-CW [Cryp]


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

Leave a reply


MONDAY, MARCH 19, 2018



Latest Comments

Social Networks