Saturday, August 30, 2014

A look at the new Gameover Zeus variant


Zeus, also known as Zbot is one of the most notorious and wide-spread information stealing banking Trojans. It was first spotted in early 2007 and since then over the years it has evolved into a very sophisticated malware family with such features as:
  • Man-in-The-Browser keystroke logging
  • Form grabbing
  • Web injects
  • Kernel-mode rootkit update
  • Custom Peer-to-Peer (P2P) protocol for Command and Control communication
  •     Domain name Generation Algorithm (DGA)
  • Mobile Zeus, also known as Zeus in the mobile (Zitmo)
In June 2014, the U.S. Justice department launched an international law enforcement operation dubbed 'Operation Tovar'  to take control of the Gameover Zeus P2P Botnet. This operation turned out to be a success with the shutdown of the Botnet activity and related Cryptolocker infection cycle.

New Gameover Zeus variant

We started seeing infection reports involving a new Gameover Zeus variant early last month (July 2014). The major infection vector still remains the same where the Cutwail Botnet is being leveraged by the cyber-criminals to send out spam e-mails with a malicious attachment. The malicious attachment on most occasions masquerades as a financial PDF document in order to lure an unsuspecting user into opening it. This is achieved by a combination of a fake PDF icon and double file extension as common file extensions are hidden by Windows unless disabled by the user. Some sample filenames we have seen includes:
  • Invoice.pdf.scr
  • E-statement.pdf.scr
  • Securedoc.pdf.scr
Once the user opens the attachment, it downloads the latest Gameover Zeus variant from a predetermined location as seen below in the unpacked payload memory:

Decrypted payload showing hardcoded URL
Download of latest Zeus variant
The downloaded Gameover Zeus variant further drops a copy of itself and runs it as:
  • %Local Settings%\Temp\Eqxav\epoxs.exe
It also drops and runs a batch file to delete the original executable file from the %TEMP% directory:

"C:\WINDOWS\system32\cmd.exe" /C "C:\DOCUME~1\zuser\LOCALS~1\Temp\MLZ6405.bat"

@echo off
del /F /Q /A RSHAIL "C:\Documents and Settings\zuser\Local Settings\Temp\mss3.exe" >nul
if exist "C:\Documents and Settings\zuser\Local Settings\Temp\mss3.exe" goto akkaoz

It creates the following registry entry to ensure persistence upon system reboot:
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ Epoxs = "%Local Settings%\Temp\Eqxav\epoxs.exe"
The bot further injects code into multiple system processes including Explorer.exe. It creates a remote thread that is responsible for running the Domain name Generation algorithm and connection to the Command & Control (C2) server. Upon successful connection to a C2 server, the bot will download the latest configuration containing list of banking URLs and web-inject plugins. Below is the list of sample domains that were generated by the DGA thread:
  • 1vi2us1syijqh1gmhwuxmr1iwt[.]com
  • 1i5ch6c1rvz8y7rp9bkbzme3v4[.]net
  • cul4hleyh07we1j2cc1ma964m[.]org
  • 1l9asc2b3mmf3dpth1d1ct987[.]net
  • w7vld0891u1d1lhbvh17b5lfo[.]com
  • 1aipcuziz5kqakplu9c5upujb[.]org
  • uccm0d1tdx38tonp9vh1jo2fq4[.]biz
  • i8gwl8hwjijd1ldh10ovl05iu[.]org
  • qxvt8m18q3wbf12992zo16mx3rb[.]com
  • 14h98mo70orwoj8gf9j1a6sz4r[.]net
  • hv1eifdb3pxw1fp250cnpe34f[.]biz
  • 17f2nku9i6zbtzs1u1v1pih3ie[.]net
  • 1hn3lbe1qwdo6k1qm3b0q1yklg1r[.]com
  • ukoizw1g9vy8c1jxlh7610o2h8z[.]net
  • zja38vktoo9i1yc8xk16sq76p[.]biz
  • 1ahnharg5apuxe5oeex1qy80ql[.]org
  • 1qozjh16vj4xz1rhcr31x7hrtf[.]com

It also enumerates through all the running processes and steals information from them if any of the following strings are present:

Decrypted list of finance & banking related strings
Feature evolution or de-evolution

The previous Gameover Zeus variant used a P2P command and control protocol in addition to a failover domain generation algorithm (DGA), to establish connection with a C2 server. However, this newer variant does not feature a P2P command and control protocol, instead it is falling back to the old DGA with fast flux tactics to hide the C2 servers. This in our opinion is a step backward as P2P was a more resilient feature.

Another step backward that we observed is the absence of the kernel-mode rootkit that was pushed out as an update early this year by the Gameover Zeus operators in the previous version. The rootkit made removal of the malware extremely difficult and disabled multiple security features on the infected system.

DGA active domains and Command & Control server trends

The bot's DGA outputs 1,000 new unique domains each day but the Gameover Zeus operators are keeping the domains that they intend to use confidential until a few hours before the actual day when they get registered. Below is the mapping of DGA domains that were registered by the the Botnet operators and were actively resolving to C2 servers in past seven days:

Command and Control server IP information and Geo-distribution map:

Active C2 Server location and ASN information

Below is the trend of C2 callbacks we have intercepted in past seven days:

One of the most active C2 server IP addresses also appeared to be the Control server for a Zeus in the mobile (Zitmo) variant in the past as seen below:

This further re-affirms the fact that the same gang is involved.


This new Gameover Zeus variant certainly appears to be the beginning of a comeback attempt for this notorious Banking Trojan Botnet family, but in many ways it has been a step backward. The number of infections are still very low and it has a long way to go to reach the infection rates observed prior to the Government takedown. Zscaler ThreatLabZ will continue to monitor the activities of this Botnet family in the coming months for active C2 servers as well as any feature updates and will ensure protection for customers.

- Deepen Desai

Monday, July 28, 2014

Dissecting the CVE-2013-2460 Java Exploit

In this vulnerability, code is able to get the references of some restricted classes which are cleverly used for privilege escalation and bypassing the JVM sandbox. The vulnerable “invoke” method of the “sun.tracing.ProviderSkeleton” class is used to issue calls to the Class.forName() method for loading internal restricted classes and methods.

Vulnerability Exploitation Procedure
To define tracepoints in any Java application, one must extend the Provider interface in their program. Creating a Provider instance is done with the help of the factory class ProviderFactory. ProviderSkeleton gives all the implementation needed by a framework provider by implementing two important interfaces, namely “com.sun.tracing.Provider” and “java.lang.reflect.InvocationHandler”. As mentioned earlier, it also has the implementation of our target “invoke” method. Invoke is the default invocation handler associated with Provider class and is created when we call the “Java.reflect.Proxy.GetInvocationHandler()” method with a Provider class object as parameter.
So, the code for this would be:
<Invoke object> = class.forname(java.lang.reflect.Proxy).getmethod(getInvocationHandler), new Class[] { Class.forName(java.lang.Object) }).invoke(Class.forName(java.lang.reflect.Proxy)), new Object[] { <Provider object> });

Class.forName is the dynamic Class Loader in Java. It initializes a class by calling its static methods and constructors, if the class was not previously not being loaded.
The following restricted classes are loaded in the exploit using the <invoke object>:
  •      “”
  •      “”
  •      “”

There is a call to the “MethodHandles.Lookup()” method which does the AccessController checks only while creating the class instance and not each time the call is made. A lookup object has the capability to access any method handle that the caller has access to.
Context stores some information about the program like the call stack. To associate the newly created context with the current thread, an object of the “enter()” method of the “” class is created using the lookup object we created. Similarly, method objects for “defineClass()” and “createClassLoader()” from the other two classes are also created. All these three objects are eventually used to disable the SecurityManager enforced by the browser for running Java code.

Privilege Escalation!
Typically, a web applet runs with the SecurityManager provided by the browser. This way, user code does not have the privileges to disable it. In our case, we are able to invoke restricted browser libraries and generate a new ClassLoader. So, this ClassLoader is of the same context as that of the SecurityManger. Finally, defineClass loads the binary object of another class using the privileged ClassLoader and sets the SecurityManager to null after it has successfully performed the bytecode verification.
We will get into this more when we go through each step in detail.

Test Case: Flashpack EK
The malicious jar files we found in multiple exploit kits (EKs) use different types of obfuscation to make them undetectable. In this blog, I will be explain the analysis of a jar file we found in the Flashpack EK, which was using the same exploit. The file can also be downloaded here.
The jar file runs as an applet in the browser and is triggered from the EK’s landing page after it has checked the Java version installed. The jar contains following classes:

Java Code Deobfuscation Routine:
Code generates strings from garbage text by calling “crock.zam()”. The following three methods perform all of the deobfuscation routine:

The entry point class “a1.class” needs the following three parameters: “urla”, “t” and “tt”. The code proceeds with creating an object of “crock.class” and calling “badafzew()” method. 

In “crock.badafzew()” creation of following three objects takes place:
  1. The contents of “pashka.class” is fetched as a stream and stored in a byte array object of size 8KB, but it is utilized later in the program for disabling the SecurityManager. 
  2. In the next step, “b3333.cadvsfew()” is called in which the Provider object is created using the ProviderFactory mechanism.
  3. A call to GetInvocationHandler() returns an object of the vulnerable “invoke()” method.
The execution is then transferred to “nano.allokas()”, passing all three objects created as parameters.  In the “allokas()” method, an object of “cve.class” in created, which gives us the following two important static method objects:
The invoke() method object is used for the first time to generate class objects of two restricted classes as follows:
Using these class objects, two method objects are created for enter() and createClassLoader()methods.
The last step is to perform an invoke action on the “” methodhandle and pass a byte object of “pashka.class” as a parameter. This results in successful disabling of the SecurityManager.
Now that the SecurityManager is disabled, the applet is free to perform privileged actions like saving files on the user machine, downloading data and performing file execution. All this workflow is performed in “nasa.class”, which I am not discussing in this blog as it is easily understandable as shown below.

JavaScript Deobfuscation:
To prepare a POC of the exploit, along with the jar file, the html page calling the applet is also important, because it sends the parameters needed for jar execution. But exploit kit landing pages are found to be highly obfuscated and it’s not at all easy to decode the parameters.
In case of Flashpack, we filtered the following traffic:

After deobfuscating the JS and extracting some useful content, we get:

Yara Signature:
Even though the jar files used by EKs have highly obfuscated code, some of the strings still can’t be obfuscated and we can use such patterns in our static analysis. And if we are lucky, we can develop accurate detection methods. The following signature can be used for exploit identification on a decompiled jar file.