Kahu Security http://www.kahusecurity.com Sat, 12 Jul 2014 05:45:55 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.1 Reversing a PHP Script Dynamically and Statically http://www.kahusecurity.com/2014/reversing-a-php-script-dynamically-and-statically/ http://www.kahusecurity.com/2014/reversing-a-php-script-dynamically-and-statically/#comments Sat, 12 Jul 2014 05:45:55 +0000 http://www.kahusecurity.com/?p=13140 Continue reading ]]> A reader sent me two PHP scripts because the PHP Converter program I wrote wasn’t able to handle it. They are both similar so I’ll just work on one of them in this post. Here’s what it looks like:

2014-07-11_01

And this is what happens when you try to use PHP Converter:

2014-07-11_02

Let’s reverse this script dynamically and then statically.

First, I’ll just change the ‘eval’ keyword to ‘echo’.

2014-07-11_03

And take a peek at what’s going on.

2014-07-11_04

Yikes, this is messed up! I thought the PHP file got corrupted somehow but then I looked closely and noticed several PHP keywords. This is actually a pretty clever technique. Basically the script is converting the strange characters to text but it’s surrounded by long, seemingly random strings that are variable names.

So I figure I would just write it out to a file and then change the ‘eval’ I noticed at the end to ‘echo’.

2014-07-11_05

Here’s the resulting file:

2014-07-11_06

I’ll just make that quick change and run it again.

2014-07-11_07

Cool, now we know what this script does!

Now let’s reverse this script statically.

Here’s a new, fixed version of PHP Converter. I added a filter to present the results of the deobfuscation without stopping if it encounters any strange characters. The characters outside the alphanumeric range will be represented by a neutral character.

2014-07-11_08

I also added the ability to output the result to Base64 format and/or to a file. With both options checked, you will get a text file of the result encoded in Base64 so the binary values will be preserved.

2014-07-11_09

Now I can convert this base64-encoded string to text using Converter.

2014-07-11_10

After cleaning this up, we can see that the section below is XOR’ing the blob using the decimal value of ’30′ which is assigned to the first variable.

2014-07-11_11

I’m going to convert the base64-encoded string to hex this time.

2014-07-11_12

Then send the data to Converter’s Key Search/Convert feature and set the values accordingly:

2014-07-11_13

And I get this result. The junk at the top and bottom is the result of XOR’ing the original text so I can ignore that.

2014-07-11_14

There are other ways to get to the final result but I think these two methods are straightforward and quick/easy to do.

The updated version of PHP Converter can be downloaded here.

]]>
http://www.kahusecurity.com/2014/reversing-a-php-script-dynamically-and-statically/feed/ 0
Deobfuscating PHP Scripts http://www.kahusecurity.com/2014/deobfuscating-php-scripts/ http://www.kahusecurity.com/2014/deobfuscating-php-scripts/#comments Sun, 01 Jun 2014 20:08:35 +0000 http://www.kahusecurity.com/?p=13126 Continue reading ]]> Occasionally people send me PHP scripts to help them analyze it. Most of the time, it’s simply unescaping the script and finding the right variable to echo. I got two tricky ones within the past couple of months and finally got around to writing a program to quickly deobfuscate them. These scripts represent obfuscation methods that make it difficult to read them but they don’t employ character rotation, XOR, base64, etc. I’m not sure if there’s an easier way to do this; if there is, I’d like to hear about it.

I already wrote a tool to handle an older variety of this method and I decided to add functionality to handle the newer ones. I also added a pretty basic (crappy) beautifier and making this available as a separate download (I think I’ll add this to Converter later).

Method 1 – Array Search/Replace
This script uses an array of base64-encoded strings. The second part of the script references specific values from the array. The obfuscated script looks like this:

2014-06-01_01

The idea is to first base64-decode the strings and load them into an array. Loop through the array and replace the calling variables with the actual values.

You should concatenate the strings first. I use Converter but even Notepad will do.

2014-06-01_02

Then you need to base64-decode the strings. Again I’m using Converter.

2014-06-01_03

Using the PHP Script Decoder tool, I paste the result from above to the “Lookup Array” box. I paste the obfuscated script to the input box. When you choose the Array method you have to enter a delimiter (in this case the comma is used) and the search string. The search string is the variable you wish to replace with the value. In this case I enter “_449578015(#)”. The pound sign is a placeholder which the tool needs.

Here’s what it looks like. Now the deobfuscated script is much easier to figure out.

2014-06-01_04

If you want to beautify the script, click on the “Copy Output to Input” button then click on the “Beautify” button.

2014-06-01_05

The result is a simple and rough cleanup of the script.

Method 2 – Random Variables
This script uses randomize variable names and assigns a value to it. The later portion references the value. Here’s what this looks like:

2014-06-01_06

The tool will parse the script and load each variable and associated value into an array. It then does a search for the variable and replaces it with the value.

I just paste the entire script in the input box and choose the “random vars” option. The delimiter for this script is a semi-colon and for the search string I enter ${“GLOBALS”}["#"]=”*”; The pound sign is a placeholder for the variable name and the asterisk is the placeholder for the value.

Here’s the result:

2014-06-01_07

Method 3 – Key Lookup
This script uses a lookup array to build the values for its variables. Each character in this string is loaded into an array:

“,`TD[r)Ej|4*^QXOK\t: @.tl#2%\\L\r_R-~b=Z7zaV{]S+’Gio>gd058up6C!HkwxmvN?nJI(\”FMWc3hYs\$&;\nBA

The script concatenates each character of the value and assigns it to a variable. The tool again does a search and replace of each character. You can optionally concatenate the result. For this particular script, you then need to use the second method and replace the variable name with the value.

2014-06-01_08

Here we go…the first step I do is paste the entire script in the input box and choose the key lookup option. The delimiter is irrelevant. I use $f9[#] as the search string. In the lookup key box I need to paste the key with the starting and ending quotes. The tool will unescape the value so you don’t have to do it yourself.

2014-06-01_09

You can see that the strings should be concatenated so I check the box and click on Convert again.

2014-06-01_10

Now I click on the “Copy Output to Input” button and choose the random vars option. I leave the delimiter to semi-colon and use $GLOBALS['#'] = ‘*’; as my search string.

2014-06-01_11

Ah, much more readable! By the way, you may have seen this on several compromised sites as the output looks something like this:

Linux10+cfcd208495d565ef66e7dff9f98764da
-or-
WINNT20+cfcd208495d565ef66e7dff9f98764da

This script is essentially an emailer.

You can find this program here.

]]>
http://www.kahusecurity.com/2014/deobfuscating-php-scripts/feed/ 0
Reversing RIG EK’s Flash File http://www.kahusecurity.com/2014/reversing-rig-eks-flash-file/ http://www.kahusecurity.com/2014/reversing-rig-eks-flash-file/#comments Sat, 24 May 2014 05:07:24 +0000 http://www.kahusecurity.com/?p=13112 Continue reading ]]> VirusTotal is showing 0 out of 51 for RIG EK’s SWFIE exploit (MD5: 65AFF3A3774298B3ED5BA2C43F8A1979). Here’s a really quick overview on how to reverse this exploit file so we can determine which vulnerability it’s using. This method can also be used on Infinity EK’s flash file and probably others.

First, you need to use your favorite method to decompile the SWF file. I always try to give ActionScriptExtractor the first shot. If it doesn’t work, you might have to use a commercial tool like I did. Looking over the decompiled code, there’s an interesting function called “onus”.

2014-05-23_01

Variable _local5 is assigned a value of “4939333″. This value is used to XOR each value from the large array. The _local2 array consists of Qwords in decimal and hex formats.

I wrote a program that will convert the Qwords to decimals then XOR the values with an XOR key. It will then write it out in little Endian format just like the ActionScript indicates.

2014-05-23_02

After converting the decimal values to hex and writing it out to a binary file, I get another SWF file (MD5: 04FC52BE437FF46465F42994F0DC5AAE). VirusTotal detects this with 3 out of 53 AV with one saying it’s CVE-2013-0634.

2014-05-23_03

The decompiled version looks like this:

2014-05-23_04

Here we see the exploit code:

2014-05-23_05

This part here writes out the shellcode after base64-decoding it.

2014-05-23_06

The Javascript from the landing page contains the base64-encoded shellcode which is read in by the ActionScript.

2014-05-23_07

The code does look similar to CVE-2013-0634 but my understanding of the Flash exploit tells me this is really CVE-2014-0322.

Anyway, the point of this article was really to make available the tool to convert Qword, Dword, and Word values to decimal. I’ll continue using it and work out any kinks before adding it to Converter. You can download this tool here if you want to give it a try.

]]>
http://www.kahusecurity.com/2014/reversing-rig-eks-flash-file/feed/ 0
RIG Exploit Pack http://www.kahusecurity.com/2014/rig-exploit-pack/ http://www.kahusecurity.com/2014/rig-exploit-pack/#comments Tue, 13 May 2014 05:00:47 +0000 http://www.kahusecurity.com/?p=13102 Continue reading ]]> A new exploit pack has been marketed in the underground since last month and appears to be picking up some steam. The new pack is called RIG and touts the following exploits:

Java – CVE-2012-0507, CVE-2013-2465
IE 7/8/9 – CVE-2013-2551
IE 10 – CVE-2013-0322
Flash – CVE-2013-0634
Silverlight – CVE-2013-0074

2014-05-12_01

The pack is said to have an average rate of 8-12% and costs $60 per day or $300 per week.

Here’s what a typical infection chain looks like. Look closely and you can see why this is being pegged as Infinity EK. There are similarities but they are different packs.

2014-05-12_02

On a compromised website, the iframe tag leads to the TDS rotator:

2014-05-12_03

If everything checks out then you get another iframe (the bottom part of the page appears to be a tracker):

2014-05-12_04

On the counter.php page, there’s yet another iframe. This time you get to the landing page of the exploit pack:

2014-05-12_05

The landing page is a large file and consists of five scripts. The top section, through some misdirection and obfuscation, assigns a value of “body” to the “vx” variable which is used by the following four scripts.

2014-05-12_06

Each of the four scripts looks something similar to this. All it’s doing is building up decimal values that are on each line preceding with “pop” to the variable “bui” which is then converted to ASCII and appended to the body element.

2014-05-12_07

This is the result after deobfuscating one of the scripts. This sets up the Java exploit.

2014-05-12_08

Here’s one for Silverlight. You can see the URL to the exploit followed by the shellcode in Base64.

2014-05-12_09

The D&E shellcodes which are passed as a parameter to the exploit code are XOR-encoded each with it’s own unique five-value hex key.

2014-05-12_10

Since the landing page contains all of these scripts, you get hit with several exploits at once leading to multiple payloads asking to bypass UAC. It’s very noisy and inefficient.

2014-05-12_11

If the exploit is successful, the payload is downloaded and executed and then requests are made to the following sites to download crimeware:

zemmes-gimbl .com/b/shoe/1928
chanse-leaf .com/com_phocaguestbook/jquery/

Files called “UpdateFlashPlayer_[random].exe” are downloaded to the temp folder with the hidden attribute set which prompts the user incessantly.

File: applet.jar
MD5: 9c6317f0c22b0782fac5858d0c4c4886
VT: 4/52

File: flash1.swf
MD5: 65aff3a3774298b3ed5ba2c43f8a1979
VT: 0/52

File: flash2.swf
MD5: 40fd69626f5248012b6d5bd2e4d2fc9b
VT: 0/52

File: 264078.exe
MD5: e4f53ece665e71955bf8f9170e3324a1
VT: 9/52

File: ewuwxeu.exe
MD5: ea8dbf470fb0dc41e10d2dcf69f53153
VT: 14/52

File: UpdateFlashPlayer_5386a177.exe
MD5: 60b1cbb5d9af6125d011bd7306afec64
VT: 2/51

File: UpdateFlashPlayer_9609e705.exe
MD5: 8caf8b2f7198bc757541a93267447460
VT: 10/52

]]>
http://www.kahusecurity.com/2014/rig-exploit-pack/feed/ 0
8×8 Script Leads to Infinity Drive-By http://www.kahusecurity.com/2014/8x8-script-leads-to-infinity-drive-by/ http://www.kahusecurity.com/2014/8x8-script-leads-to-infinity-drive-by/#comments Mon, 07 Apr 2014 05:40:37 +0000 http://www.kahusecurity.com/?p=13089 Continue reading ]]> The “8×8″ script I’m referring to includes a link that looks like this:
hxxp://www.example .com/JB3xd6iX.php?id=87342871

And can be detected using a regular expression that looks something like this:
/^.*\/[a-z0-9A-Z]{8}\.php\?id=\d{8}$

One set of links redirect users to social engineering scams (e.g. fake Adobe Flash Player update) that I wrote about earlier. Another set redirects users to Infinity EK (aka “RedKit”, “GoonEK”).

First, let’s see how this drive-by looks like from the users’ perspective.

The user visits a website that’s been compromised. On one of the webpages, there’s a script with the filename containing eight random characters followed by an ID value which has eight digits (i.e. the “8×8″ script).

2014-04-06_01

The user is then redirected to another legitimate website that’s been previously compromised. This site serves up a script that leads to another site.

2014-04-06_02

This site is also legitimate and compromised. It houses the Infinity Exploit Pack script which tries to exploit the user’s browser.

2014-04-06_03

This is what the deobfuscated version of the landing page looks like. If the exploit is successful, there’s a request for the malicious payload file back to the same site.

2014-04-06_04

Infinity has an arsenal that includes two Java, two MSIE, Flash, and Silverlight exploits. The author(s) have been adding updates to their arsenal as well as modifying the links and infrastructure since the last time I analyzed it as RedKit v2.0.

Now let’s look at what’s happening behind the scenes. A webmaster provided me with suspicious files from his compromised website after I informed him his site was redirecting users to a drive-by. (I promised I would not reveal his site name so I redacted and/or modified the following screens.)

Turns out his site was compromised two different times. The first time, the attacker modified at least one HTML page and inserted the following script tags:

2014-04-06_05

Sometime later, the/another attacker modified the index.php file and inserted a PHP script that would download content from another website.

2014-04-06_06

Running this script, makes a request to a backend server and produces a seemingly endless number of new links:

2014-04-06_07

I was very fortunate that the compromised website had both the infected index.php file and the 8×8 script on his server. The link above leads to a PHP script on another site but I’m pretty certain it’s the same as the one below (which is also the same as the one I wrote about earlier).

2014-04-06_08

Deobfuscating the script is no longer a chore so I can extract the contents of the encrypted config string.

2014-04-06_09

Running it produces the TDS IP, key, and other information:

2014-04-06_10

So this is what’s going on…

2014-04-06_11

Here’s a series of packets showing this:

2014-04-06_12

The scripts are all the same and therefore appears to be the work of the same gang behind RedKit v2, Box Fraud, Goon EK, and Infinity.

]]>
http://www.kahusecurity.com/2014/8x8-script-leads-to-infinity-drive-by/feed/ 0
Wild Wild West – 04/2014 http://www.kahusecurity.com/2014/wild-wild-west-042014/ http://www.kahusecurity.com/2014/wild-wild-west-042014/#comments Sun, 06 Apr 2014 01:59:52 +0000 http://www.kahusecurity.com/?p=13072 sorry this is so late. added the following packs:

“Zuponcic”
Infinity (aka “RedKit”, “GoonEK”)
Ramayana (aka “DotkaChef”, “DotCacheF”)
RSPandorasBox
Top-Exp (aka “Magnitude”)

wildwildwest_0414

]]>
http://www.kahusecurity.com/2014/wild-wild-west-042014/feed/ 0
VBE Script Leads to Bank Fraud http://www.kahusecurity.com/2014/vbe-script-leads-to-bank-fraud/ http://www.kahusecurity.com/2014/vbe-script-leads-to-bank-fraud/#comments Sun, 06 Apr 2014 01:54:11 +0000 http://www.kahusecurity.com/?p=13069 Continue reading ]]> I only stumbled on this at the middle so I don’t know how this is being targeted to users. Apparently this particular scam has been out there since at least August 2013 and it’s still up and running.

This is a VBScript Encoded file (VBE) that starts off the fraud:

2014-04-05_01

And it looks like this:

2014-04-05_02

Using a VBE decoder, I can convert the file to get the following. You can go here or here for the decoder.

2014-04-05_03

There’s several functions in this script and the one at the top deobfuscates the content by doing some math to convert decimal values to ASCII. The AppdataPath and File1 variables look interesting so I just add this to the script:

2014-04-05_04

This pops up the deobfuscated values then quits before it executes anything further. Here’s the result which tells us where the file will be written to and where to download the file from.

2014-04-05_05

Let’s get the second VBE file and decode that one as well.

2014-04-05_06

While going through the script, this pops up:

2014-04-05_07

This turns out to be a proxy.pac malicious script! Downloading the third file, I get this obfuscated proxy.pac file.

2014-04-05_08

After I clean this up, here’s what we get:

2014-04-05_09

After analyzing the scripts, here’s what it does…it changes the proxy values in IE and Firefox browsers:

2014-04-05_10

Then, whenever the user visits one of the sites found in the proxy.pac file, they get redirected to a phishing page but the URL bar shows that they are at the right banking site.

2014-04-05_11

Truncating the path reveals an open folder that contain files that make up the phishing page which is a sign we truly are not on the legitimate site.

2014-04-05_12

Here’s what the real banking site looks like:

2014-04-05_13

Packet captures shows that our traffic is indeed being sent to the phisher’s site when we attempt to visit one of those Brazilian bank sites.

2014-04-05_14

Here’s information about the domains and files:

Domain: eua.bestworked[.]com
IP: 64.74.223[.]40

Domain: euas.bestworked[.]com:8082
IP: 64.74.223[.]40

Domain: mn.dmanwork[.]com:8082
IP: 8.5.1[.]49

Filename: update.vbe
MD5: a8f52fb1a543abf5ac18ae2dbc0351e8
VT: 3/48

Filename: seta.vbe
MD5: 3fc44dae258d0316179541db44d09ad7
VT: 4/51

]]>
http://www.kahusecurity.com/2014/vbe-script-leads-to-bank-fraud/feed/ 0
Scout — New Tool Released http://www.kahusecurity.com/2014/scout-new-tool-released/ http://www.kahusecurity.com/2014/scout-new-tool-released/#comments Wed, 26 Mar 2014 05:56:11 +0000 http://www.kahusecurity.com/?p=13053 Continue reading ]]> Here’s another tool that you might find useful when analyzing potentially infected websites. Scout is Pinpoint on steroids. Scout uses the Pinpoint engine and includes a feature from Revelo that makes this more functional and…risky. Let me explain.

Pinpoint downloads webpage components akin to using wget or curl. Pinpoint does not render the content making this safe to use even without a VM. Scout, on the other hand, gives you the ability to render content in select files so it can collect the URLs it’s trying to access (Revelo already includes this feature). This is great for those who don’t know how or have the time to deobfuscate Javascript. You just render the script and catch the results. However, if the file contains exploit code, your computer could get infected.

I did consider simply adding the new features to Pinpoint and calling it v2.0 but this could potentially cause confusion since Pinpoint is a safe tool to use so I decided to leave Pinpoint alone and create a new tool called Scout (I’ll still maintain both code bases). As its name implies, Scout seeks information about your target and does so rather progressively.

One other feature I thought would be useful was to give Scout the ability to take a screenshot of the webpage. The best and safest method I could come up with is using PhantomJS. It uses the WebKit browser engine so it’s way more safer than IE but there is added risk since the infected/malicious page has to be completely rendered. That’s the other reason why I wanted to separate this from Pinpoint.

So let’s see this in action…

Here’s Scout with its two new features:

2014-03-25_01

To activate the screenshot capability, download PhantomJS from here and copy the Windows executable to the same folder that Scout resides in. Now the “Take Screenshot” option lights up and you can enable and disable it as you choose. Scout will automatically create “rasterize.js” which is used to produce the screenshot. You can modify it (e.g. change its user-agent string) and Scout will use it going forward.

2014-03-25_02

Here’s what the workflow might look like. Enter a URL then click on start.

2014-03-25_03

After Scout pulls down the main page, it will launch PhantomJS and perform a screenshot of the site which gets saved as a PNG file:

2014-03-25_04

Viewing Scout’s capture file, we see some obfuscated Javascript in the source code. Since the Pinpoint engine won’t render it, we don’t know what this does.

2014-03-25_05

Copy/paste the Javascript and save it to an HTML file. Be sure it has the <script></script> tags (or <html></html> tags as necessary).

2014-03-25_06

Click on Tools > HTTP Request Simulator, choose the file, then click on Start.

What I’ve done is include some of Revelo’s functionality into Scout. There is a built-in WebBrowser Control that renders the URL. As the WebBrowser Control makes requests to external content (e.g. Javascript, CSS, images, etc) or redirects the browser depending on the webpage contents, Scout will collect the links then drop the HTTP responses before it reaches the browser. This should, in theory, prevent your computer from getting compromised but I can’t guarantee it so you ought to run this in a VM.

2014-03-25_07

Here’s another example…

First, let’s paste in the URL and click on Start:

2014-03-25_08

Here’s the screenshot of the site:

2014-03-25_09

Reviewing Scout’s capture file, we see Javascript (exploit code) from Infinity EK:

2014-03-25_10

Extract the script from the page and save it to an HTML file:

2014-03-25_11

Since this has a lot of scripts, the internal WebBrowser Control may not be able to handle it so you can optionally use your Internet Explorer browser. When you run Scout and click on Tools > HTTP Request Simulator, Scout will automatically set IE’s proxy setting to “localhost:8080″ (which is changed back after you close HTTP Request Simulator). All you need to do is leave the “File” field empty, click on Start, then open the HTML page in IE (note: you can do this with Firefox or Chrome too as long as you set the proxy settings yourself).

Here we see IE executing the js.html file with the exploit code. Scout’s HTTP Request Simulator is catching the requests, dropping the responses, and displaying the results. The VM did not get infected but I’ll never run this on my host computer, just in case. And neither should you.

2014-03-25_12

If you don’t see anything in the “results” box then maybe the script doesn’t have any redirect code or doesn’t reference any external content. Or maybe it relies on jQuery in which case you can paste in the jQuery script into your file.

You can download Scout from tools page.

By the way, I do appreciate all of your emails in support of Pinpoint! I’m glad it is helping you with your analysis and I hope Scout can further your research.

]]>
http://www.kahusecurity.com/2014/scout-new-tool-released/feed/ 0
Converter Updated http://www.kahusecurity.com/2014/converter-updated/ http://www.kahusecurity.com/2014/converter-updated/#comments Mon, 17 Feb 2014 22:34:48 +0000 http://www.kahusecurity.com/?p=13038 Continue reading ]]> The latest version includes several new features and bug fixes:

  • Fixed Mixed Octal to Hex function to handle null char at the end
  • Fixed and enhanced code related to keep/strip filtering functions
  • Fixed unescape handling of null bytes

Unescape File
Under the File menu > Unescape File allows you to unescape a text file. You have the option to beautify the Javascript using JSBeautifier (Note: if it’s not Javascript, you will likely get disappointing results).

2014-02-17_01

Convert Binary File
Added the ability delete bytes in the File > Convert Binary File function. The bytes are deleted before any action is taken.

2014-02-17_02

Sort Text
Under the Format menu > Sort Text you can now sort by characters, rows, or comma-delimited values.

2014-02-17_03

Range Search/Replace
Under the Tools menu > Range Search/Replace enables you to do a search and replace using one of three methods. While you can also do this using regex in Search/Replace Text, this is another way I thought I’d add.

2014-02-17_04

2014-02-17_05

Key Search/Convert – Calculate Distance
Added a method to have Converter try to automatically find a multi-byte XOR key. You can read this blog post where I describe how this works.

Just import a binary file that you suspect is an executable. You only need the first 1K bytes so leave that checkbox at the top checked. Click on the “Calculate Distance…” option. It will automatically paste in the DOS header string and set it to auto mode. Converter will start using offset 1, 2, 3…until the (near) length of your search string. I found it generated too much false positives if I used the entire length. You can get false positives when you have a short search string or large offset.

2014-02-17_06

Converter, File Converter, and Data Converter can all be downloaded from here. Thank you for your support!

]]>
http://www.kahusecurity.com/2014/converter-updated/feed/ 0
Exploring XOR Decryption Methods http://www.kahusecurity.com/2014/exploring-xor-decryption-methods/ http://www.kahusecurity.com/2014/exploring-xor-decryption-methods/#comments Wed, 12 Feb 2014 03:56:59 +0000 http://www.kahusecurity.com/?p=13029 Continue reading ]]> The use of XOR encryption to keep anti-virus, web filters, and even researchers at-bay have been used for many years. While there are stronger encryption algorithms, the XOR cipher is very easy to add to a project, has low overhead, and is still quite effective even today.

Converter has four ways to help you figure out what the XOR key is. For a single XOR key, you can use Converter’s Key Search/Convert. If it’s a PE file it may have the string “This program cannot be run in DOS mode” in the header. Let’s try that. We just need the first 1KB so import the file and leave the “Import First KB” checkbox checked. Make those setting changes and click on the Search button.

2014-02-11_01

The XOR key of 0x8E was found!

If you’re not sure if it is a PE file, you can have Converter enumerate all the XOR values to a text file. To do this, check the “Output First…” box then click on the Search button. Scrolling through the results, you may come across the PE magic and part of the header. The value of 142 is the decimal equivalent of 0x8E.

2014-02-11_02

For XOR keys with more than one value, there’s a couple of ways to find the key besides brute forcing each value. One way is import 1KB of the file once again then copy that to the main screen. Choose Stats > Hex Frequency. The output will show you the number of times each hex value has been seen in the input. Notice that eight hex values show up over 80 times. This is likely the XOR key in no particular order. You can now start brute forcing the file with these values. :)

2014-02-11_03

The second way is to paste the imported data and then choose Tools > Pattern Finder. Converter will try to find the longest repeating pattern in the data string. This will take awhile but you will hopefully get decent results like this:

2014-02-11_04

This isn’t the actual XOR key. You could copy the output to the input box and have it look for the next longest repeating pattern again (and again). But you don’t need to. Here is the result of the first pass:

DCD43089E77A630FDCD43089E77A630FDCD43089E77A630FD
CD43089E77A630FDCD43089E77A630FDCD43089E77A630FDC
D43089E77A630FDCD43089E77A630FDCD43089E77A630FDCD
43089E77A630FDCD43089E77A630FDCD43089E77A630FDCD4
3089E77A630FDCD43089E77A630FDCD43089E77A630FDCD43
089E77A630FDCD43089E77A630FDCD43089E77A630FDCD430
89E77A630FDCD43089E77A630FDCD43089E77A630FDCD4308
9E77A630FD

You can see a pattern with the following string being repeated many times:

DCD43089E77A630F

They look like hex values but we don’t know where one ends and the other begins. One clue is to look at the hex frequency screenshot above. It’s the same values! But we don’t know what is the first value of the XOR key is.

Going back to Key Search/Convert, delete all of the input data except for the first two characters which is 0×80 in this case. Search for “M”. We get the result 0xCD which is the first value in the XOR key.

2014-02-11_05

Now we can figure out what the 8-byte key is:

0xCD 0×43 0×08 0x9E 0×77 0xA6 0×30 0xFD

Let’s test it out…it works!

2014-02-11_06

A couple of weeks ago, I read an article called, “Efficient Detection of XOR-Encoded Traffic” by Josh Homan. This concept is not new but for some reason, his excellent write-up caught my eye so I started to study this more closely. I tried using other algorithms besides XOR but I couldn’t come up with anything more efficient and effective.

Please check out his article as he did a great job explaining the concept (thanks Josh!). The basic idea is to look for the same distance between two values in the input data. Let’s use the same string Josh used in his example,

This program cannot be run in DOS mode.

The distance between “T” and “h”, “h” and “i”, “i” and “s”, etc would be the same even though the string has been XOR-encrypted with a single XOR value. If the XOR key is four bytes for example, then you need to offset by the same value and look for the same distance between “T” and ” “, “h” and “p”, “i” and “r”, etc.

I’ve added the concept to the next version of Converter which I’m still testing. I had to modify the Key Search section to accommodate for this but it seems to work pretty well. I do get false positives when the search string is short or the offset is large.

To use this feature, import 1KB of your data and choose “Calculate Distance…”. Converter will pre-fill the Match String for you. If you toggle between Single Key Search and Calculate Distance, the Match String will switch between “This program cannot be run in DOS mode.” and “This program must be run under Win32″ for you.

If you leave the offset at 0, it will automatically go through the length of your search string and will try to find the first match. Enter an offset if you want to try a specific XOR key length.

2014-02-11_07

The same 8-byte XOR key is found but again, we’re not sure what value goes first. Paste the key, set the options, and click on Convert. If that doesn’t work, you need to shift the XOR key over by one so just click on the new “Rotate Key” button and it does it automatically.

2014-02-11_08

Once you have your key, use Converter’s File > Convert Binary File to process the entire file.

Again, it’s not perfect and you will encounter false positives but should give you a great starting point.

So then I thought, why stop at this — why not have a tool that can automatically XOR-decrypt a file? I needed to find a good live example to test my theory on…

By now I’m sure you have read about GameOver ZeuS now using encryption to get their files past network security. If not, you can read these two write-ups:

CyberCrime & Doing Time – GameOver Zeus now uses Encryption to bypass Perimeter Security
CrySyS Blog – GameOver Zeus now uses Encryption to bypass Perimeter Security – .enc encryption

Based on CrySyS’ writeup, the downloader program downloads an “.enc” file, XORs the file with a four-byte key, then decompresses it using LZNT1. If I had to do this manually, I would either extract the key from RAM after running the downloader or figuring out the key in Converter as described above. But by using Josh’s technique, I can automatically find the key.

Here’s the plan for a POC:

  • Open the “.enc” file and check for the “ZZT ” magic (0x5A5A5000)
  • Remove the magic bytes
  • Calculate the distance for “program” then shift the XOR key over by one
  • Decrypt the file using the XOR key
  • Write it to a temp file (for debugging purposes)
  • Uncompress the file using LZNT1
  • Write out the PE file

The LZNT1 tool they used isn’t able to decompress everything for some reason. I had the same problem too but this works most of the time. There is a debug checkbox that will show you the XOR key it found and preserve that temp file so you can check it out.

I found three live samples here:
hxxp://farmyarddog .co.uk/images/pdf.enc (97B200826B7A526D91FDA4C56DC438AE)
hxxp://svsmills .com/images/pdf.enc (2FF56C80DAE376FED059E12033690DFC)
hxxp://mararu .ro/Media/07UKex.enc (9DF4F00EF32806905C3E92286FDE7F0B)

Here’s the hex view of one of the files showing its magic bytes:

2014-02-11_09

I run the program on each of the files:

2014-02-11_10

And I get back three decrypted and uncompressed files automatically:

decrypted1.exe (542A5A6F04DDCAD3EFFC72121C59E332)
decrypted2.exe (11E9BF6E9FEDD3EC64163594371BA790)
decrypted3.exe (49686AB2AE3ECF219024A6E4F990AB79)

Here’s the hex view of the temp file (after it’s XOR’d and before it’s decompressed). If you look closely you’ll see that there are some null bytes in the DOS header which is why the program isn’t searching for the entire header string, just the word “program”.

2014-02-11_11

Few notes:

  • If the .enc file doesn’t have the magic bytes then the program will end
  • If the XOR keys cannot be found automatically (probably because the file is not a PE), the program will end
  • If the decompression process fails for some reason then you might get a small file with partial results

You can download the tool from here.

]]>
http://www.kahusecurity.com/2014/exploring-xor-decryption-methods/feed/ 0
Pinpointing Malicious Redirects http://www.kahusecurity.com/2014/pinpointing-malicious-redirects/ http://www.kahusecurity.com/2014/pinpointing-malicious-redirects/#comments Sat, 08 Feb 2014 20:36:28 +0000 http://www.kahusecurity.com/?p=13017 Continue reading ]]> Cybercriminals are constantly thinking up new ways to redirect unsuspecting visitors to their drive-by landing page. The guys over at Sucuri often find really interesting redirects that they’ve come up with.

What I have been doing lately is documenting these redirection methods so that I can program Pinpoint to look for these methods when it analyzes webpages. I believe it’s useful to identify these methods so that you can tell if it’s an Infinity EK (aka RedKit, GoonKit), ramayana EK (aka DotkaChef), DarkLeech, or another type of website infection.

Here’s what I collected so far. Some of these methods are deprecated, browser-specific, or won’t work unless the browser is in compatibility mode but I’ve captured them anyway (btw, these two sites were very helpful).

Meta Refresh
<meta http-equiv=”location” content=”url=http://www.google.com” />
<meta http-equiv=”refresh” content=”0;url=http://www.google.com” />

Javascript Redirect
document.domain=”http://www.google.com”;
document.location=”http://www.google.com”;
document.location.href=”http://www.google.com”;
document.URL=”http://www.google.com”;
location=”http://www.google.com”;
location.assign(“http://www.google.com”);
location.host=”http://www.google.com”;
location.hostname=”http://www.google.com”;
location.href=”http://www.google.com”;
location.reload(“http://www.google.com”);
location.reload=”http://www.google.com”;
location.replace(“http://www.google.com”);
self.location=”http://www.google.com”;
top.location=”http://www.google.com”;
top.location.href=”http://www.google.com”;
window.location=”http://www.google.com”;
window.location.assign(“http://www.google.com”);
window.location.href=”http://www.google.com”;
window.location.replace(“http://www.google.com”);
window.navigate(“http://www.google.com”);
window.open(“http://www.google.com”);
window.showModalDialog(“http://www.google.com”);
window.showModelessDialog(“http://www.google.com”);

CSS
<div style=”width:expression(document.location(“http://www.google.com”))”>hello</div>
<style>body{width:ex/**/pression(document.location(“http://www.google.com”));}</style>
<style>body{background-image:url(javascript:document.location=”http://www.google.com”);}</style>

OnError
<img src=”missing.jpg” onerror=document.location=”http://www.google.com”;>

Other
By changing the data type to Javascript, it will decode and execute the script that’s in base64:

<script src=”data:text/javascript;base64,dG9wLmxvY2F0aW9uPSJodHRwOi8vd3d3Lmdvb2dsZS5jb20iOw==”></script>

You don’t actually need to define the data type as this works too:

<script src=”data:;base64,dG9wLmxvY2F0aW9uPSJodHRwOi8vd3d3Lmdvb2dsZS5jb20iOw==”></script>

Same thing here except the data type is set to HTML:

<object data=”data:text/html;base64,PHNjcmlwdD50b3AubG9jYXRpb249Imh0dHA6Ly93d3cuZ29vZ2xlLmNvbSI7PC9zY3JpcHQ+”>

By saving the redirect content in an external file, it will be read and executed with this:

<object data=”redir.htm” type=”text/html”>

In this redirect example, the name of the file holds the key. The script reads in the filename and after subtracting 5 from the decimal equivalent of the characters, converts it to “google.com” which you are redirected to.

2014-02-08_01

I saw a similar example in the wild awhile back. In this script, I assigned colors of various parts of the webpage but those are actually decimal values of the redirect script.

2014-02-08_02

First, let me show you what the webpage looks like. I just searched for random images on Google and put them on the webpage.

2014-02-08_03

Now have a look at the source code and you can see what I’m using the images for. The script grabs the width and height of each photo and converts these decimal values to text which is the redirect script. This one took a lot of patience since I had to resize each picture to the decimal values I needed without overly distorting the images.

2014-02-08_04

For this redirect I use the obfuscation method found in live examples and combine it with the technique above. The logo.png’s width and height was also resized to the decimal values I needed then referenced by the script. This value is the key (multiplier) that converts the “x-y coodinates” at the top into the redirect script.

2014-02-08_05

Here, I embed a secret value at the end of a PNG graphic file. I use VBScript to extract the bytes I needed which are converted into the redirect script.

2014-02-08_06

Here’s the shot of the data I added to the graphic file using a hex editor.

2014-02-08_07

Here’s a crude method to extract data from a photo, convert the bits into text then eval the result. This works on older versions of IE. The code, Binary Ajax, from this site can be used to make this work on newer versions.

2014-02-08_08

To make this, I just grabbed a random image from Google:

2014-02-08_09

Then I added the hex equivalent of the redirect script in the “Authors” field.

2014-02-08_10

The bytes are extracted with the help of VBScript. The Javascript portion converts the hex to ASCII and evaluates it. And like the rest, you end up on google.com.

Besides detecting these methods (or at the least captures the main parts and writes it out to the cleaned up output file for your review), the latest version of Pinpoint now includes several new features and bug fixes:

  • Removed log option since that should always be enabled
  • Added stats to log file (multiple calls will be counted each time)
  • Included the HTTP request to the raw log file
  • Ability to add to the header (use ^p to insert CRLF)
  • Finds links on a webpage up to five levels deep
  • Ability to access webpages when a port is specified (e.g. example.com:8080)
  • Ability to make a GET or POST on the initial request
  • Unescapes links before making a request to them

Here’s a live example of Pinpoint doing its thing. (If you want to see more examples, you can read this introductory post.)

2014-02-08_11

You can see an iframe tag with a strange-looking URL in the above pic. Viewing the log file reveals that this file has a high “entropy” value of 86.35% and is referenced on the main page.

2014-02-08_12

The file called “pinpoint_clean.txt” is a cleaned-up version of the webpages that only shows key elements. Here you can see the malicious iframe tag.

2014-02-08_13

You can download Pinpoint here.

]]>
http://www.kahusecurity.com/2014/pinpointing-malicious-redirects/feed/ 0
Revelo Updated http://www.kahusecurity.com/2014/revelo-updated/ http://www.kahusecurity.com/2014/revelo-updated/#comments Fri, 07 Feb 2014 05:10:00 +0000 http://www.kahusecurity.com/?p=13002 Continue reading ]]> I’ve been noticing obfuscated Javascript using a function that returns the deobfuscated result more and more lately so I added a new method to catch this.

2014-02-06_01

Here’s an obfuscated script. It’s not that difficult but it does look intimidating!

2014-02-06_02

First I loaded the script and made sure that the “<script></script>” tags are present. This is important to Revelo because it uses this exact string as a marker to add content before or after the opening or closing script tag.

Next, I click on the “Highlight Decryption Clues” button. This gives you hints to look for in the script — functions, variable accumulators, and now returns. What this shows is the variable “IBq” is accumulating a result. (This is the only accumulator in the entire script.) Then the results get returned to the calling function.

2014-02-06_03

Just choose the new method called “Intercept Return and Variable” and paste in the actual return statement “return(IBq)”. You need to paste the “return” keyword too because there’s other combinations.

2014-02-06_04

Click on the “Execute” button and go the Results tab to get the deobfuscated text. (Note: the results contain escaped characters but it is essentially deobfuscated.)

2014-02-06_05

The other change was that I updated the JSBeautify script with the latest version from jsbeautifier.org .

You can find Revelo here.

]]>
http://www.kahusecurity.com/2014/revelo-updated/feed/ 0
Box.php Fraud Kit http://www.kahusecurity.com/2014/box-php-fraud-kit/ http://www.kahusecurity.com/2014/box-php-fraud-kit/#comments Fri, 31 Jan 2014 04:20:10 +0000 http://www.kahusecurity.com/?p=12996 Continue reading ]]> I’ve been researching that fake Adobe Flash update and Neutrino EK redirect that other fine researchers have been writing about:

blog.spiderlabs.com/2014/01/beware-bats-hide-in-your-jquery-.html
blog.sucuri.net/2014/01/website-mesh-networks-distributing-malware.html
www.f-secure.com/weblog/archives/00002659.html
blog.malwarebytes.org/online-security/2014/01/neutrino-delivers-fake-flash-malware-hosted-on-skydrive/

I don’t want to duplicate too much of what they have already covered but here’s what I’ve discovered so far…

Compromised websites have this script injected in HTML pages or external Javascript files (see SpiderLabs’ blog):

2014-01-30._01

Here are some other examples:

v008642[.]home[.]net[.]pl/pub/ALwX12uL[.]php?id=56254554
m1[.]home[.]pl/pub/pnrAtOjy[.]php?id=25916810
www[.]uacups[.]com/YZivZBZ8[.]php?id=18279488
crm[.]autotrim[.]ru/BgOXgTDu[.]php?id=53381973
www[.]luxuryholidaycottages-scotland[.]com/yQ0ofabY[.]php?id=19327629
79[.]96[.]53[.]47/pub/KUnJWUSz[.]php?id=10665478
tennesseechristmastree[.]org/z3vZkP8y[.]php?id=123805228
bluemot[.]com/TRAVEL%20PASS%20PROYECTO%209%20JULIO_/PSV6HvQ8[.]php?id=10431893
www[.]dortmund-vegan[.]de/MyNHgdft[.]php?id=123562613
salvatorismater[.]home[.]pl/projekt/xUXpaFdw[.]php?id=55870772
svstall[.]at/CeXCJgtr[.]php?id=27970583
www[.]telecomdata[.]ro/qRdWb723[.]php?id=101043310
www[.]dvangelder[.]nl/AtGvHSaG[.]php?id=3792231
bestwaytolearnmandarin[.]com/root/NdOmB5M7[.]php?id=60559313
laireduvin[.]fr/img/O2ApKvh4[.]php?id=60559313
bluegrassfirstclass[.]com/Joseph/7vPt8Jm5[.]php
www[.]billingborough[.]lincs[.]sch[.]uk/attachments/4g3IIYEj[.]php?id=57110286
heritageindiaimages[.]com/gallery_images/GILk7gke[.]php?id=63553146
web230[.]webgo24-server8[.]de/F1wxFBty[.]php?id=58237817
csfirearms[.]com/flash/6Is6c3hB[.]php?id=56543812
svp-stadt-sursee[.]ch/zVilDE4Z[.]php?id=51288531
patchwerk[.]net/pics/fx9bLB38[.]php?id=115311343
www[.]alessiosatta[.]it/img/6QeiNof2[.]php?id=52484468
kavelnieuws[.]nl/cgi-bin/yWqMkTiL[.]php?id=46362613
www[.]dvangelder[.]nl/AtGvHSaG[.]php?id=46626551
wg2c7cfgx[.]homepage[.]t-online[.]de/kontakt/dw1sPuVj[.]php?id=58215025

After a few moments, the visiting website shows a frame offering an Adobe Flash Player update.

2014-01-30._02

Clicking on the link leads to a malicious executable being download. I’m not sure how successful this fraud campaign is but it looks pretty convincing to untrained users.

The landing page of that injected script sets up the fake Adobe Flash Player update frame then calls an external HTML file. You can see the reference to “b.html” in the HTML page below.

2014-01-30._03

Sometime in mid-January, the landing page was updated to include a call to the Neutrino Exploit Kit. Now it seems to be redirecting to the Nuclear Exploit Kit.

2014-01-30._04

Going back to the fake update, here’s a portion of the “b.html” page. The “skydrive.live.com” link is where the malware resides.

2014-01-30._05

After checking numerous sites for additional clues, I was lucky to find an open FTP server so I could download the files behind this campaign.

2014-01-30._06

The HTML files are different pages that try to convince users to download VLC Player, VIO Player, to disable AdBlock, or to enable Javascript.

2014-01-30._07

There are three PHP files. In the “b.html” file, there’s an AJAX call to “checker.php”. This PHP file grabs the visitor’s IP, presumably for banning repeat visitors and/or to check if it belongs to security companies or sandboxes.

2014-01-30._08

The second file, “okaybox.php”, looks like this:

2014-01-30._09

After deobfuscating this, the script turns out to be WSO Shell with weird comments embedded in the script used as fillers.

2014-01-30._10

Interestingly, the individual(s) behind this “kit” often uses a PHP shell with a filename that starts with a four-letter dictionary word followed by “box.php” (e.g. agedbox.php, lonebox.php, pastbox.php, ripebox.php, etc.).

The third PHP file is what the compromised website redirects the users to and looks like this. The script has three parts. The top part has a “cfg” variable. The second part has an array of base64 strings. The third part is the main code that references the array.

2014-01-30._11

You can use Converter’s Array Search/Replace function to deobfuscate this in such a way so you can see what it’s doing but not necessarily to run it (unless you fix the variables by adding quotes where applicable).

2014-01-30._12

What this script basically does is decrypt the “cfg” variable, make a request to some site and pass information about the user and server to it, then take some action depending on the results.

2014-01-30._13

You can fix up the code so you can decrypt the “cfg” variable manually. Cool!

2014-01-30._14

Now we can mimic the script and see what happens. I constructed the URL based on the code (don’t visit this link if you don’t know what you’re doing!):

hxxp://109.202.108 .4/mantds/egiybka.php?dom=http://www.somesite .com/&ref=http://www.othersite .com/&ip=10.10.10 .10&prox=no&agent=Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)

2014-01-30._15

This is the same landing page we got at the very top of this article except the iframe source now references our fake site.

]]>
http://www.kahusecurity.com/2014/box-php-fraud-kit/feed/ 0
Sneaky Redirect to Exploit Kit http://www.kahusecurity.com/2014/sneaky-redirect-to-exploit-kit/ http://www.kahusecurity.com/2014/sneaky-redirect-to-exploit-kit/#comments Mon, 13 Jan 2014 01:26:53 +0000 http://www.kahusecurity.com/?p=12973 Continue reading ]]> While I was testing a Pinpoint update, I found a sneaky method to redirect unsuspecting users to Neutrino EK. This one was interesting to me so I thought I would document it here.

Here’s the website I visited…looks suspicious already:

2014-01-12_01

There was a reference to an external Javascript file:

2014-01-12_02

The file is obfuscated Javascript which is a red flag:

2014-01-12_03

I found the malicious redirect, or so I thought…

2014-01-12_04

Long story short, this led nowhere. Going back to the main page, there is a call to a Flash file at the bottom.

2014-01-12_05

Reviewing the ActionScript reveals something interesting. It reads in a PNG file called “gray-bg.png”, extracts every other character, then evals it.
2014-01-12_06

The “PNG file is not a graphic file but a renamed text file.

2014-01-12_07

I used Converter to extract one character every two positions and got this:

2014-01-12_08

The URL leads to the Neutrino landing page.

]]>
http://www.kahusecurity.com/2014/sneaky-redirect-to-exploit-kit/feed/ 0
Exploit Delivery Networks http://www.kahusecurity.com/2014/exploit-delivery-networks/ http://www.kahusecurity.com/2014/exploit-delivery-networks/#comments Fri, 10 Jan 2014 04:00:46 +0000 http://www.kahusecurity.com/?p=12965 Continue reading ]]> Exploit packs are normally set up on a hacker-controlled server. Compromised websites or malicious email links lead unsuspecting users to the drive-by landing page on the server. While this keeps the main control panel, renter’s panel, crypter, statistics, etc all in one place, it’s vulnerable to a take-down resulting in a major disruption and a loss of statistical data among other things.

We might be seeing the beginning of a new trend where distributed, self-contained exploit packs are installed on multiple compromised websites. A back-end server pushes out updates to and retrieves statistics from these websites. Take-downs of these compromised websites hosting the exploit packs don’t cause a major disruption anymore. The hackers just compromise other websites and quickly build it back up.

This is basically a content delivery network but for exploits — an “Exploit Delivery Network”, if you will. RedKit is a prime example (you can read about it here). Another exploit pack was recently revealed which operates in a similar manner.

Special thanks to a colleague of mine who provided me with intel and permission to write about this. Also thanks to a forum administrator who provided me with the files after his site was compromised.

Ramayana Exploit Pack
The “DotkaChef” exploit pack was discovered several months ago. Its real name is ramayana. Recently, the cybercriminals behind ramayana targeted numerous forums running vulnerable versions of IP.Board (read more here). After successfully exploiting the website, a folder is created with the self-contained exploit pack copied to it.

2014-01-09_01

The PHP script verifies that the incoming URL contains the correct parameters and values otherwise you won’t get infected. This prevents researchers from trying to analyze the pack. Here’s an example exploit chain related to ramayana:

website/panel/js/fe0e2feefe/?=MDct5ibpFWbf12c8lzM1ATN4YDM1UDMwk
zM89SZmVWZmJTZwUmZvMnavwWZuFGcvUGdpNnYld3LvoDc0RHa8NnZ
website/panel/js/fe0e2feefe/?f=a&k=3900550685053931
website/panel/js/fe0e2feefe/?f=s&k=3900550685053919
website/panel/js/fe0e2feefe/?f=sm_main.mp3&k=3900550685053942

Here’s the part of the script that sends the exploit over. There are two Java exploits used — atom.jar (CVE-2013-2423) and byte.jar (CVE-2013-1493).

2014-01-09_02

The Java applets and their related payloads are the four other files you see in the folder screenshot above. Those files are base64-encoded and are decoded upon delivery.

2014-01-09_03

A stats file is also created which contains the key parameter from the URL and a status code.

2014-01-09_04

The PHP script defines the values of the status code:

2014-01-09_05

The backend system that controls the exploit pack nodes runs Python. It does a health check, builds the exploit pack files, pushes out updates, and other things. And of course there is a dashboard with a statistics panel which is fed by a stat-harvesting script. This appears to be an important measure of an exploit pack’s success and therefore part of most control panels.

Summary
“RedKit” and ramayana may represent a new class of exploit packs and an evolutionary improvement over their peers. Their exploitation methods remains the same but the delivery system uniquely leverages compromised websites to host disposable components of their exploit pack in order to maximize resiliency, protect their backend systems, and ultimately, to ensure the longevity of their criminal operations. Time will tell if Exploit Delivery Networks become the new norm but it’s something to keep a close eye on nonetheless.

]]>
http://www.kahusecurity.com/2014/exploit-delivery-networks/feed/ 0
The Resurrection of RedKit http://www.kahusecurity.com/2014/the-resurrection-of-redkit/ http://www.kahusecurity.com/2014/the-resurrection-of-redkit/#comments Wed, 08 Jan 2014 04:45:38 +0000 http://www.kahusecurity.com/?p=12960 Continue reading ]]> “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.

2014-01-07_01

Originally, a typical RedKit infection chain looked something like this:

2014-01-07_02

RedKit v2.0
Back in November 2013, this was the malicious iframe tag that led unsuspecting visitors to a drive-by landing page:

2014-01-07_03

Joel Esler identified this as a new exploit kit and called it “Goon EK”. The infection chain looked like this:

2014-01-07_04

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”.

2014-01-07_05

The infrastructure required one less tier of compromised hosts and looked something like this:

2014-01-07_06

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:

2014-01-07_07

This is what the redirection to the landing page looks like:

2014-01-07_08

And this is the infection chain:

2014-01-07_09

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:

2014-01-07_10

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.

2014-01-07_11

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”.

2014-01-07_12

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.

2014-01-07_13

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.

2014-01-07_14

Here are the exploits used by this version of RedKit:

2014-01-07_15

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.

2014-01-07_16

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:

2014-01-07_17

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.

2014-01-07_18

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:

2014-01-07_19

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.

2014-01-07_20

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:

2014-01-07_21

]]>
http://www.kahusecurity.com/2014/the-resurrection-of-redkit/feed/ 0
Pinpoint Tool Released http://www.kahusecurity.com/2014/pinpoint-tool-released/ http://www.kahusecurity.com/2014/pinpoint-tool-released/#comments Fri, 03 Jan 2014 04:59:59 +0000 http://www.kahusecurity.com/?p=12938 Continue reading ]]> There are many times where I come across a drive-by download, especially malvertisements, and it takes me awhile to figure out which file on the compromised website is infected. I wrote Pinpoint to help me find the malicious objects faster so I can provide that info to webmasters for clean-up purposes. My hope is that this tool will be helpful to you as well.

2014-01-02_01

Pinpoint works like wget/curl in that it just fetches a webpage without rendering any script. Pinpoint will then try to determine which links are used to make up the webpage such as Javascript, CSS, frames, and iframes and downloads those files too (some Javascript content will produce incorrect links). The list of links it finds shows up in the document tree on the main window.

At the same time, a log file is created which shows the links and in which file the link resided in. It will also download the file and calculate the “entropy”; the higher the value, the more rubbish characters it found which may help identify obfuscated Javascript.

You can of course spoof the user-agent string and referer values to ilicit a malicious response from the website. There’s also a function to clear your cookies (see Options menu item) since many exploit packs check for the presence of cookies on repeated visits. Use Tor to get another IP address since it’ll get banned usually after the first visit.

Here are a few examples to help you better understand what this program does.

Example #1
Visiting the website in the screenshot below with the appropriate user-agent and referer values reveals a suspicious-looking iframe.

2014-01-02_02

Opening log.txt shows the files that make up the webpage. The second URL from the top looks suspicious and has a 51% entropy value which is not really high but may indicate the presense of some obfuscated Javascript.

2014-01-02_03

By default, there are two other files that are created. The capture.txt contains the HTML source code of all of the pages it fetched. You can see the main webpage and somewhere in there is the malicious iframe. Under that is the HTML source code of the iframed page.

While your computer is safe since none of the scripts are executed, your anti-virus may still detect malicious scripts and trigger an alert (and blacklist my Pinpoint program in the process). Ideally you should be doing all of this in a virtual machine without AV anyway.

2014-01-02_04

The second file that gets created is clean.txt which is a cleaned up version of the HTML source code that just contains Javascript, frame, iframe, calls to external scripts, etc. This should help you locate the malicious content faster. Unfortunately, you may still have to figure out where in the source code the malicious content is.

2014-01-02_05

Example #2
Another infected website is visited and it shows two suspicious links — one in the external Javascript section and the second in the iframe section.

2014-01-02_06

Here’s the log file that shows several things. First the presence of the external Javascript file about half-way down. The second is the last file with a weird URL. The entropy value is very high for this one which means this is likely heavily obfuscated (or packed/compressed).

The request chain reveals that the main page called up the external Javascript file and that file called up the iframe.

2014-01-02_07

Here’s the capture file which shows that iframe page with the entropy value of 86.48%.

2014-01-02_08

And here’s the clean file showing the external Javascript file. By the way, I made everything left-justified in this file to make it quickly readable.

2014-01-02_09

Example #3
Here’s the last example. This one doesn’t show anything in the document tree because there’s no links on the page.

2014-01-02_10

The log file shows content with a relatively high amount of entropy.

2014-01-02_11

The capture file shows obfuscated Javascript appended to legitimate webpage contents.

2014-01-02_12

Finally, the clean file shows the important bits.

2014-01-02_13

Most of the options don’t need any explanation but here’s a brief description of those that do:

Disable Compression – sends the HTTP request without the encoding option
Enable Entropy – performs the entropy check
Ignore Safe Sites – ignores common sites that host frameworks, ads, and other legitimate content so it doesn’t get downloaded
Ignore CSS – ignores external CSS files so that it doesn’t get downloaded

When visiting a large website full of links, AJAX calls, and embedded content, Pinpoint may choke on it. I’ll explore other methods but for now this seems to work fine most of the time. You can find the tool here.

]]>
http://www.kahusecurity.com/2014/pinpoint-tool-released/feed/ 0
Analyzing DotkaChef Exploit Pack http://www.kahusecurity.com/2013/analyzing-dotkachef-exploit-pack/ http://www.kahusecurity.com/2013/analyzing-dotkachef-exploit-pack/#comments Fri, 20 Dec 2013 05:51:56 +0000 http://www.kahusecurity.com/?p=12923 Continue reading ]]> “DotkaChef” (aka DotCache, DotCacheF) was discovered by Chris Wakelin (@EKwatcher) several months ago. Today we noticed that several things have changed but it’s functionally the same.

If you look closely at the websites infecting visitors’ computers linked to “DotkaChef”, they are running Invision Power Board (IP.Board). It’s quite possible that cybercriminals have been targeting a vulnerability in old installations of IP.Board, specifically versions <= 3.3.4 (CVE-2012-5692 - Unserialized PHP Code Execution).

2013-12-19_01

When a website is successfully compromised, the “DotkaChef” Pack gets uploaded to the server in one folder with random characters. This appears to be a self-contained, portable exploit pack.

Back in June or so, the URLs looked like this (and thus its name):

website/upload/.cache/?f=atom.jar&k=2341993693027637&h=baf5291d12f88f53
website/upload/.cache/?f=site.jar&k=2341993693027615&h=baf5291d12f88f53
website/upload/.cache/?f=sm_main.mp3&k=2341993693027648&h=baf5291d12f88f53

Since then, the URL formats have changed and no longer use the “/.cache/” folder.

website/panel/js/fe0e2feefe/?=MDct5ibpFWbf12c8lzM1ATN4YDM1UDMwk zM89SZmVWZmJTZwUmZvMnavwWZuFGcvUGdpNnYld3LvoDc0RHa8NnZ
website/panel/js/fe0e2feefe/?f=a&k=3900550685053931
website/panel/js/fe0e2feefe/?f=s&k=3900550685053919
website/panel/js/fe0e2feefe/?f=sm_main.mp3&k=3900550685053942

Let’s have a closer look…

The URL for the landing page has a bunch of random characters. This is actually base64 characters in reverse. Reversing and de-base64’ing the string reveals the following.

fs|http://website/panel/js/fe0e2feefe/|39005506850539|sm_main.mp3

The pipe character is used as a delimiter to separate out “fs”, the website path, a 14-digit “key”, and the payload. When the malicious URLs are generated, the “k” variable contains a 16-digit number with the 14-digit “key” as the base.

The “f” variable is associated with the malicious Java applet. This kit uses two Java exploits and the “a(tom.jar)” and “s(ite.jar)” values correspond to the exploit to be used.

If you were to hit the page with an incorrect URL, you will see this error message:

2013-12-19_02

When the correct URL is used, you will get the landing page. The landing page has Javascript which uses JJEncode for its obfuscation which you can see below (I wrote about how to deobfuscate this earlier):

2013-12-19_03

The deobfuscated version looks like this. It’s calling up the “atom.jar” exploit which abuses CVE-2013-2423.

2013-12-19_04

Using JD-GUI, we can see that there’s little in the way of obfuscation as it’s using base64 to convert its strings. It reads in the URL from the landing page and sends the payload to the computer.

2013-12-19_05

The other Java applet is basically doing the same thing. This applet exploits CVE-2013-1493.

2013-12-19_06

The payload comes down with the “mp3” file extension that gets renamed then executed. You will get one of two payloads – Zbot or Zaccess.

Finally, the exploit pack keeps track of successful and unsuccessful loads. Each row contains the key, a pipe delimiter, and a status code. The status code of “466” indicates it was a successful load.

2013-12-19_07

By reviewing the logs, there are quite a number of successful loads making this a simple yet effective exploit pack.

File: atom.jar (CVE-2013-2423)
MD5: 36D157C2EE62CF4BABA43497983739AA
VT: 3/49

File: site.jar (CVE-2013-1493)
MD5: FDCF4174445C303FC20494D9B24D7E7D
VT: 5/48

File: bb.mp3 (Zbot)
MD5: 29028CB338DFA191574939D281F1B385
VT: 24/47

File: sm_main.mp3 (Zaccess)
MD5: B6B0F0FE2033608579B4FA55D2993486
VT: 36/49

]]>
http://www.kahusecurity.com/2013/analyzing-dotkachef-exploit-pack/feed/ 0
Wild Wild West – 12/2013 http://www.kahusecurity.com/2013/wild-wild-west-122013/ http://www.kahusecurity.com/2013/wild-wild-west-122013/#comments Mon, 02 Dec 2013 00:56:07 +0000 http://www.kahusecurity.com/?p=12912 Added the following packs:

White Lotus
CK Exploit Kit
“x2o Exploit Kit”
“Angler Exploit Kit”
“HiMan Exploit Kit”
“Magnitude Exploit Kit”
LightsOut Exploit Kit
“Goon Exploit Kit”

Special thanks to Kafeine for his feedback and numerous contributions!

wildwildwest_1213

]]>
http://www.kahusecurity.com/2013/wild-wild-west-122013/feed/ 0
Deobfuscating Magnitude Exploit Kit http://www.kahusecurity.com/2013/deobfuscating-magnitude-exploit-kit/ http://www.kahusecurity.com/2013/deobfuscating-magnitude-exploit-kit/#comments Mon, 11 Nov 2013 23:48:53 +0000 http://www.kahusecurity.com/?p=12909 Continue reading ]]> Per a couple of reader’s request, I’ll be covering how to deobfuscate Magnitude using the latest version of Converter. For those of you who don’t already know the history of Magnitude EK, you can catch up by checking out the following articles from two fine security researchers:

Magnitude EK : Pop Pop
Official PHP Website Hacked, Spreads Malware Infection

From a source of mine, here’s what the panel looks like and a suggestion that a better name for this kit should be “Death Touch EK”. How appropriate for unpatched computers!

2013-11-11_01

The exploits used by Magnitude/Death Touch EK are:

CVE-2013-2551 (IE VML)
CVE-2012-0507 (Java Atomic)
CVE-2013-2471 (Java Raster)
CVE-2011-3402 (EOT86/EOT64)

Here’s the latest iteration of the Magnitude EK landing page which has changed since a few weeks ago:

2013-11-11_02

The script splits the values using the “%” character and converts the decimal values to text before xor’ing it. You can simply write out the value of the variable “awt”. This is what you should do if you’re using Revelo:

2013-11-11_03

This is the result. As you can see, several exploits are thrown at the computer.

2013-11-11_04

Eventually, the computer will be infected with ransomware if any of the exploits were successful.

2013-11-11_05

Let’s focus on the Java applet which has very little coverage on VirusTotal.

MD5: 31526a1411a85a3e8b9e7a614b4ba065
VT: 1 / 47

2013-11-11_06

What you see above is the main string deobfuscator routine which is deXOR’ing with the value of 0×14. Strings from the “v.class” file look like this and are sent to the routine to be deobfuscated.

public static String jgrw = wiutc.n(“~ubu:uc`:}yusq:Pu`uVarrqf”);
public static String hdhkww = wiutc.n(“~ubu:uc`:}yusq:Pu`uVarrqfVm`q”);
public static String xrkzfj = wiutc.n(“~ubu:uc`:D{}z`”);
public static String rqp = wiutc.n(“~ubu:uc`:}yusq:Fug`qf”);
public static String mcitjzb = wiutc.n(“~ubu:uc`:Uxd|uW{yd{g}`q”);
public static String w = wiutc.n(“~ubu:uc`:}yusq:Yax`}D}lqxDuwqpGuydxqY{pqx”);
public static String dwnmvoh = wiutc.n(“~ubu:gqwaf}`m:Df{`qw`}{zP{yu}z”);

You can use Converter’s Key Search/Convert feature and paste in the string, set the values as you see in red and you can get the plain text value when you click on the “Convert” button at the bottom. Looks like this applet is exploiting CVE-2013-2471.

2013-11-11_07

In the same “v.class” file is a large blob of weird-looking characters. The variable is passed to two functions. The first is the same routine as the above. The second function converts the result from base64 to binary.

2013-11-11_08

To deobfuscate this blob of text, paste it into Converter then choose Format > Mixed Octal to Hex. You will get a bunch of hex code back.

2013-11-11_09

Click on “Copy Output to Input” to get the hex code to the top. Then click on Key Search/Convert and choose the following options. Make sure you choose the “hex” input this time. What you should get is Base64 characters.

2013-11-11_10

Copy the result back to Converter’s main screen then click on the “Base64 to Hex” button. The “CAFEBABE” string is the magic for Java class files.

2013-11-11_11

Click on the “Copy Output to Input” then click on File > Export Binary File and write it out to a file called “file.class”.

2013-11-11_12

Now you can open the file up with JD-GUI or whatever you use. You can see that it will try to disable the SecurityManager and another function converts the payload using XOR 0×29.

2013-11-11_13

Last month the applet was using a different method to obfuscate its strings. I’m not sure why they changed it since it was more sophisticated. Let’s have a look at that one.

MD5: 31526a1411a85a3e8b9e7a614b4ba065
VT: 4 / 47

2013-11-11_14

The above routine deobfuscated the following strings:

public static String kpwieg = v.mw(“JNKNnNp5n.~NcFnEN5NU!jjF3UT5F”);
public static String omfoucd = v.mw(“JNKNnNp5n#9.t5″);
public static String ndzgu = v.mw(“JNKNnNp5n.~NcFn&NX5F3″);
public static String ugyu = v.mw(“JNKNnNp5n*AS,Nw9~S9X.5F”);
public static String mzjot = v.mw(“JNKNnNp5n.~NcFnw9A93197FA”);
public static String ekc = v.mw(“JNKNnNp5n.~NcFn1!A5.#.$FA#N+/F7uN~SAF197FA”);
public static String nqu = v.mw(“JNKNnANtcni=JF+5″);

The function “mw” would load the first obfuscated character, look it up in a string and find its position number then add 32 to the final decimal result. We can do the same using Converter.

Here’s the deobfuscation key from the “v.class” file. We need to unescape this and keep the result handy.

%I\\vz;0(8WbeD?nlfos:q_<|R4'BYPL`}*UwEh Z>^@d\”1Qi#G&u-CraV{)6MOyH[N=+7Fjc,.J/A~t9Sx3X5!Kp$T2km]g

Now select an obfuscated string (unescape it first if necessary), paste it to Converter, then click on Tools > Secret Decoder Ring. Choose the following options and paste the deobfuscation key so it looks like this:

2013-11-11_15

Click on the “Decode” button and you should get a string of decimal values:

2013-11-11_16

We’re not done yet. Copy the result and go to File > Key Search/Convert. Now choose the following settings and click on the “Convert” button.

2013-11-11_17

This applet also has a large blob of obfuscated text.

2013-11-11_18

You basically have repeat the same steps above but with some additional steps:

  • Paste blob into Converter
  • Convert “Mixed Octal to Hex”, “Hex Format – %”, then “Hex to Text” (cleans it up then converts back to text)
  • Use Secret Decoder Ring
  • Use Key Search/Convert to add 32 to the value

You should then have base64 characters left like so. If you noticed, you will have some colon characters in your result but these are not part of the standard base64 alphabet. Based on the Java code, we need to replace them with the letter “L”.

2013-11-11_19

The final step is to convert this from “Base64 to Hex” and export it to a binary file. If all goes well you will be able to open the binary file as “rwnc.class”. By the way, this file looks the same as the one we got with the current version of Magnitude.

2013-11-11_20

I hope this walk-through was helpful to you!

]]>
http://www.kahusecurity.com/2013/deobfuscating-magnitude-exploit-kit/feed/ 0