Most drive-by exploit kits use a minimal exploit shellcode that downloads and runs the final payload. This is akin to a two-stage intercontinental ballistic missile (ICBM), where the first stage — the exploit — puts the rocket in its trajectory, and the second stage — the payload — inflicts the damage.

In the cyber crime world, the decoupling of the first stage from the payload is designed to ensure that exploit kits are as generic as possible and can deliver all possible payloads, provided that the payloads only need native execution, either as a stand-alone executable — files with a .exe file extension — or DLL registration via RegSvr32 — files with a .dll extension.

g01pack: Breaking the Exploit Kits Mold

The IBM research team recently found that a Java exploit kit called g01pack has added another mid-course stage, turning the infection process into a multistage attack. The first stage of the attack, the exploit shellcode, executes a second stage in which a Java class runs in a separate Java process. This second Java process then downloads and runs the final payload. We believe this discovery represents the first instance of an exploit kit delivering its payload via a multistage attack.

Why would an attacker need a multistage exploit? To extend the ICBM analogy, in much the same way that an ICBM uses multiple stages to obtain a longer range, the attacker uses multiple stages to distance the attack launch site from its final destination. By utilizing an extra stage, the attack is more likely to bypass some security products; the initially exploited process (Java) launches another Java process (the second stage) that appears less suspicious, and only that second-stage process runs the final, native payload (the persistent malware dropper).

This is supported by the analysis we performed using various security tools and the poor detection rate we observed. Out of 46 tools tested in file-scanning mode, only eight tools identified the first-stage JAR as malicious, and only two identified the second-stage class (cabOrgies.class) as malicious.

We observed this multistage exploit approach in one of the vulnerabilities exploited by the g01pack exploit kit: the well-known Java vulnerability CVE-2012-1723, which dates back to mid-2012. This vulnerability allows the exploit to break out of the Java sandbox. It has long since been patched by Oracle, but apparently, there are enough unpatched targets to make this attack worthwhile.

Figure 1: Exploit Kit g01pack — Multistage Attack

Although the Java exploit we researched is part of the g01pack exploit kit, it is interesting to note that some implementation details are similar to the exploit used by BlackHole for CVE-2012-1723, identified in mid-2012 (as described in a Symantec blog post). The BlackHole approach, however, was a typical exploit payload scheme, not the exploit-intermediate process-payload scheme we see here.

The final payload is, of course, malware. We noticed many malware families being distributed by this specific exploit kit, such as Zeus, Torpig, Gozi, Shylock and likely many others. The exploit kit is used to infect targets globally, with an infection rate estimated at 1 in 3,000 machines per month infected by payload executions from this exploit kit alone as of mid-2013. This very high infection rate proves the effectiveness of this multistage approach. Therefore, it is highly likely that other exploit kits will incorporate a similar approach.

Stage 1: Exploiting CVE-2012-1723

Stage 1 begins when the browser navigates to a Web page that contains HTML code and an Applet tag. When the browser renders the content of the Web page, the Applet tag instructs the browser to launch a Java class from a URL designated in the Applet tag using arguments given in the Applet tag. These arguments contain the encrypted URL of the final payload — this can be a Windows executable (parameter name is “date”) or a Windows DLL file (parameter name is “guid”).

For example, the Applet tag would be:

This instructs the browser to launch Java (the “javaw.exe” process) with the JAR URL (in our example, the “[example].jar” is located in the same host and folder originally accessed by the browser), the class name (package “critical,” class “securityupdate”) and the parameters (in our case, “date,” whose value is a long encrypted string that represents the URL of the final payload).

Java then retrieves the JAR URL and invokes the Applet class from the package.

The JAR File

The malicious JAR file implements a Java package called “critical,” and contains six Java classes (.class files):

Java starts by running the init() method of the Applet class “securityupdate.” This function first ensures that it is running on a Windows platform and that the JRE version is not “1.7” (i.e., it ensures it does not run on Java 7; in fact, the exploit will succeed only for Java versions 6u10-6u32 inclusive). Next, the function uses the Java class “entry” to exploit CVE-2012-1723 and escape out of the Java sandbox. A patch for this vulnerability is available, but apparently, there are still enough unpatched Java 6 installations to make it a valuable target for exploit kit writers.

A successful exploitation results in running the method “JiXU” of class “keaVestAltho” with high privileges. This method contains a hard-coded encrypted string, which represents the “in memory” class “remoterEhPoplin.” The method decrypts the string, creates the class from it and invokes the class constructor with three arguments: the Applet’s “date” parameter, the Applet’s “guid” parameter and a byte array representing the second-stage class “cabOrgies,” which the method copied into memory from the corresponding JAR resource.

The constructor for class “remoterEhPoplin,” the “in memory” class, has the following flow:

As you can see, in steps 5 and 6, the Java process launches another new Java process with a copy of the second-stage class. Note that the “date” and “guid” parameters of the Applet tag (which contain the payload URL in an encrypted form) are transferred as-is in the Java invocation command line. The EXE/DLL indicator becomes the third parameter (set to “0” for EXE or “1” for DLL).

For the example above, the following command will be executed:

This launches Java (javaw.exe) in a new, minimized window with an empty title.

Stage 2: A New Java Process

A new Java process is launched with the working directory set to %TEMP%. This directory includes a package (folder) called “critical,” which includes a class file called “cabOrgies.”

The Java process is launched with four command line arguments: “critical/cabOrgies,” “main” (ignored), the encrypted URL and an EXE/DLL indicator. This instructs Java to invoke the main method of the class cabOrgies found in %TEMP%\critical/cabOrgies.class with a string array containing the following three command line arguments: “main,” the encrypted URL and the EXE/DLL indicator.

It follows this workflow:

As you can see, Step 3.g runs the final payload.

In our example, the encrypted URL string is decrypted into:

The host name no longer has a DNS resolution, however, which is hardly surprising.

Java Obfuscation

The Java code in both stages is heavily obfuscated. Four different obfuscation methods are applied (some of them probably via an obfuscation tool):

• Dummy code is inserted in a seemingly random fashion between real operations. The dummy code is mostly calling functions (with no argument, with a string argument or with an integer argument) that immediately return.
• Function (method) names are randomized.
• Most strings are encrypted at the class file and only get decrypted in runtime (the encryption scheme is a cyclic XOR with a hard-coded key).
• Java reflection is used to bind to functions in runtime.

The obfuscation instances change rapidly, and it’s quite common to see two to three different versions in a single day — so, we don’t expect to see “cabOrgies” a few days from now. Some names take longer to change. For example, the package name used to be called “oracle” in early April, and for the past few weeks, it has been called “critical.”

Raw Data

Conclusion

The g01pack is among the most successful exploit kits available today. It executes a drive-by download attack that results in the silent installation of malware. Using the multistage attack, the g01pack exploit kit can effectively distribute advance malware that evades detection by existing security controls.

I’d like to thank Assaf Friedman from the IBM Trusteer security group for his help collecting the data for this blog.