The Resurrection of RedKit
"RedKit" was once a thriving exploit pack then faded away leaving behind artifacts on several abandoned hosts which are still triggering broken redirection alerts to this day. Within the past couple of months, however, we are witnessing a deliberate return of “RedKit”. While I can’t be 100% certain, there are many striking similarities between this and the previous iteration of RedKit that I’m led to believe that this is an updated version.
Overview of its Resilient Infrastructure
RedKit, discovered in May 2012 by Trustwave, eventually built itself a three-tier infrastructure to protect its backend, “command and control” server. The real exploit pack server would send PHP scripts to compromised websites and gave them assigned roles: redirector, exploiter, and dropper.
Originally, a typical RedKit infection chain looked something like this:
RedKit v2.0
Back in November 2013, this was the malicious iframe tag that led unsuspecting visitors to a drive-by landing page:
Joel Ester identified this as a new exploit kit and called it "Goon EK". The infection chain looked like this:
It turns out that this was the first appearance of the updated version of RedKit. Then in early December 2013, RedKit v2.0 URLs looked very similar and instead of “cnt.php” it used “post.php”.
The infrastructure required one less tier of compromised hosts and looked something like this:
Near the end of December 2013, the infrastructure and URLs changed once again. Now it’s more efficient and even less compromised hosts are needed. This is what the infrastructure looks like today:
This is what the redirection to the landing page looks like:
And this is the infection chain:
If you’ve been tracking these infections, you’ll notice that the URLs to the exploit landing pages are very inconsistent. Here are several examples:
How are they able to achieve this? The RedKit author(s) are cleverly using the .htaccess rewrite rule so the malicious URLs can be anything they choose. The URLs they have used to date doesn’t have any pattern but the filename will always contain .php, .htm(l), or .asp(x).
If you go to a non-existing file on the compromised website, it will be caught by their script. The script then parses the URI and depending on the results, the appropriate exploits are delivered.
To check if a website has been compromised and part of a RedKit infrastructure, visit a non-existing file with a “.shtml” extension. If the .htaccess and malicious script exists, it will catch the URI and echo it back to you.
RedKit v2.0 Arsenal
RedKit uses one of three Java exploits depending on the version the user has installed. The Java applets have minimal obfuscation. It does have a hidden class file called “NewClass.class”. And as you can see, it builds the URL for the payload using the time (HHmmss) and then appends the string “.mp3”.
In late December, a new exploit, VUPEN’s Internet Explorer Use After Free Vulnerability, was added. The payload URL triggered by this IE exploit doesn’t use the timestamp method. It’s a hard-coded value in the exploit code.
The landing page containing the exploit code has been obfuscated. The script XORs the blob of characters using the value “cdlo” (first red rectangle). At the bottom, the script calls a function called “starter” which passes the payload URL and another XOR key which is then concatenated to a VBScript routine and executed. At the bottom, there’s a link to a malicious Java applet just in case the IE exploit failed.
Here are the exploits used by this version of RedKit:
RedKit Infrastructure
The compromised servers hosting the RedKit script has an .htaccess file which causes all non-existing files to redirect to the “post.php” file. I was able to obtain these files by a helpful website developer.
The post.php file is different depending on the website's role and can be easily and quickly changed by the author(s). In fact, the author(s) appear to rotate the roles regularly to avoid detection. The PHP script is minimally obfuscated and looks like this:
Redirector Role – Back in November 2013, the compromised websites playing the redirector role checked for the “id” parameter, wrote the IP address to a file called “post.ips”, then redirected the visitor to the next stage. It did check to make sure they were potentially vulnerable Windows machines as you can see here.
Exploiter/Dropper Role – The websites with this role have a different post.php file. The script doesn’t interrogate the visitors’ Referer and UserAgent as thoroughly as in the past. It does check what version of Java they are running then gives them the IE exploit or one of three malicious Java applets.
First, it makes sure the URI contains “.php”, “.htm”, or “.asp” then it writes the IP address to a file. It then does a basic check to make sure the Referer and UserAgent exists and has a long enough value. Then it produces the IE exploit landing page or the following HTML page for the Java applets:
The visitor is then redirected to a non-existent file on the same server but is caught by the .htaccess rewrite rule and sent back to the post.php file. Here, the script checks the Java version and gives the visitor the appropriate JNLP and Java files. The Java URL again leads the visitor back to the post.php file and the applet is delivered. All of the files are stored within the PHP script as base64-encoded strings which are decoded as needed.
A log of visitors is written to a text file on the website which is grabbed by the RedKit author(s) then cleared each time:
