A closer look at the malicious Redkit exploit kit

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

In my previous article on the Redkit exploit kit, I provided an overview of how the kit operates. Specifically, how the attack uses a network of compromised web servers to serve up the redirects and malicious content.

In this article, I will take a closer look at the malicious content used to infect the user with malware.

The landing pages used by current versions of Redkit are pretty simple, consisting of just a tiny web page that loads up the malicious Java content. A single param attribute is used to pass in an obfuscated URL (underlined) to the Java code:

This string is retrieved and decoded (simple character substitution):

As noted previously on Naked Security, there have been several recent vulnerabilities in Java that are being targeted by exploit kits like Redkit. In a successful attack, security mechanisms will be bypassed and the malicious payload silently downloaded and run.

The specific vulnerabilities that are being targeted in Redkit change quite regularly, but have recently included:

The JNLP file referenced in the landing page (above) reveals a security bypass that is being used by several of the active exploit kits. The attacks make use of an undocumented parameter (__applet_ssv_validated) to bypass security restrictions, and enable silent (no user prompt) execution of an unsigned applet.

The file downloaded from the payload URL is actually AES encrypted. Clues to the use of AES litter the Java code, despite various attempts to obfuscate the intent. For example, reversing the Cipher transformation string:

Sure enough, looking at the downloaded file, it is easy to confirm that it looks encrypted or encoded in some way (it is not a regular Windows executable at least!):

Of course, to infect the user, the Java has to decrypt the file first. Elsewhere within the code is the necessary decryption key (and iv parameter):

Using these we can manually decode the encrypted file:

openssl enc -d -aes-128-cbc -in -out -K -iv -nosalt -nopad

The Java code does not simply decrypt and save/execute the downloaded file however. There is an additional block of code that inspects the decrypted stream, hunting for a string that is used as a marker.

The purpose of this mechanism is evident a little lower down in the code.

So, if the marker is found, the if condition is false, and two executable files are extracted from the decrypted stream and executed. If the marker is not found, only a single payload is present, and just that file is executed.

Looking at the decrypted file obtained from a recent Redkit payload, the marker is indeed present (highlighted in red), sitting between the two executables that the user is infected with (scareware and a data stealing Trojan).

This mechanism enables the Redkit exploit kit to infect the victim with up to two payloads in a successful attack. The mechanism could easily be extended to allow even more. Of course, this does not really make the attack "worse" - once any machine is infected with a single payload, it is common for that to download and execute others. Nonetheless, it is an interesting feature to note.

The diagram below provides an overview of the above information, summarising how Redkit infects victims with malware.

In these two posts on the Redkit exploit kit I have described the key characteristics of the kit. The most interesting of these are:

use of a network of compromised web servers to "host" the kitproxy malicious content (landing page, JAR, payload) from the C&C server to the victim via a compromised web serverdownload payload(s) in encrypted (AES) formenable infection of 2 payloads in a single attack

To conclude, a few points concerning how users can best protect themselves from this (and similar) attacks.

To start with users or organisations need to consider whether their machines are vulnerable to the exploits being used (just Java in the case of Redkit, at the time of writing).

Do you have Java installed? Do you actually require it? If not, remove Java from your browser.

If you do need Java, ensure you are fully patched, and running the latest version.

In terms of security software, regular good practice should be followed.

In short, use a reputable security product which is up to date.

Additionally, ensure the available functionality within that product is enabled (web reputation filtering, web content scanning, cloud protection, memory scanning, runtime protection/HIPS).

All of these features are designed to provide layered protection, which is crucial for effective protection against drive-by download attacks delivered from exploit kits like Redkit.

Follow @SophosLabs
Follow @NakedSecurity

Image of red eye courtesy of Shutterstock.

View the original article here

Lifting the lid on the Redkit exploit kit (Part 1)

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Redkit is one of the lesser known exploit kits that is currently being used to distribute malware.

Though not as widely talked about as Blackhole, Redkit has gained some press recently, having been involved in the NBC site hack and the spam campaigns that followed the Boston bombings.

In the first of this two-part series, I will give an overview of the exploit kit: how it operates and where it is being hosted.

Part Two will take a deeper look into the malicious code being used in order to uncover some of the functionality it provides to the attackers.

To start with, let's take a look at how Redkit operates.

As with other exploit kit drive-by downloads, victims are typically redirected to the exploit kit when they browse a compromised web site. For Redkit attacks, there are several different flavours of redirect being used, but over the past few months, the most prolific is one that Sophos blocks as Troj/Iframe-JG.

This inject has been discussed previously. As you can see from the image below, the iframe injected into pages is fairly easy to recognise:

The conventional drive-by download model involves victims being redirected to a malicious exploit site. However, Redkit does things a bit differently.

The initial redirect (typically an iframe) will be to another legitimate, but compromised server. Let's call this the first stage redirect. This redirect will be to a four-character .htm or .html page in the root of the the target web server. For example:

compromised_site.net/dfsp.html
compromised_site.com/zpdb.html

The response from this redirect is a HTTP 301 redirect. Let's call this the second stage redirect.

The 301 redirect bounces the victim off to another compromised web server, again to a four-character .htm or .html page. This time, the malicious content is delivered via a simple landing page that loads the malicious JAR.

Historically, Adobe Reader has also been targeted, but Redkit has been targetting just Java vulnerabilities for a while now.

More recently, the landing pages are slightly different, using JNLP (Java Network Language Protocol):

Note: Older versions of the kit used .html for the first stage redirect target, and .htm for the second stage. In later versions of the kit this has changed.

As far as the victim is concerned, the malicious content is delivered from the compromised web server that is used in the second stage redirect. Interestingly, however, that content is never stored on that web server.

Instead, the compromised web servers used by Redkit are loaded with a PHP shell, which manages things. The PHP shell is responsible for:

Bouncing first-stage redirects on to another (randomly chosen) server. The PHP shell connects to a remote Redkit command and control (C&C) server in order to obtain a list of other compromised sites (updating the list each hour).Delivering malicious landing page and JAR content to the victim. This is not loaded from disk. Instead it is downloaded (using cURL) via HTTPS from the C&C server. So the PHP shell essentially acts as a proxy for the malicious content.

? Sophos products detect the PHP shell as Troj/PHPRed-A.

The PHP shell works in tandem with a rogue .htaccess file, which is responsible for guiding incoming HTTP requests (to the four-character htm/html files) to the necessary PHP script.

This is illustrated in the diagram below.

A large number of compromised web servers have been used by Redkit over the past few months. A breakdown by the countries hosting the hacked servers is shown below.

These servers are split across several ISPs:

How are the servers being compromised? Looking at the server strings returned from the compromised web servers, we get a fair spread.

This would suggest that it is not the server platform (Apache, IIS etc) that is being targeted/exploited. More likely software/applications installed on the server itself, or simply stolen credentials.

This concludes the first of these articles on Redkit. It provides an overview of how the kit operates, and describes the interesting techniques used to "host" the exploit kit. The data collected thus far also gives us an indication of the prevalence of this kit, and the number of compromised web servers involved.

In the next article in the series, we will take a closer look at the malicious Java code, and how it is used to infect the victim with the payload.

Follow @SophosLabs

Follow @NakedSecurity

View the original article here

The Redkit malware exploit gang has a message for security blogger Brian Krebs

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Brian Krebs

Award-winning security blogger Brian Krebs is loved by everyone on the internet... apart from the criminals.

The fact that Krebs has shut down spam operations, helped dismantle botnets, given the notorious Russian Business Network more than the odd headache, has made him plenty of enemies in the internet underground.

Just last month, online crooks launched a DDoS (distributed denial-of-service) attack against Krebs's blog, and sent an armed SWAT team around to his house.

So, I was interested to hear from SophosLabs researcher Fraser Howard what he had uncovered inside the latest version of the Redkit exploit kit what appeared to be a message for Brian Krebs.

Crebs, its your fault

What's that famous quote?

"Say anything you want about me as long as you spell my name right!".

In this particular case, the Redkit gang were struck by a double attack of both poor spelling and lousy grammar - but I doubt tireless cybercrime reporter Krebs will lose much sleep over it.

Sophos products are proactively detecting the redirects which point to the exploit site as Troj/JSRedir-R and Troj/Iframe-JG.

The landing page of the exploit kit is detected as Troj/ExpJS-II, and Sophos proactively protects against the Java vulnerability (CVE=2012-4681) that this version of Redkit tries to exploit as Exp/20124681-C.

http://twitter.com/gcluley

Thanks to SophosLabs Principal Researcher Fraser Howard for alerting me to this message.

View the original article here