Incognito exploit kit

Exploit kits are becoming an increasingly popular means of spreading attacks. Umesh recently blogged about seeing a spike in the usage of the Blackhole exploit kit. This exploit kit targets multiple known vulnerabilities present in a victim's browser, increasing the probability of a successful compromise. Various exploit kits differ in the way they are packaged, designed and implemented. The most distinguishing factor among different exploit kits is how exploits are obfuscated, in order to bypass various security controls.

Recently, I have noticed a significant increase in the usage of the Incognito exploit kit. Similar to the Blackhole exploit kit, Incognito also targets vulnerabilities in Java and Adobe products. Another item that stands out to differentiate among these exploit kits is the URL patterns used. Most of the time, the URL pattern remains same within a given exploit kit. A quick look at malwaredomainlist shows the usage of common patterns used in URLs associated with Incognito.

Common URL patterns for Incognito:

Code obfuscation (Formatted for good view),

De-obfuscation of the aforementioned JavaScript, shows the exploit kit carrying out different attack vectors. Let’s analyze different pieces of the de-obfuscated code.

Object Initializations and other functions,

Iframe Injection:

Google safe browsing reports this URL to be malicious. Visiting the above link redirects you to fake search portal delivering ads hxxp://searchportal.information.com/?o_id=164060&domainname=register-domain-names.info.

Step 0: This is the entry point of the malicious code. It completes required initializations of objects for vulnerable ActiveX controls. Upon the successful creation of objects, it launches the first attack vector by calling function 'gr', which injects a malicious file. The code then moves on to Step 1.

Vulnerability Details:
CVE : CVE-2006-4704
Name : Microsoft Visual Studio 2005 WMI Object Broker Remote Code Execution Vulnerability

My previous blog post describes a different version of obfuscated JavaScript targeting this vulnerability.

Step 1 : This code targets the “Java Deployment Toolkit”.

Vulnerability Details:
CVE : CVE-2010-1423
Name : Java Deployment Toolkit insufficient argument validation

Step 2 : This creates Iframe tags for malicious PDFs.

This example illustrates how the multi-level attacks targeted by exploit kits are becoming a favored choice of attackers these days. More importantly, the creation of automated tools to deliver these exploits, provides attackers with the opportunity to launch campaigns on a frequent basis, with limited technical knowledge.

Pradeep

Exploit in the wild for MS06-014 – a five year old vulnerability

Although 0day vulnerabilities receive all the attention, it’s not unusual to see attackers still taking advantage of old vulnerabilities to attack end users. Here's such an example where the vulnerability used was MS06-014 – a five year old vulnerability!. hxxp://www.win0day.com/win/6.htm delivers an obfuscated JavaScript exploit for this attack. More information about this vulnerability can be found here. Back in 2006 Metasploit released exploit code for this vulnerability.

Lets look at obfuscated JavaScript used:

The de-obfuscated code looks like this:

The exploit takes advantage of vulnerable ActiveX object “RDS.DataControl” having classid “BD96C556-65A3-11D0-983A-00C04FC29E36”. The exploit is designed to download executable files, which are then stored on victim's machine. This executable file path in the exploit is as follows:

This in turn decodes to:

Virustotal results indicate that 21/43 AV engines have protection against this Trojan – a concerning statistic considering the age of the exploit used to deploy the malware. Virustotal’s URL submission indicates that malware URL was submitted on 2010-11-18 and still is in active state. Why would attackers continue to leverage such an old vulnerability? Sadly, as we have shown in our quarterly reports, nearly one in five corporate users still employ Internet Explorer 6, a nine year old web browser.

Pradeep

Analysis of multiple exploits

The most common type of malware seen in Blackhat spam SEO is the fake antivirus. But I also see other types of exploits from time to time. This week, the same malicious page came up on different domains: 4rukel.cz.cc, 4lofs.tk, 1polidsf.co.cc, 1barede.co.cc, 3timesto.tk, 4greaix.cz.cc, 4krudi.cz.cc, etc.

This page is interesting because it uses exploits rather than social engineering to install the malicious code. Below are the details of the exploits / malicious code.


Heavy obfuscation

The JavaScript code is heavily obfuscated. It cannot be de-obfuscated by a simple copy-paste of the code into Malzilla, some of the decoding has to be done by hand.

Original malicious code

One common technique, used in this page, to break the JavaScript de-obfuscation tool is to make references to the DOM. On this page, part of the JavaScript code is included in a textarea HTML tag. It is retrieved and executed later with code like this:

eval(document.getElementByTagName('textarea')[0].value);

While executing the obfuscated JavaScript code, new HTML elements are added to the page, and used to store values or JavaScript code retrieved again later in the JavaScript code.

First de-obfuscation pass generated new obfuscated JavaScript code!

Fortunately, all the JavaScript code is inline. There is no external file, which always make the de-obfuscation harder.


Multiple exploits

Like many malicious pages, several exploits are included on this page:

1. 2 malicious Java applets, using different techniques for Internet Explorer and Firefox
2. PDF exploit
3. Quicktime '_Marshaled_pUnk' Remote Code Execution Vulnerability
4. Heap spray attack
5. Internet Explorer MDAC exploit
6. Internet Explorer "iepeers.dll" exploit
7. 3 Flash exploits

Part of the code for the Java exploit

I believe these exploits come from different sources because the coding style of the various functions varies greatly.


This malicious page tries the different exploits until one is successful. Users need to make sure they keep both their browser and their plugins up to date.

-- Julien

Spam SEO: Use of Java/Flash leads to more dangerous exploits

Most malicious sites behind spam Search Engine Optimization (SEO) poisoning attacks lead to fake antivirus pages. The malicious sites rely on social engineering, tricking users into thinking their computer is infected and require user interaction to execute and install the malicious file, which is disguised as an anti-virus program.

Well hidden exploits

Over the past 3 days, we've seen some even more dangerous websites using Java exploits and Flash vulnerabilities. These malicious pages do not require any user interaction to infect users. They are also very difficult to detect - the exploits are hidden behind several layers of Javascript redirects and use obfuscation. Also, the attackers allow each IP address to receive the malicious page one time only. After a user or a security tool accesses the malicious domain, any subsequent requests coming from the same IP address get redirected to different, harmless pages. This makes post-infection analysis, and the use of security tools almost useless. You have to make sure that you hit the right page, the right way (correct headers, referer header, form data, etc.) the first time or the exploit will not be revealed. Popular online security scanners like JSunpack or Wepawet cannot be used since all requests to the malicious sites are done from the same IP address.

Spam SEO Page leading to a Flash exploit

Java exploit

Mike reported a 300 percent increase of Java exploits last month. These new pages are very similar to what we saw before. A malicious JAR file is launched automatically through a Java ActiveX control vulnerability on Internet Explorer, or through the Java Quick Starter, which is installed silently on Firefox with a recent Java Plugin update. The malicious JAR files are not flagged by most antivirus vendors.

Like all spam SEO, the attack starts with legitimate sites being hacked. New pages are added to target popular search terms, in order to appear in the first few pages of a Google search. When a user clicks on spam SEO links, he actually gets redirected to a different URL such as hxxp://www.hutriken.com/nvu_y/hqpa_b_.php. This page checks to determine if the browser supports Java, and if so, sends the following form with automatically:

Detection of Java capabilities

The next page (the 4th HTTP request) contains both inline obfuscated Javascript, and an external script (obfuscated as well). Once deobfuscated, the exploit is very simple - it invokes the ActiveX control or the Java Quick Starter with the URL of the malicious JAR file.

Deobfuscated java exploit code

If the user, or the security tool, fails at any stage to have the appropriate prerequisites (lacking certain browser capabilities, multiple requests to same page, etc.), it gets redirected to http://google.com/.

Flash exploit

The flash exploit is not as well hidden as the Java exploit, and it is found on fewer links. It consists of a single page with obfuscated Javascript.

Obfuscated Flash exploit

The exploit uses a heap spray technique via ActionScript. We've posted an extended analysis of this type of exploit back in December. Like the Java exploit, no user interaction is needed for the exploit to run.

Deobfuscated exploit

-- Julien

Remote Downloader ActiveX: old exploits, new malware

ActiveX is a proprietary Microsoft technology, which allows developers to produce reusable software components. The controls are compatible with the Internet Explorer (IE) web browser and over the years have been a frequent security threat, as many developers have produced insecure ActiveX controls which can lead to the remote execution of code when a user with IE visits a malicious web page. This is a very powerful tool for attackers because everything happens in the background (no user interaction), and they can trigger exploitation with only a few lines of code.