Quick Overview
In a typical drive-by download scenario, users visit a compromised website and are redirected to a web server hosting an exploit pack. The exploit pack server delivers the appropriate exploit to compromise the visiting user’s PC then uploads the malicious payload to finish the job.

In order to infect as many users as possible, the exploit pack server needs to stay up for as long as possible. In the typical setup, the exploit pack server is exposed to every user who lands on its malicious pages.
 
To improve its resiliency, exploit pack authors had to find ways to keep the exposure to a minimum. Over time, they deployed several tricks such as redirection rules, traffic distribution systems, dynamic DNS, using dedicated servers for exploits and another for payloads, and so on.

But in the end, the exploit pack servers are still vulnerable to takedowns because they make their presence known even if they’re hiding behind a dynamic DNS.
 
Enter RedKit
RedKit was discovered around this time last year by the excellent researchers over at Trustwave and initially setup like a typical exploit pack. Several months ago, the author(s) of RedKit moved to a new kind of infrastructure, one that was designed to protect its main exploit pack server. It does this by leveraging compromised websites to act as proxies. The real exploit pack server would send files to these compromised websites and give them assigned roles: redirector, exploiter, and dropper.

Here’s a typical RedKit infection chain:

 
It starts off with a compromised website hosting a malicious iframe tag that leads the unsuspecting visitor to the first link in the chain:

Each compromised website thereafter appears to have an .htaccess file which looks like the following. This redirects any request that comes to the website with a non-existing filename containing 1-4 alphanumeric characters ending in HTM, PDF, or JAR to the default.php page. This rewrite rule gives the authors the flexibility to change the filenames and URL format quite easily.

The default.php file is different depending on the website’s role. It appears the role can be changed by the RedKit authors though it is not known how they determine the role a website plays and how the file gets updated.

Redirector Role – Compromised websites tagged with this role have a script that redirects the user to another compromised website via a 301 redirect. This leads to the second link in the chain.

Exploiter Role – The script used by compromised websites playing this role deploys the standard rules you see with other exploit packs to prevent multiple infections and to make sure the “undesirable” visitors are kept away. Otherwise it determines the user’s Java version and sends one of three malicious applets (CVE-2012-0422, CVE-2013-0422, CVE-2013-1493). The applets stored in this file are encoded as base64 (note: it has been removed for brevity’s sake).

Here’s one of the checks it makes:

This is the excerpt that primes the malicious Java applets:

The script above creates an HTML page with the appropriate applet that will infect the visitor’s PC:

A few months ago, the exploiter script did a curl to the RedKit backend server (the real exploit pack server) then downloaded and stored the Java applet on the compromised website in a special folder. If another visitor with the same Java version came along, the script would check if the applet was already in the folder and used that applet instead of pulling it down from the backend server again.

Dropper Role – Compromised websites with this role send the payload to the visitor’s PC. The script does a curl to the RedKit backend server and obtains the malicious executable to deliver to the PC.

Here’s what the packet capture shows when the “setup.exe” file is downloaded (which matches the above script):

Although this has not been observed, since PHP scripts are used, it’s quite possible to update and/or combine roles quickly and easily.

Not much is known about the backend, exploit pack server. Because of their infrastructure, the RedKit authors could easily monitor incoming connections and deploy an IP-whitelist to only allow connections from a list of websites they’ve compromised.

Conclusion
The RedKit authors have come up with a new strategy to sustain themselves by implementing a unique, resilient infrastructure. This strategy appears to serve several purposes:

• Takedowns become confusing and complicated since it appears that compromised (legitimate) websites are hosting the exploit pack.
• The setup gives RedKit authors the flexibility to change the URL formats quickly and easily making detection more difficult.
• Using compromised websites and updating/combining their roles make the entire infrastructure dynamic and resilient.
• The main exploit pack server is not part of the infection process so it’s never exposed.
• Managing one or two exploit pack servers and monitoring the chokepoints for suspicious activity is far easier to do, and do well.

Although their strategy appears sound, it’s not without some disadvantages:

• Much more compromised websites are needed to build and maintain their infrastructure.
• Owners of compromised websites who detect and remove their scripts can disrupt or even break the infection chain.

Relying on compromised websites makes their infrastructure somewhat fragile and unreliable. However, it appears the RedKit authors have consciously made stealthiness and resiliency of their own server a higher priority over the effectiveness and efficiency of drive-by infections. I suppose they prescribe to the school of thought that having poor loads/stats is better than not having any at all.

Added the following packs:
Whitehole
Neutrino
Fiesta
g01Pack
“Zuponic”
“NoMatch”
Anonymous Exploit Kit
“Glazunov”
“PopAds”
Whitestorm
SafePack
“SPL Pack”

If you can share any of the above (source code or panel shots), please do!

Here we see the Word document with an embedded object:

Viewing the file with Notepad, we can see that this is an RTF file and definitely looks suspicious.

A little ways down, we can see a NOP sled.

Let’s use OfficeMalScanner to extract the objects and confirm our suspicions.

Looks like we have to use RTFScan instead. RTFScan tell us that there are matching shellcode signatures in the OBJDATA section. Then it dumps a single OLE object and suggests that we run OfficeMalScanner again.

The OLE object is rather small considering the original “file.doc” file is 791KB. Something is wrong. Here’s what the OLE file looks like:

Let’s have a look at the original Word file again. This time we notice the magic for Word in hexcode.

What if we strip away the original RTF headers and make this file look like a Word document? Maybe then OfficeMalScanner can extract the hidden binaries. With a hex editor, we do just that.

Since this is hex, we need to convert it to binary and write it out to a file.

We can open this file called “file.doc_” which has the Word magic at the beginning. Now we copy the rest of the binary code from the original “file.doc” file and paste it to the bottom.

Now let’s run OfficeMalScanner on this modified file using its scan and brute options…and hope this actually works. Great it does!

OfficeMalScanner finds the XOR key and is able to extract two embedded files.

The first file appears to be a Word document.

And opens in Word with a warning.

The other file is an executable.

You can actually do this the long way and carve out the embedded objects from the Word document manually but this would take more time than what’s necessary. Thanks to Frank Boldewin’s tool and a little tweaking, we can get the job done fast!

The exploit used is CVE-2012-0158 and seems to have very good coverage on VirusTotal (31 / 46). Here is the tool I used to recreate the malicious Word document. Actually I found two. It would be irresponsible to share these files so don’t bother asking. Sorry!

Filename: Word-2013.1.8.exe
MD5: ea7084ef5faa8c7721ab163cb6cb58d2

Filename: MS10-087.exe
MD5: 2898479123b90278cfc7b30ddd9c4bd6

MalwareCrusaders will be posting more details on this soon so I won’t go too deep here. I’ll just focus on the embedded binary file which turns out to be an executable.

Downloading the JAR from the website gives a different one each time but here’s the MD5 hash I’m working off of: 01B9B996144834146B4109719ED84AA5

Opening the file with JD-GUI shows us an object in the JAR:

The embedded file does look encrypted:

We can tackle this two ways. One way is to bruteforce the file. The other is to reverse the applet and find the decryption routine. Let’s go through both starting with the bruteforce method.

Using Converter’s Key Search/Convert feature, you can import the first 1KB of the file so you can test your assumptions on a small data set. Just by looking at it, you can see diagonal waves formed by cetain characters which tells us there’s a pattern. If you don’t see any pattern then the file may be encrypted using the AES or RC4 algorithm.

Just select a bunch of characters and look for repeating strings:

55493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F6A3862655
16455493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F6A3862
65516455493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F6A3
86265516455493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F
6A386265516455493564413855774F6A386265516455493564413855774F6A3862655164554935644138557
74F6A386265516455493564413855774F6A3862655164554935647216

Then put them one on each line:

4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356

So this looks like a 15-byte XOR key but which byte goes first? Going back to Converter, just leave the first two characters in the input box, set the input format to “hex”, then do a key search match of “M”. It will tell you what the XOR key is…77.

So 77 is the first byte:
774F6A386265516455493564413855

Now enter the hex string above separated by commas into Converter. Be sure you choose Hex format for the key and select the Consecutive action. Looks like it works!

If you want to write it out to a binary file, you need to make sure that you import the *entire* file (not just the first KB) and the output format must be changed to hex.

The second way is to reverse engineer the applet. You will have to go through each of the applet’s class files and read though the code. There’s a lot of deadends, fake data, and decoys but you will eventually end up on the last class called “U”. In it, is a string of positive and negative integers. The variable is called “encoded” and it just so happens that a few lines down, it says that the “encoded” value is passed to an “XorDecrypt” function along with a string, “wOj8beQdUI5dA8U”.

Further down, we can see the function with useless content except for the code that indicates that each byte is XORed with the string from above. This string is the decryption key.

Let’s copy the strings over to Converter. Make sure the input format is dec(imal), the key format is text, the key itself is separated by commas, and the action is consecutive. Looks like it’s another class file.

To write this out, choose hex output, convert it again then write to binary file.

Change the file name to whatever.class then open it up with JD-GUI. This routine takes the inputStream (which is the encrypted file) along with a decryption string which is the same string as the one above, “wOj8beQdUI5dA8U”.

MD5: 6943787043e7a946c840f9d82f8088f6
VT: 4/46

This is a list of changes made to this version:
+ Replaced Binary-to/from-Text with Binary-to/from-Hex to make it more useful
+ Added Filter > “Keep Hex” to only keep hex characters
+ Added Format > “Mixed Octal to Hex” to convert a mixture of text and octal to hex
+ Added Format > “Sort Text” to sort a string
+ Added Format > “Hex Format – CSV” separates hex values with a comma
+ Added Tools > “String Builder” to keep values between quotes
+ Modified “Dec-to-Hex” and “Dec-to-Octal” to handle negative integers
+ Added “copy output to input” option to Secret Decoder Ring
+ Added ability to import first KB (or all) of data to Key Search/Convert
+ Eliminated extra fields in Key Search/Convert screen
+ Made expression capability in Key Search/Convert and Convert Binary File a little more robust (added Extra > “Expressions Help”)

Here’s a look at some of the features in action…

This applet used binary strings to hide its actions:

Just paste it in and the Binary-to-Hex feature will split on every eight characters and convert them to hex. You can choose the Output Format using the dropdown at the bottom.

Here we see an applet concatenating several variables together before it deobfuscates it:

Using the “String Builder” feature…

Just paste the section in and Converter will concatenate everything between the quotes together. Make sure the beginning and ending quotes are present.

This applet is using a mix of text and octal characters:

The “Mixed Octal to Hex” feature…

Will convert the string (including escaped characters) to hex.

This applet is using an array of positive and negative integers:

Converter now converts decimal to hex properly.

This particular applet takes this concatenated string and deobfuscates it by running through a decoder routine three times:

The Secret Decoder Ring now allows you to copy the output to the input field so you can decode it any number of times without having to manually copy/paste each time.

Finally, you can see the changes made to the Key Search/Convert screen. I tried to make the expressions as flexible as possible.

You can download Converter from here. Enjoy!

I grabbed a Blackhole landing page link from a favorite site of mine, malc0de.com/database. Be sure you check it out and subscribe to the feed to get the latest!

Here, my browser is going to get hit by a Java exploit:

Analyzing this JAR file, we see at #26 a ClassCode is being created. It is calling two functions (test.iar then test.stob).

Here’s the “iar” function:

And the “stob” function:

Let’s get the string of characters from ClassCode and perform the same functions using Converter. Here’s what the array looks like. At the end of the array is the number “2″ which is passed to the “iar” function as the “glueString”.

We copy the array into Converter and do a search of ” , ” and replace it with “2″.

Now we use the Tools > Key Search/Convert function. You’ll notice that the Before and After Action has changed. I made it more robust to handle calculations that go beyond the original addition and subtraction actions. Looking at the “stob” function of the Java applet, each byte has 42 subtracted from it then a modulo 256 is performed. It’s also not doing any XOR function. We can replicate this in Converter like so:

The word “val” must appear in the calculate field. What Converter is doing is replacing “val” with each byte from the input field, subtracting 42 then doing a mod 256. You have to enter an XOR key but you can use a 0×00 to have it do nothing.

You can perform numeric operators (+ 0 * / \ ^ mod) and boolean operators (not and or xor eqv imp) in the correct order of operation (use parenthesis). All values should be entered as decimal. To be honest, I haven’t tried all of the operators nor arithmetic functions so use at your own risk.

I also added this functionality to the File > Convert Binary File option. Since this does file conversions and not a key search, the screen looks different. Just choose “Convert” if no XOR calculations need to be performed.

Here’s the resulting file:

And the same file loaded in JD-GUI:

The final addition is the ability to do a key search to find a matching hex code instead of just text. It can do decimal (CSV-delimited) too.

Data Converter has been updated to v0.5 to include the before/after actions functions and hex/decimal key searching as described above.

In addition, Revelo has been updated to v0.5.1. I just made some of the functions more efficient and fixed a few bugs along the way.

All of these tools can be found here.

An couple hours later, I figure I would try again and get lucky. Still nothing! But this time I thought I would check out the ads. As I scrolled down, about half way down the page an ad slid out from the bottom right. My PC then got infected.

The source code of the ad box shows a redirect script.

This script shifts the block of random text by one ASCII character then renders it with a document.write. I can use Converter to show me what this obfuscated text looks like:

This is the landing page of Fiesta EK (aka Stamp EK, SofosFO). Hat tip to Fox-IT.

I thought I was all done here but I looked through the rest of the HTML source and this Javascript section looked really suspicious.

Since I burned through so much time on this already, I just pasted that section in Revelo and clicked on “Execute” to safely see what it would do.

I curl’d the link and got this file. Nothing. Looks like I have to spoof the referer.

Tried again and got this. This file appears to contain a Javascript variable.

I pasted this into Revelo up at the top above the previous script and hit “Execute”:

So what does this script do? It converts the variable from the second site into a URL then appends it to the body. You can whip up a simple script with the following to see how the URL gets made:

It gets rid of any character from G to Z (upper and lower case) and converts all of the special characters to “%” then unescapes what’s left. This, as you know, is the landing page of Blackhole.

The website was notified and time was given to clean it up before this post but the site still appears to be affected. It seems webmasters are having some difficulty finding and removing these types of infections lately.

UPDATE
I was asked to comment why this drive-by isn’t picked up by online website scanners.

Majority of the time, these scanners work great and can detect suspicious content easily and accurately. In this case, however, the infected content is located in an iframe that only appears when the user scrolls down the page past the end of the article. This is atypical and the attacker probably took advantage of how the ad was normally presented on this website.

And the script itself was no ordinary redirect.

Here’s a prettied-up version of the script. What the script is doing is a simple character substitution to convert those special characters into hex code. The hex code is then converted to text and eval’d. Of course it’s doing it in the most obscure way.

Here’s a very quick rundown of what it does. First it takes the value of the $q variable and converts it from this:

$q = ['7_%3', '%d|%b;%c}%4,%5~%9.%6{%e!%f+%8-%0#%2*%1&%a<'];

To this; this is the substitution key:

$q = ['7_,3(,d|,b;,c},4,,5~,9.,6{,e!,f+,8-,0#,2*,1&,a<'];

Then all it does is search/replace the value of the $p variable (the mess of symbols) by using the two characters separated by commas above. So it reads in “7″ and “_” from q$ then it does a search for “_” in $p and replaces it with “7″. Next it reads in “3″ and “(“, etc. Continue through the rest of $q.

To deobfuscate the script, simply make this modification:

And the final result appears.

This leads to Impact Exploit Kit. You can find out more about this kit here:

http://malware.dontneedcoffee.com/2012/12/inside-impact-exploit-kit-back-on-track.html
http://malwaremustdie.blogspot.jp/2013/01/lets-say-hello-to-impact-exploit-kit-w.html

I also moved packs around based on feedback from other researchers.

Here is the applet we will be looking at. As Denis mentioned, this is heavily obfuscated and unique to each visitor. There is an embedded object in the JAR file.

This file contains gibberish but there is a visual pattern indicating that it has been XOR’d.

Looking at the file with a hex editor, we can probably conclude that the file has been XOR’d with the following five bytes: C9 CB C3 A2 91

But let’s examine the JAR more closely and see if we can verify this. After looking through the code, we come across this. We can confirm that it is exploiting the latest Java vulnerability (CVE-2013-0422).

Further in the code, we see this. This takes the bytes from arrayOfByte1 and XORs bytes from arrayOfByte2.

Let’s fire up Data Converter and enter those values using the settings you see below. I had to modify this program to better handle decimal keys and fix a bug that affected converting large files. Looks like this code is exploiting an older vulnerability!

Finally, we get to this piece of code.

This code looks similar to the one above so we’ll use Data Converter and the same settings again. This looks interesting and warrants further investigation.

Let’s change the output format to hex and convert it again. Seeing “CAFEBABE” indicates that we just found a hidden class file. If you click on “Write to Binary File”, we can save it directly to a binary file to examine it further.

Opening the class file in JD-GUI, we browse through the code and get to this routine. We see that it is XOR’ing the payload using five bytes.

Now let’s use File Converter using the following settings. The input file is the object found in the JAR file. Pressing the ‘convert’ button results in an executable file that infects the victim’s PC.

This new version of File Converter can now handle keys with positive and negative integers as well as hex values. Note that decimal values of -55, -53, -61, -94, and -111 is the same as hex values of C9, CB, C3, A2, and 91 so entering either keys in this program would yield the same results.

You can download the newer versions of the programs above here. I’ll incorporate the changes in the next version of Converter when I’m done testing.

Again, special thanks to Denis for helping me test the programs.

Under the File menu, I’ve added three new features.

You can import binary files into Converter (but don’t try loading a 100MB file though since that’s not what Converter was meant for). The file contents will show up as hex data which you can send to the main form or back out to a text file.

You can also export binary files from hex data.

If your file is too big for Converter to handle, you can split files into smaller segments (and subsequently join them back together).

If you need to convert a large file, you can always use the Convert Binary File feature. I incorporated new options found in another program I wrote called File Converter. You can read about it here:

Under the Tools menu, I added the Secret Decoder Ring feature.

You can learn how to use this feature from this blog post:

The Convert Base feature now includes a new delimiter per request.

And finally, the Key Search/Convert feature has been enhanced as described in this post:

You can get Converter here. I hope you enjoy this update!

Here’s the infection chain:

tmkgm.lflinkup.com/main.php
alpkfbtgy.lflinkup.com/3227fyw/024776ygcgd.asp?1
alpkfbtgy.lflinkup.com/06592657829ja/qrsop326821?1
alpkfbtgy.lflinkup.com/06592657829ja/rke80886
alpkfbtgy.lflinkup.com/06592657829ja/lib1.pdf
alpkfbtgy.lflinkup.com/06592657829ja/39723568va1start
alpkfbtgy.lflinkup.com/06592657829ja/ncai8236581

The first two URLs are redirectors to the main landing page which is “qrsop326821″. When I first looked at this HTML page, I thought the file got corrupted in Wireshark but it’s actually not.

Here’s the Javascript portion. The script basically loops through the code to re-sort itself back into its original form.

And this is what the deobfuscated code looks like:

Here’s what the transformation looks like since it’s rather difficult to describe.

In a recent update, this pack now separates the Javascript from the HTML page by storing it in an external file.

As you can see from the landing page, there’s two sets of exploits — Java and PDF. The PDF contains the LibTiff exploit and shellcode which does a download and execute of the final payload file. When the Java applet appears to use two exploits and if successful then it downloads a JPEG file that doesn’t have the correct magic number.

Opening the file with a hex editor shows that every other byte is a garbage character and that this is really an executable.

I updated a program I wrote earlier to extract every other byte and dump it to a file.

These are the results I got:

File: rke80886.jar (CVE-2012-4681, CVE-2012-1723)
MD5: E2B9C1892F7BA7D0DC69EBFC91098636
VT: 1 / 43

File: lib1.pdf (CVE-2010-0188)
MD5: B80B7119A6AC1596C7467C1942CD0CD1
VT: 4 / 44

File: EXE Payload
MD5: 7B89036D65CA53FD133FAC4F75DD4770
VT: 27 / 44

This pack hasn’t been identified yet so if anyone knows its name, please drop me a note.

In a version of Black Hole early in the month, you could find this in the HTTP request generated by the Java applet itself:

These strings are the URLs of the payload obscured using a secret decoder so to speak. Every two characters is a byte that represents a position in a key. If you extract the results from the key and concatenate them, you’ll have the URL.

What’s the key? Each author or exploit pack version could have its own unique key but we can try to figure out what the key is; we just have to work in reverse. I wrote a program that might be of some help so let’s try this out on Black Hole version 2.

First we have to obtain this string of encoded characters and the URL of the payload. I’ve done a little Wiresharking that yielded the following:

I’ve pasted the values in the program and set it to “Position Lookup”, two-character formatting with a hex type:

If you press the “Analyze” button right now, it will tell you that the output field is empty (it needs to have a starting string to build off of) so the program will then insert a string of ` characters for you like so:

Now press the “Analyze” button once again. It will fill in the positions of the key based on what is known — the encoded values and the URL.

Let’s get another set of strings from another instance of Black Hole and put that into the program but this time we leave the output value alone because we want to add to our existing (partial) key.

Keep going, trying to find a good mix of characters based off of the payload URL. After a few more, you’ll probably end up with this:

dq&`pg“3twh_`v“kz““o8sa`0`y:`u-m“`2b7`4f““/i`6ej1c=n`.?9`x`5lr“““

The left over ` characters reveal missing values. By counting those up, we can guess that those are upper case characters and a couple more symbols. What we have are all the lower case characters, numbers, and significant symbols which may be enough. Now let’s use the key, paste in just the encoded value, and this time click on the “Decode” button:

Cool! If you haven’t figured out how this position lookup works, the above graphic should make it more clear. The first two bytes of the encoded value (“text input” field) are “0b”. Just above the “Key/Substitution” field are a set of incrementing hex values. Go to position 0x0b and get the character directly underneath it, which is “h”. That’s the first character of the URL! The next two characters are “09″ so go to the 0×09 position and get that character which is “t”. Got it?

Now we can use this secret key to find out what the payload URLs are for this variant of Black Hole v2…until the key is changed.

Interestingly, I analyzed a new exploit pack that Kafeine found called Cool Exploit Pack and noticed the same-looking string of encoded characters. I put that into the program using the Black Hole key and guess what…it worked! What’s the odds of two exploit pack authors using the same secret decoder?

The program also helps you tackle another type of “encoding method” called character substitution. The program acts a little differently for this method. You will need to enter a “plain text” value. I’ve already included a common set of URL-related characters but it probably won’t work for all cases so you can adjust it as needed. In addition, the length of the “plain text” must match the length of the starting string (all those ` characters) since this is a subtitution cipher after all.

Here we have the payload URL for yet another new exploit pack called CritXPack. We plug this into the fields and click on the “Analyze” button. In this particular substitution cipher, the first character of the encoded string is “d” which corresponds to “h”, “X” corresponds to “t”, and so on.

Again, you would find other instances of this exploit pack, collect enough encoded strings and URLs to build up the key until you have all of the useful characters. Then you can keep that key for decoding future CritXPack’s payload URLs.

This program is now available on the Tools page.

This sort of looks like an EXE file structure so I imported the file as hex, truncated it so I could do an XOR search for “MZ” quickly. Found the key!

Now I can load up the entire file then XOR it with the key, 0xA2, but something doesn’t look right.

All the 0xA2 values should actually be 0x00s. The KaiXin author(s) only encoded non-0×00 values. Clever. So I check this box then convert it again.

Okay, that looks better. Now let’s write it out to a binary file and check it against VirusTotal. Here are the results:

MD5: a2528ea962ce621b3b0f190a1d1e904e
VT: 25 / 43

I updated this Data Converter tool to incorporate some new ideas like the one above. It can also enumerate all the keys to an external file because sometimes you don’t know what you are looking for.

I also included the ability to add or subtract a decimal value before and after performing the action. This suggestion came from Kafeine (thanks!) when trying to extract an encrypted class file from a JAR.

If there are no major bugs then I’ll be adding this to the Converter tool later. You can download this and other programs directly from this site now on the Tools page.

Here’s the unsubscribe page:

And the source code showing the malicious iframe tag:

When we follow the TDS link, we get to an HTML page with obfuscated Javascript.

Looking closely at the code, we can make the following change and deobfuscate the script.

We can see that this page delivers two exploits — a Java and PDF exploit.

The interesting bits can be found in the Java applet so let’s have a closer look at this. In this particular section of the Class3 file, it converts that string of hex into another class file.

Let’s just do a quick dump of the hex code to a file and see what the output looks like. We can see a URL. Hmm, what are these four decimal values?

When we make a request to that URL, we get a file. Ugh, this is not an executable file BUT we can see a pattern.

Let’s bring the file into Converter. We see a repeating series of four bytes, 31 7A 4D 2F, where it should be all zeros. Hey, that’s the hexadecimal equivalent of the decimal values above.

If we go to Tools > Key Search/Convert, we can test our assumption by XOR’ing the hex code with the four bytes above. Yup, now that’s an executable!

Now let’s go to File > Convert Binary File and convert it for real.

Here’s the URLs used by Nice Pack but it keeps changing of course:

famfdie.lflinkup.com/in.cgi?15
orkvx.lflinkup.com/ssd
orkvx.lflinkup.com/qFoKRz/NQMwb1jfexg0y?ndr=EOTOTRTw2f2vTBvRTK
orkvx.lflinkup.com/lFoKRz/NQMwb1jfexg0y
orkvx.lflinkup.com/mFoKRz/NQMwb1jfexg0y
orkvx.lflinkup.com/f4FoKRz/NQMwb1jfexg0y

And these are the results from Virus Total:

File: mor.exe
MD5: 9e98e10fb67e9fa76880d05a8417760e
VT: 23 / 42

File: NQMwb1jfexg0y.pdf (CVE-2010-0188)
MD5: eb8cf298785bdba58c44db9db16731cf
VT: 3/44

File: NQMwb1jfexg0y.jar (CVE-2012-1723)
MD5: 67d43b24a9333981efc9df8fa5049894
VT: 4/44

Special thanks to Mila from Contagio!  Be sure to check out her list of exploits used by exploit packs.

Converter v0.4
Some bug fixes and minor updates were made:
* “Convert Base” feature has been expanded to enable you to convert from/to decimal values separated by commas or spaces. Single-value conversions still work.
* The “Convert Custom Base64″ feature now lets you convert to hex as well as text.
* Replaced the “XOR Encrypt/Decrypt” feature with “Key Search/Convert” that allows you to do XOR, ROTate, or ShiFT searches and conversions from/to text, hex, or comma-separated decimal values (see Data Converter below).

File: Converter v0.4.zip
MD5: D4D92BD5D73361205110B0B8ED2B5DD8
Link: http://www.mediafire.com/download.php?gay9f1dq3cv40xb

Revelo v0.5
I fixed some bugs and added a new method called “Redirect Function with Name”. What this allows you to do is redirect a function to an outside script that displays the contents of the eval’d function. As an example, here we see a compressed script. We select the method, enter the word “function”, and set the option to “Replace Starting at Top” to make sure we catch the first topmost instance then click on “Execute”. The results appear on the Results tab.

What’s going on behind-the-scenes is that Revelo modifies the script from this:
<script>eval(function(p,a,c,k,e,d)…

To this:
<script>eval(zyxyz=function(p,a,c,k,e,d)…

Then adds this to the end:
<script>alert(zyxyz);</script>

I also added the ability to do these replacements just once instead of doing it for all matches.

File: Revelo v0.5.zip
MD5: F639E4F6E1E7CA93EFE11EBF1838F6E5
Link: http://www.mediafire.com/download.php?7j6ur67mhruq0it

PHP Converter
This tool really did not need to be made but I was asked by a friend to come up with an easy way to handle obfuscated PHP files found on compromised hosts for a non-PHP, security newbie. The best option is really to learn PHP and have Portable XAMPP (or similar) on-hand.

To “deobfuscate”, choose the nested options from inside-out.

To “obfuscate” text, choose the nested options from outside-in. Credit to James Johnston of TechKnow Professional Services. This program also contains cryptography software by David Ireland of DI Management Services Pty Ltd .

File: PHPConverter.zip
MD5: 859AFA779782408EBB75D8C2FFAD94E6
Link: http://www.mediafire.com/download.php?9amb1ahv8sq0qdy

Data Converter
I’ve been coming across Java applets using XOR encryption for awhile now. Using a debugger like Eclipse is the way to go but sometimes I find that I just want to get an idea of what’s going on so I whipped up this quick and dirty tool.

This program allows you to take in text, hexcode, or decimal values delimited using comma separation. The key and output format can be any of the three as well. You can choose the XOR, ROTate, or ShiFT method and the action can be single (same key for the entire run), sequential (converts the input using the first key, runs through it again using the second key, etc), and consecutive (loops through each of the keys for the length of the input).

Here’s an example taken from a malicious Java applet:

This program is now part of Converter but you can download this separately if you want.

File: File_Converter.zip
MD5: 635957B1B66A8CE5349EDB3EC589E491
Link: http://www.mediafire.com/download.php?c99gh0oir3774g8

Sandbox Tester
I needed to test an automated sandbox analysis tool. Without getting too fancy or sophisticated I came up with several methods to get my test malware through. I eventually came up with just over a dozen methods but this program incorporates only four of those methods. To prevent abuse, you can’t select your own binary to drop. Sorry!

First choose your drop location, add a drop delay value in seconds (set it to 0 for no delay), and the name of the drop file.

The “Name Check” option checks to see if the name of the drop file has changed. If so, the dropper will quit without doing anything. The “Loc Check” checks to see if the location of the drop file is not “c:\documents and settings\” or “c:\users\”. If yes, then the dropper will quit.

If you choose the “Mouse Aware” option then the dropper watches the mouse to see if it moves within the drop delay time. If not then the program quits. If you choose a short delay value then it may not give the dropper enough time to check for movement so bear that in mind.

The last option is “Active Window”. If the dropper sees that the menubar or desktop is in the foreground (top-most window), the program quits. Again, you may need to up the delay value to give enough time to check for user activity.

When you make your selections and click on “Create” then this program creates the dropper. This is what you upload to the sandbox. When the sandbox executes the dropper then an executable is dropped into the location you specified, waits a number of seconds (if applicable), then pops up a “Hello World” message and drops an .EXE file to the current path. That file is actually just a text file that contains the Eicar string.

File: SandboxTester.zip
MD5: E47C4248C4FC8096A81636FD5FD546B1
Link: http://www.mediafire.com/download.php?9bnvyfdeygecnp7

Here’s the panel’s login screen which looks just like Crimepack.

But the rest of the pack is completely different. Here’s the landing page of the exploit pack:

The second layer is a little more challenging:

Once you deobfuscate the code, you’ll be rewarded with a neatly written script complete with comments. Here we see the three Java exploits it’s using:

The next day, the applets were replaced with similar ones:

As you can see from the above, the visiting computer gets hit by all three Java exploits:

CVE-2012-4681
CVE-2011-3544
“Social Engineering Applet”

The last applet is not actually an exploit. It merely tries to convince you that it’s okay to run the applet.

If you don’t have Java installed, CrimeBoss gives you a chance to install it.

The text above is in Portuguese, here’s a translation:

“You do not have Java or it is disabled.
This page has features that require Java to be enabled.
Click here to install the Java plugin.”

There are three interesting aspects to this exploit pack. The first is that this pack distributes the parts of its infection chain onto different domains. This makes the pack a little more resilient.

The second thing is that the payloads are renamed to look like graphic files. Unless you look at the magic numbers, it may not be very obvious that they are executables. Presumably they are hiding in plain sight on these servers. The dropped files range from backdoors to banking Trojans.

dl.dropbox.com/u/104545784/mda.bmp
uploads.boxify.me/90831/gforcea.bmp
andreazza.med.br/xul.gif
desperadoradio.nl/phedex/icon.gif
andreturco.com.br/imgs/a22.gif
kids-trace-com.web11.redehost.com.br/ams5.jpg
dl.dropbox.com/u/80789560/phed0015.ico

The third is that these Java applets download the malicious payload using a specific useragent string as seen here:

This translates to this:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko Firefox/11.0

Another applet used this one:
Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

At the moment, it does not matter what your useragent string is; you can download these payload files at any time using any browser. But it seems plausible that in the future, CrimeBoss’ sites could restrict a direct download unless you have a matching UA string. This would join the other packs that employ a sessionID, cookie, referer, or UA string check to prevent direct downloads.

Java Exploits
File: java7.jar (CVE-2012-4681)
MD5: 171bd05e3d9b7b17f206ff0e2beaeddf
VT: 9/41

File: javab.jar (CVE-2011-3544)
MD5: D679A4EED92C94EF1E75F47F0DDDC2B4
VT: 4/42

File: xul1.jar
MD5: 80F3F65413F5A7A7E07B8FE17E9943E5
VT: 4/42

File: pka1.jar
MD5: F2D9B13E224A4AA2F234BF2316E9E30C
VT: 2/42

Dropped Files
File: a22.gif
MD5: 0a6d3a1505a8f14252b5afc5b71fe800
VT: 6/42

File: gforcea.bmp
MD5: f30526e804df83a2a30068f1d74faeab
VT: 4/41

File: icon.gif
MD5: 5045d1c758ac60f50813fdd8188b3ae8
VT: 6/41

File: mda.bmp
MD5: f474e1d0e4adc3d0b5cba7b17727a4f9
VT: 2/42

File: ams5.jpg
MD5: c39ddd740e730d27346d325222a2302c
VT: 1/42

File: phed0015.ico
MD5: 13B86ED2D78EA2C6DBF6CF7EE7EC5206
VT: 0/42

Here’s the obfuscated exploit page from Neosploit:

When you tidy things up, you can see Neosploit’s signature div tags. The function at the top called “cel” is the deobfuscator (which is later renamed to “dor”). The script sends hex strings to this function to get it deobfuscated, for example, “dor(hit,mud)”. We can monitor what is getting passed through it by writing out the “t” variable.

Another way is to see what’s going on is to view the contents of the div containers. We can do it manually or we can use Revelo. Here I choose the “Intercept DIV Attach with ID” option and enter an asterisk as a wildcard.

After you execute it and we get the deobfuscated results:

The site is now dead but it shows the two different URLs being called up by the script. Each one downloads a Java applet to the user’s computer.

The first JAR delivers the CVE-2012-1723 exploit:

The second JAR exploits the latest Java vulnerability, CVE-2012-4681:

If either succeeds, then a fake AV program gets downloaded and installed on the user’s machine.

File: rW7PHE0d.jar (CVE-2012-1723)
MD5: 70611BC834288033FBC069CAE9F26280
VT: 2/42

File: qU8jMPS9.jar (CVE-2012-4681)
MD5: 5DD8F610A7538F3096138A5259541973
VT: 4/41

File: BfWJroL5.exe
MD5: E40C6CB6D999DC69A55D4504EDF930EC
VT: 10/41