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.
Sorry can I have this in plain old English please… Im so very low tech this lost me. Should I be worried and if so what do I need to know…
This is way too complex for the average everyday computer person who is not technically knowledgeable about all the computer techy terms.
Wow and I was disappointed it didn’t go into much detail! You can’t really simplify it more than that. Look at the pretty picture of the computers and it says it all.
The attack is different because it uses a 2 redirections instead of 1, and also then downloads the payload (virus) directly from a control computer instead of storing on it’s own disk.
The use of curl is clever, but what exactly is the idea behind the second HTTP 301 redirect?
Good question. It is common for drive-bys to involve intermediary servers which simply 301 (bounce) traffic on, but that is typically in the context of monetizing that web traffic (TDS servers).
In the case of Redkit, it is a bit different. The 301 is between servers within the network of compromised web servers. Perhaps to put more "distance" between the target of the iframe, and the malicious content eventually served up? Perhaps to better track referring URLs driving in the user traffic from the iframe-injected sites? (That could be done without the 301 step though.)
Hi Fraser, is there a know pattern of how the red kit name the first url or the second? Or code inside the scripts? My questions is because I want to write a shell script to detect red kit in apache lnx servers.
The servers used in the 1st and 2nd redirects are legitimate web sites that have been compromised. So the only predictable thing you could check for would be the characteristic 4-character filename (in root of site).
Fraser,
Excellent article. Thanks very much for posting and for NOT simplifying further. We had a web server compromised by RedKit recently and the info in your work was invaluable in helping us get a handle on what to look for in our site files and how RedKit functions overall. Wish we had more of these types of article out there. Keep up the good work.