Monday, September 8, 2014

RIG EK outbreak continues

During daily data mining activities, we observe continual outbreaks of many exploit kits (EK) such as RIG EK. Logs are monitored and analyzed to come up with new protections, which are eventually deployed in the Zscaler cloud. The dynamic nature of EK’s landing page code, presents a constant challenge in providing generic detections. We need to take a look at various aspects of EK’s such as URLs/Domains/IP’s to come up with a generic detection guidance. In this regard, log analysis plays an important role. 

In this blog we'll take a look logs from  last week (8/28/2014 - 9/5/2014), observed for RIG EK.

RIG EK Traffic (%)
The above chart illustrates the traffic trend of RIG EK over the past week. There was a significant spike noted on Sept. 4th. 

Sept 4th Domains/IP:

Domains IP
eir.alexandrajarup[.]com 194.58.101[.]24
eir.alexandrajarup[.]com 194.58.101[.]24
uiue.nuiausqas[.]com 194.58.101[.]24
iow.alanmccaig[.]com 191.101.14[.]125
ods.alankellygang[.]com 191.101.14[.]125
uew.alankellygang[.]com 191.101.14[.]125
soi.alankellygang[.]com 191.101.14[.]125
eur.alankellygang[.]com 191.101.14[.]125
sod.alankellygang[.]com 191.101.14[.]125
soa.alankellygang[.]com 191.101.14[.]125
lol.alankellygang[.]com 191.101.14[.]125

Sept 4th EK URLs:


Sept 4th common URL pattern:

[.]com/?PHPSSESID=njrMNruDMh7HApzBKv7cTKZNKU7YHVnYmMzMhe6JVg

RIG EK landing page content:

RIG EK Landing Page
Code analysis of the landing page shown above is not discussed here. For a full code analysis, please take a look at our blog post from last month. In that blog, we tried to come up with a generic de-obfuscation technique that helps to de-obfuscate the EKs such as RIG and Fiesta.

Let's now take look at the overall traffic distribution by IP for the last week (8/28/2014 - 9/5/2014).

Traffic distribution by EK IP's
Traffic was observed from 13 unique IP addresses. IP '191.101.14[.]125', was seen to be spreading the EK's in large volumes. We also observed many IP addresses falling into three subnets.

194.58.101[.]XXX
191.101.13[.]XXX
191.101.14[.]XXX

We recommend blocking the aforementioned IP's. Subnet level blocks can also be used but we have to be bit cautious when doing so as legitimate sites may also be hosted in the same range.

The following world map illustrates the geographical distribution of the EK IP's which have been observed. As noted, most activity is emanating from Russia. 


Geo-graphical distribution by EK IP's
No geo-location information was available for IP's falling into '191.101.XX.XX' subnet.

Below is the full list of domains and IP's seen for the previous week.

Domains IP
tue.allthatsin[.]com 178.132.203[.]113
qie.allthatsin[.]com 178.132.203[.]113
dfu.aloliskincare[.]com 194.58.101[.]38
uer.alistairnunes[.]com 194.58.101[.]31
eir.alexandrajarup[.]com 194.58.101[.]24
oweuryt.account-ltunes[.]com 191.101.13[.]139
teyruyt.a[.]commodationinsauze[.]com 191.101.13[.]139
weorioi.a[.]commodationinsauze[.]com 191.101.13[.]139
owiery.wikusbotha[.]com 191.101.13[.]140
nuaysuq.planeimpressions[.]com 5.31.72[.]115
suyfdys.online-moneymakingsystem[.]com 5.31.72[.]115
iuiweyr.online-moneymakingsystem[.]com 5.31.72[.]115
oweiru.laughterisgoodmedicine[.]com 5.31.72[.]115
woiero.laughterisgoodmedicine[.]com 5.31.72[.]115
aosidoa.kensymicek[.]com 191.101.13[.]202
sdfusug.kensymicek[.]com 191.101.13[.]202
qwieuu.kensymicek[.]com 191.101.13[.]202
iuasid.kensymicek[.]com 191.101.13[.]202
odigoud.helny[.]com 191.101.13[.]202
qoiweur.helny[.]com 191.101.13[.]202
miiuis.helny[.]com 191.101.13[.]202
oeriouh.francisssmith[.]com 191.101.13[.]202
dciugi.francisssmith[.]com 191.101.13[.]202
gdofigu.forgottenapples[.]com 191.101.13[.]201
miqwue.boxsteravatar[.]com 191.101.13[.]200
popoqwe.dukeanddiva[.]com 191.101.13[.]201
mbivuc.click2maps[.]com 191.101.13[.]201
oiqwour.click2maps[.]com 191.101.13[.]201
mbivuc.click2maps[.]com 191.101.13[.]201
oiqwour.click2maps[.]com 191.101.13[.]201
oiaosdu.bluffswebdesign[.]com 191.101.13[.]201
dwieru.bluffswebdesign[.]com 191.101.13[.]201
nuasiud.amiramatthews[.]com 191.101.13[.]200
miuggid.748tmp[.]com 191.101.13[.]200
owierowu.748tmp[.]com 191.101.13[.]200
eoitoe.boxsteravatar[.]com 191.101.13[.]200
miqwue.boxsteravatar[.]com 191.101.13[.]200
wueriq.boxsteravatar[.]com 191.101.13[.]200
naduq.00tim[.]com 191.101.13[.]198
miasud.bigredshed.org[.]uk 191.101.13[.]198
qiuwer.121sky[.]com 191.101.13[.]198
digudyfg.belucent.co[.]uk 191.101.13[.]196
woiero.beauchamplondon.co[.]uk 191.101.13[.]196
eir.alexandrajarup[.]com 194.58.101[.]24
uiue.nuiausqas[.]com 194.58.101[.]24
iow.alanmccaig[.]com 191.101.14[.]125
ods.alankellygang[.]com 191.101.14[.]125
uew.alankellygang[.]com 191.101.14[.]125
soi.alankellygang[.]com 191.101.14[.]125
eur.alankellygang[.]com 191.101.14[.]125
sod.alankellygang[.]com 191.101.14[.]125
soa.alankellygang[.]com 191.101.14[.]125
lol.alankellygang[.]com 191.101.14[.]125
kick.alankellygang[.]com 191.101.14[.]125
sdifu.alanhalldriving[.]com 191.101.14[.]125
pqqie.alanhalldriving[.]com 191.101.14[.]125
weoriuwyt.alanhalldriving[.]com 191.101.14[.]125
oigydfg.alanhalldriving[.]com 191.101.14[.]125
oiweyr.alanhalldriving[.]com 191.101.14[.]125
fgydy.ajrobertsconsulting[.]com 191.101.14[.]125
husaus.ajrobertsconsulting[.]com 191.101.14[.]125
super.affogatomoments[.]com 191.101.13[.]139
iuweryw.activity-partners[.]com 191.101.13[.]139
weorioi.a[.]commodationinsauze[.]com 191.101.13[.]139
owiery.wikusbotha[.]com 191.101.13[.]140
oiqwour.click2maps[.]com 191.101.13[.]201
oiaosdu.bluffswebdesign[.]com 191.101.13[.]201
dwieru.bluffswebdesign[.]com 191.101.13[.]201
owierowu.748tmp[.]com 191.101.13[.]200
eoitoe.boxsteravatar[.]com 191.101.13[.]200
miqwue.boxsteravatar[.]com 191.101.13[.]200
qiuwer.121sky[.]com 191.101.13[.]198

The above trend shows a continuous outbreak of RIG EK in the wild. Data mining logs for such activity provides us with a sense of the trends being followed by the attackers. We will keep on sharing such information via blogs/scrapbook posts. 

Stay tuned! 

Pradeep

Friday, September 5, 2014

Nuclear Exploit Kit and Flash CVE-2014-0515

For this blog, we'd like to walk you through a recent attack involving Nuclear Exploit Kit (EK) that we analyzed. It was found leveraging CVE-2014-0515, a buffer overflow in Adobe Flash Player discovered in April 2014.

Nuclear Exploit kit targets a number of known vulnerabilities including:
Below are the files which were downloaded during the exploitation attempts observed:

FILE TYPEMD5SIZECVE/THREATVT HITS
FLASHA1465ECE32FA3106AA88FD666EBF8C785614CVE-2014-051518 / 53
JARA93F603A95282B80D8AFD3F23C4D488912396CVE-2012-050726 / 54
PDF19ED55EF17A49451D8052D0B51C662399770Exploit.PDF-JS22 / 54
EXE8BCE8A59F9E789BEFB9D178C9A03FB66104960Win32/Zemot39 / 53

Although there are other associated vulnerabilities that are being exploited by Nuclear Exploit kit, we will limit this blog post to reviewing the Flash exploitation (CVE-2014-0515).

Nuclear EK Landing

Unlike other EKs such as RIG, Nuclear EK's landing page code is highly obfuscated.


(Fig 1: Obfuscated Landing Page)

After de-obfuscation, the page looks as follows:

(Fig 2: De-Obfuscated Landing Page)

Nuclear EK's landing page checks for the following antivirus (AV) driver files and if finds any, terminates the exploitation process. We have seen these checks before in RIG EK too.

(Fig 3: Check for AV driver files)


If this AV check is passed, a javascript function then checks the installed Flash version and if a vulnerable version is detected on the client's browser, a call is then made to a dynamic Flash object creation module.

(Fig 4: Flash Call)

Here are the vulnerable Flash player checks:

(Fig 5: Checks if vulnerable version installed)

If the version check passes, the Flash exploitation process will commence as seen below.

CVE-2014-0515 exploit analysis

Here is the code that dynamically creates a new Flash Object:

(Fig 6: Flash Object Creation)

The Flash exploit payload that gets downloaded is highly obfuscated to evade AV detection. Below is a snippet of decompiled code from this Flash exploit:


(Fig 7: Decompiled Flash File)

There are two hard coded snippets of obfuscated shellcode in the action script as seen below:

(Fig x1,x2: Raw Shellcodes)
 

After de-obfuscating on the run time, it adds bytecode to a Shader Object from one of the de-obfuscated shell code snippets.


    (Fig 8: Shader Byte Code Filler)

The Shader's Pixel Bender is where this malformed byte code is written, which triggers the vulnerability.

Here is the Malformed byte code:

(Fig 9: Malformed data for Pixel Shader)


Disassembling Pixel Bender's byte code

We used Tinc Uro's program to get the PixelBender binary data decompiled.


(Fig 10: Decompiled PixelBender data)

We can see the inappropriate content here. The Shader Object takes a float parameter whose default value is set to a matrix of 4x4 floats and the second float value of this matrix is invalid value triggering the vulnerability.

Conclusion

Since the downfall of the popular Blackhole Exploit Kit, we have seen the advent of many new Exploit Kits. Nuclear Exploit Kit definitely ranks in the Top 5 prevalent EKs in the wild at the moment. We have seen an increasing number of compromised sites and scam pages leading to Nuclear Exploit Kit in past three months. Some of the notable compromised sites during this time frame that were redirecting to Nuclear EK includes:

SocialBlade.com - A youtube statistics tracking site.
AskMen.com - Men's entertainment website
Facebook.com survey scam pages

Exploit kits generally make use of known vulnerabilities and Flash is a popular target. CVE-2014-0515 in particular targets a Flash vulnerability in Flash versions before 11.7.700.279 and 11.8.x through 13.0.x before 13.0.0.206 on Windows and OS X, and before 11.2.202.356 on Linux. It's critical to ensure that your employees aren't running outdated versions of Flash as it is commonly targeted by EKs.


References:

Saturday, August 30, 2014

A look at the new Gameover Zeus variant


Background

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
:akkaoz
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.

Conclusion

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



Introduction
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():
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>:
  •      “sun.org.mozilla.javascript.internal.Context”
  •      “sun.org.mozilla.javascript.internal.DefiningClassLoader”
  •      “sun.org.mozilla.javascript.internal.GeneratedClassLoader”

MethodHandles.Lookup()
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 “sun.org.mozilla.javascript.internal.Context” 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 “sun.org.mozilla.javascript.internal.DefiningClassLoader” 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.