Lifting the lid on the Redkit exploit kit

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.

Traffic control

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:

Exploit kit

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.

Command and Control server

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.

Distribution

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.