Friday, January 30, 2015

Exploit Kits: Anatomy of a Silverlight exploit

With the significant adoption of Silverlight technology in today’s market, it has become one of the popular targets for the hacker community. We have observed many popular exploit kits (EKs) like Nuclear and Fiesta, serving specially crafted exploits targeting Silverlight vulnerabilities. Recently, we blogged about the Nuclear Exploit kit live infection cycle, which was leveraging Silverlight vulnerabilities to infect the victim’s computer. In this blog, we will take a look at the Silverlight exploit payloads and how they are embedded in the Exploit kit.

A Silverlight file is a zip archive with an ".xap" extension and it is written in the .NET language. This XAP file contains a list of one or more .NET managed assemblies (.DLL files) along with the AppManifest.XAML file.

We have observed that Exploit kits are generally targeting following Silverlight vulnerabilities:
  • CVE-2013-0074: Memory Dereference Arbitrary Code Execution Vulnerability.
    This vulnerability is due to an improper boundary checking of the user supplied input which leads to arbitrary code execution.
  • CVE-2013-3896: Information (memory) disclosure Vulnerability
    By exploiting this vulnerability an unauthorized attacker can gain access to the sensitive information. This bug is used to bypass the exploit mitigation technologies.

    The following is a typical infection cycle involving Silverlight exploits in EKs:

Dissection of the Infection Cycle and Silverlight Exploit:

As we discussed in our previous blog, the landing page of the Nuclear Exploit kit is heavily obfuscated to evade Anti-virus detection. The function highlighted below is invoking the Silverlight exploit:

As we stepped through the deobfuscated code, we found that the exploit author has implemented multiple unused variables to possibly confuse analysts. We saw a parameter named “tuti” which contains the base64 encoded data that decodes the shellcode.

Upon successful execution of the silver_run() function, the Exploit kit will download a malicious XAP file with the following GET request.

The downloaded XAP exploit consists of three files as shown below.

The AppManifest.xaml file contains the deployment details needed to run the Silverlight application. The first element of it starts with a deployment node which defines the Assembly information, Runtime version, Application Entry point and the assembly extension parts. In this file, There is an attribute called 'RuntimeVersion' through which we can target a specific version of Silverlight. There are two other important attributes, namely EntryPointAssembly & EntryPointType which are mainly used for loading the XAP file.

Reverse engineering the .NET DLL file is straightforward, because it is MSIL (Microsoft Intermediate Language) and there are multiple tools at our disposal. We used the Telerik JustDecompile tool to decompile the DLL. The following screenshot shows us the list of the classes used by the asdgsd.dll.

The screenshot below shows the entry point routine asdgsd.App. The constructor of asdgsd.App is used to call the shlyapa class.

The following activity is performed by the shlyapa class which attempts to exploit multiple silverlight vulnerabilities:
  • Get the .NET run time environment version and store it in the “mild” variable.
  • Get the base64 encoded stream from aforementioned “tuti” parameter and store it in “brae” variable and invoke the "dips" function.
  • In parallel, the function “lout” generates the “numArray” leveraging  class “chaiki”.
  •     Function "lout" generates the "BitmapImage" instance by calling function "game" from "alupka" 

  • The function "huts" is leveraging CVE 2013-3896 (A memory disclosure vulnerability in the public WritableBitMap class) to calculate the base-address of "" as seen below:

  • Finally, the "dips" function executes the "spca" function that takes the base-address of "" as an argument. The "spca" function is triggering CVE-2013-0074 (Dereference Vulnerability during HTML object rendering) as shown below:

The following is a sample of live Nuclear Exploit Kit domains that we have seen in past 24 hours:

Nuclear EK Domains 

We continue to see the Silverlight vulnerabilities mentioned in this blog being exploited by many other popular exploit kits. Zscaler is actively monitoring and protecting end users against this threat.

Credit for Analysis & Guidance : Dhruval Gandhi

Thursday, January 22, 2015

Malvertising leading to Flash Zero Day via Angler Exploit Kit

UPDATE [01/25/2015]: Adobe released an update yesterday (APSA15-01) for CVE-2015-0311 that fixes the zero day exploit mentioned in this blog. Given the number of exploit attempts we are seeing for this vulnerability in the wild, it is critical for users to update the Adobe Flash player to the latest version


Earlier this week, Kafeine published a blog mentioning an Angler Exploit Kit (EK) instance serving a possible zero day Adobe Flash exploit payload. The ThreatLabZ Research Team reviewed Angler Exploit Kit activity across the cloud and were able to identify multiple instances of Angler Exploit Kit hosting sites serving a new Adobe Flash payload that is able to exploit the latest Flash Player version  [Adobe released a patch (APSB15-02) for CVE-2015-0310 today and we can confirm that the patch does not prevent exploitation of the 0day discussed in this blog. The latest version is still vulnerable and is being actively exploited in the wild.]

Upon further investigation, we discovered that this appears to be yet another case of a Malvertising campaign leading unsuspecting users to Angler EK instances. Upon successful exploitation, we observed a new variant of the Bedep Trojan getting dropped and executed on the victim machine. We tested this on a Windows 7 64-bit system and the payload dropped was a 64-bit Bedep Trojan variant which generated a high volume of AdFraud traffic from the infected system.

The affected advertising networks found in this case were:
Infection Cycle

The infection cycle involves users visiting a legitimate site that displays certain advertisements from the compromised advertising networks, which will redirect them to an Angler EK hosting site and begin the exploit cycle. If the exploit is successful, a new variant of Bedep Trojan gets downloaded in an encrypted form and installed on the target system.

The entire infection cycle occurs silently in the background and is completely transparent to the end user.

The exploit page has the title "Welcome to new site" and is comprised of 220 hidden input elements, followed by three inline scripts.

The first script code snippet is obfuscated with block comment text (ie: /* random text */), but also appears purposefully broken for multiple JavaScript engines. Looking at the code, there are multiple period characters inserted throughout the script which leads to syntax errors at runtime:

The second script code snippet calls a function in the first script leading to "eval" and resulting in JavaScript code that performs Browser plugin detection:

The third script code snippet drew our attention, as it is not obfuscated and simply loads an SWF object. This script serves the Adobe Flash 0-day and it is interesting to note that the script will only execute if the earlier script has thrown an error. The flash payload is only triggered if a variable defined in the first script is undefined:

Successful exploitation will result in download of the Bedep Trojan payload that appears to be encrypted using an incremental XOR technique.

Malware Payload activity - Bedep Trojan

The malware payload dropped is a 64-bit DLL belonging to Bedep Trojan family.  This malware family is known to download additional malware. It is also responsible for generating AdFraud and ClickFraud activity from the infected system.

File: neth.dll
Size: 219608
MD5: EFB584DEA6CBC03765487633BD5A5920
Compiled: Wed, Nov 28 2007, 15:51:15  - 64 Bit DLL
Version: 5.3.3790.3959 (srv03_sp2_rtm.070216-1710)

It drops a copy of itself at the following locations:

C:\Users\All Users\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll

It creates the following registry entries to achieve persistence in a discreet manner:

HKLM\SOFTWARE\Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\: "C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll"
HKLM\SOFTWARE\Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\ThreadingModel: "Apartment"

HKU\S-USERID-1000_Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\: "C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll"
HKU\S-USERID-1000_Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\ThreadingModel: "Apartment"

This ensures that it runs in the context of system process "explorer.exe":

It appears to determine the infected system's timezone and location by connecting to "", however we noticed that it is not able to supply the latitude and longitude parameters in the request, essentially resulting in getting back UTC date and time information.

It employs a Domain Generation Algorithm technique to hide the actual Command & Control server as seen below:

 We found the following two C&C domains registered in past 48 hours:


It attempts to connect to these Command & Control servers to report the infection and receive further instructions. It presumably gets a list of ClickFraud tasking servers, following which we started seeing high volume of ClickFraud activity.

This is the first 0Day Adobe Flash Player exploit for year 2015 and not surprisingly, we are seeing it getting served through a malvertising campaign. The fact that the end malware payload getting served in this case is also involved in AdFraud activity leads us into believing that this campaign appears to be from a gang indulging in ClickFraud and AdFraud activity.

Zscaler ThreatLabZ has deployed multiple layers of protection against this threat to ensure that the customers are protected.

Analysis by Deepen Desai & John Mancuso

Friday, January 9, 2015

Chanitor Downloader actively installing Vawtrak

We at ThreatLabZ are keeping an eye on a fairly active downloader called Chanitor. This malware is being delivered via phishing emails purporting to be "important" documents, for example, voicemails, invoices, and faxes; all are actually screensaver executables with the extension ‘.scr’. Another unique feature of this downloader Trojan family is the usage of and over SSL for its Command & Control (C2) communication.

Upon execution, Chanitor copies itself to ‘%APPDATA%\Roaming\Windows\winlogin.exe’ by running the following command:

cmd /D /R type "C:\<path-to-binary>\winlogin.exe" > ___ && move /Y ___ "C:\Users\<username>\AppData\Roaming\Windows\winlogin.exe"

It then waits for a few seconds before deleting the original file, and executes the copy via the following command:

cmd /D /R ping -n 10 localhost && del "C:\<path to original exe>" && start /B "" "C:\Users\<username>\AppData\Roaming\Windows\winlogin.exe" && exit

Once the command executes, it creates a registry entry for persistence:

Chanitor encrypts some key components like C2 server locations that is decrypted only when used on run time. For example, "" is decrypted using a xor loop:

The next step is enumeration of functions for making outbound SSL connections and making connections to the command and control server. These connections are shown in the screenshot below.

The first connection (#1 above) is to retrieve the public IP of the infected host. The success or failure of this request isn’t checked though, so the next request happens regardless. This request (#2) is a beacon to the command and control server on TOR via Chanitor uses SSL for all communication and beacons via POST requests to /gate.php. If the request is successful, the C2 server will provide further instructions which during our analysis was to download additional binary payload. The download is shown in session #3 above. Once the download finishes, there is a subsequent beacon which presumably means success (#4). Strangely enough, there is a failed request to (#5). This domain does not exist, so the purpose of this request is unknown.

The screenshot below shows detail of the initial beacon (#2) and server response to download a stage 2 binary:

Each beacon takes the following form:

If the request to is unsuccessful, the IP address will be the machine's RFC1918 address instead of a public IP. The C2 server replies with an instruction to download a file (highlighted in red above) and the download is initiated immediately. The beacon information, with the exception of the IP address, is also stored in the registry:

After downloading and reporting success, the original binary will then sleep for approximately 5 minutes (there's some variation for slightly longer and slightly shorter) before beaconing again:

Downloaded Binary

The downloaded binary is a dropper Trojan and is saved as C:\Users\<username>\AppData\Local\Temp\__<4 alphanumeric characters>.exe. Chanitor will run the downloaded payload via the following command:

cmd /D /R start /B "" "C:\Users\<username>\AppData\Local\Temp\___16AE.exe" && exit

Upon execution, the binary checks for the presence of a debugger. If no debugger is found, the binary then unpacks an embedded DLL and writes it to disk. This DLL is a new variant of the Vawtrak Trojan.

The DLL is registered with regsvr32.exe via the following command to ensure persistence:

The Vawtrak dropper Trojan then deletes itself from the target system. The Vawtrak dropper binary and the DLL are compressed using aPLib v1.01 library as seen below:

Vawtrak, also known as NeverQuest and Snifula, is a powerful information stealing backdoor Trojan that has been gaining momentum over past few months. It primarily targets user's bank account via online banking websites.

Indicators of Compromise

C2 Domains

File Locations
C:\ProgramData\TigaPjopw\VofcOhhel.zvv -- these names appear random
C:\Users\<username>\AppData\Local\Temp\~004BFD62.tmp -- this name appears random
C:\Users\<username>\AppData\Local\Temp\___16AE.exe -- this name appears random


The samples collected date back to the beginning of October 2014 and have changed in measurable ways over the past few months. The first samples would not run on Windows 7 unless in compatibility mode, required administrative privileges, and did not have icons that matched the purported filetype or theme, but the recent samples have evolved to run without errors and appear to be more refined. We attempted to contact tor2web at and at and received bouncebacks followed a few days later by a delivery failure notification. Since the C2 servers are hosted on TOR, tracking the individuals behind this campaign may prove difficult, but blocking access to tor2web would be effective for the time being.