Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Internet Explorer Zero Day: CVE-2014-0322

Recently, several security vendors reported about a new IE 0day which affects version 9 and 10. The attackers targeted the U.S. Veterans of Foreign Wars website (vfw.org) with an injected iframe which contained a previously unknown exploit for IE.

Below we'll detail some of the techniques used by the hackers behind the attack and draw your attention to some similarities in the payloads of this vulnerability and CVE-2012-4792 (which we took a look at last year).

The hackers behind the attack used several techniques to help them stay "under the radar" as long as possible:

  1. The malicious IFRAME, although containing the exploit in function "puIHa3()", doesn't execute the exploit by itself - instead, it embeds a Flash file, which in turn executes the malicious function of the parent HTML:

    a. The malicious IFRAME embeds the flash file:

    9670_6641235e-24b2-4d09-89ca-9df80bee5593

    b. Here is a snippet from "Tope.swf" which executes the puIHa3() function that is defined at the parent HTML:

    8095_17989468-016e-468a-9406-d68c1041e3f3

Besides triggering the exploit, the current Flash file is also used for spraying the heap and for bypassing ASLR protection. Using Flash in malicious campaigns is becoming very popular these days for various reasons: its efficiency in heap spraying and its ability to interact with the parent HTML and actually execute JavaScript code as if it is part of the HTML DOM. We have actually seen recent attacks where all the IE exploit code resides entirely inside the Flash file which is embedded in the HTML page. These capabilities add more layers of evasion to the attack.

  • When the malicious function from the HTML is finally executed, the exploit will be executed unless the user has EMET installed (Microsoft's Enhanced Mitigation Experience Toolkit). The attackers check for the existence of EMET.DLL file, using Microsoft.XMLDOM ActiveX:

    11818_cb18f7d4-17ed-4a59-a3c9-cf5866933287

    And the path of the DLL is provided to the function:

    12440_ea084ee0-5f7f-4d8a-b624-16e0e1354363

    We may assume that they have tested their exploit against EMET prior to deploying the exploit in "production".

  • Although this vulnerability exists in IE9 as well, we see no code to support exploitation for IE9. This could be due to various reasons:

    a. They had intelligence regarding their target's browser version.

    b. They were short in time or money and decided to proceed as is.

    We don't know the actual reason for this, however it is clear that the attackers aren't rookies as they don't proceed with exploitation unless IE10 User Agent is detected. This ensures no false attempts are made, which could only lead to early detection.

When the exploit succeeds, the Flash file drops to the victim's machine a malicious file named "Erido.jpg".

Analyzing the Payload

Some of our readers with excellent memories may remember a blog post from January 2013 where we took a look at a payload for CVE-2012-4792. You may be wondering why we'd mention this post. As it happens, the payload for CVE-2014-0322 has a remarkable number of similarities. In fact, there are so many similarities that a good argument could be made that the author of the previous payload is also the author of this one. As we've already spoken in great detail about the previous payload, we'll take this opportunity to outline the similarities and differences between the two.

Similarities / Differences

First and foremost, let's discuss how these payloads are similar. One of the first similarities that immediately jumps out at the analyst is string decryption routine, which once again makes use of a simple XOR scheme. The malware then immediately enters an installation routine, where we see a number of other similarities. Specifically, they use the same routine for determining whether the victim is running a 64-bit operating system (OS). Additionally, the same technique for UAC bypass is seen, with a dropped DLL used (DLL determined based on OS architecture).

Finally, one of the largest similarities witnessed is the command and control (C&C) structure, which has remained near identical, as seen below:

10511_8d2d74f8-0001-43d3-a02c-7e93c655ea1a

You may notice two additional commands in this list. These will be discussed shortly. The encryption scheme of XORing the data against 0x59 remains the same, as well as the structure of the sent and received C&C data.

The sample we saw previously was more than a year older than this one, it's not surprising that some changes have been made. During the installation of the malware, it is no longer installed as a service. Instead, the malware uses the common 'Run' registry modification, as we see below:

[HKLM|HKCU] SOFTWARE\Microsoft\Windows\CurrentVersion\Run\MicroMedia - %Temp%\MicroMedia\MediaCenter.exe

The path seen above is the location the malware will copy itself to during installation. The other major modification during the installation process is the removal of the installation as a service, and the addition of the installation of a COM server. In addition to these changes, we see the network communication change slightly, as three distinct URIs are used. We also see those two additional commands that I previously mentioned. The first added function (case 7) simply uploads basic information about the malware, including the process ID and the path of the malware. The second added function (case 8) executes a command within the context of cmd.exe and uploads the response.

In summation, these two binaries, while over a year apart, are very similar both in the coding style and their functionality. It's extremely likely that the same individual or group of individuals authored both binaries.

At the time of this writing, Microsoft still hadn't provided a patch for the security flaw.
Until that happens, we would recommend that all users of Internet Explorer upgrade to IE version 11, install EMET or use another browser.

Trustwave SWG blocked this threat out of the box without requiring any additional updates. We will also address this vulnerability in the coming updates in order to protect against any future variations of it.

What would be the first Exploit Kit to integrate this 0day exploit? Time will tell…

Thanks to the Seculert team for their help with this project. See their post on the topic here.

This blog was co-authored by Josh Grunzweig and Rami Kogan.

Latest SpiderLabs Blogs

Zero Trust Essentials

This is Part 5 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More