Kahu Security http://www.kahusecurity.com Sat, 13 Sep 2014 05:48:30 +0000 en-US hourly 1 http://wordpress.org/?v=4.0 Detecting Phishing Sites in Your Logs http://www.kahusecurity.com/2014/detecting-phishing-sites-in-your-logs/ http://www.kahusecurity.com/2014/detecting-phishing-sites-in-your-logs/#comments Sat, 13 Sep 2014 05:48:30 +0000 http://www.kahusecurity.com/?p=13175 Continue reading ]]> I recently read the Anti-Phishing Working Group’s 2Q 2014 report and saw the number of unique phishing sites. I then compared the numbers with the previous year.


After more than 10 years of phishing it’s still around, and growing! Back then, there were companies offering clients a way to detect phishing attacks by analyzing their own web server logs. I wrote my own program in 2006 and decided to update it and offer it up as freeware in case anyone needs a tool like this (I wrote a Python script that does the same thing which I’ll probably push onto Github one day).

The idea behind this and other similar tools is to analyze referers in your web server logs. These referers are generated when a user visits a phishing page and submits the form. Upon receiving the user’s credentials, the phishing page will often redirect the user to the legitimate website. The referer will contain the URL of the phishing site.

In other phishes, the contents of the phishing page are composed of images, stylesheets, and Javascript from the legitimate site in order to make it look exactly like the original to fool unsuspecting users. Again, we can find out the URL of the phishing page by looking at the referers it generates.

Keep in mind that if the phishing website is self-contained (that is, does not need any files from the legitimate site) and does not redirect the user back to the legitimate site then there would be no trace in the web server logs.

Let’s take a look at a typical phish. Here I went to PhishTank.com and try to find a phishing site that’s still up:


Here’s what the site looks like:


When I proceeded through the pages where it asks for more and more personal and financial information, I eventually get to the last page:


Clicking on the Continue button takes me to the main Paypal site (it’s the Danish version for some reason):


I captured the source code of last phishing page and it looks like this. Notice that it contains links back to the real Paypal site. I’ve highlighted the link to the main logo graphic.


If we were to look at Paypal’s web server logs, it might look something like this (note the last line). There’s a GET request to the logo graphic and the referer is the URL of last phishing page that called the graphic up.


If we could find these entries in our log files, we’d find these phishing sites and get them taken down. And we don’t need to rely on users telling us about it. There’s also an added bonus. Sometimes phishers will test their creation first and their referers show up in the logs and we can take down those phishing sites before their phishing campaign can even begin!

Here’s where the program, Sounder aka FishFinder, comes in:


The top portion is where you define folders and filenames. You also need to define the column that contains the referer information (be sure your logs contain referer information or this program won’t work!) and line separator. There’s debug modes to help you.

You can have it check the Contents of the potential phishing site by scanning for content keywords as defined below. For example, if you enter login, password, email, and username that you see there, the program will check if the website has any of those keywords and tell you if there’s a match on the results file.

The Check Filename option will check if the referer contains any of the blacklisted items. The blacklist textbox should contain filenames of known bad referers. In the case of Paypal, it might be something like “paypal.com.html” or “logon.php”. The whitelist textbox would be URLs that you would want to ignore like partner websites, spiders, portals, etc.

If the Capture Screen option is set, the program will screenshot the page for visual inspection. This feature requires PhantomJS. I’ve included the required “rasterize.js” file in my download so you just need to copy the PhantomJS executable into the folder.

Finally, the Server File (Referers) textbox should contain the paths to files on your web server that is often used on phishing pages. Here, I’ve included the path to the logo file.

You can save (and load) the settings by clicking on the appropriate buttons on the bottom. The program uses an INI file which contains helpful descriptions and worth looking at before you use the program.


When Sounder is run, it will scan the files in the Logs folder and look for any HTTP request matching the items in the “Server Files (Referers)” textbox then inspect the referer. If the referer is known bad then it will automatically flag it. If the referer is on the whitelist, it will ignore it. If the referer is neither good nor bad then it will flag it as suspicious so you can have a chance to inspect it. You should then add the referer to either the white or black list as appropriate for future runs.

If the referer is marked suspicious then it will (optionally) visit the page and check if the webpage contents contain any of the items in the “Content Keywords” textbox and grab the screen, regardless of whether there were any keyword matches.


Here’s the results file that shows that this particular referer was suspicious and the keyword “login” was found on the webpage.


This is the screenshot that PhantomJS captured.


I hope you find this program useful!

http://www.kahusecurity.com/2014/detecting-phishing-sites-in-your-logs/feed/ 0
A Quick Peek at Network Injection http://www.kahusecurity.com/2014/a-quick-peek-at-network-injection/ http://www.kahusecurity.com/2014/a-quick-peek-at-network-injection/#comments Thu, 21 Aug 2014 03:15:05 +0000 http://www.kahusecurity.com/?p=13160 Continue reading ]]> Like many of you, I’ve been looking at the various NSA document leaks to see what kind of tools and techniques are being used. I suppose these releases will give cybercriminals new ideas and we will see some of these put to nefarious use sooner than later.

This particular article was very interesting, especially the concept of network injectors. I’ve heard about EvilGrade but never played with it. It seems as though QUANTUMINSERT and FinFly ISP do something similar.

I wondered how I could use this for a pentest. Getting inline with my target would be the first challenge. There are several tools I could use to route wired and wireless network traffic to my computer but maybe an easier way is to setup a proxy server then push out a proxy.pac file.

Here’s a website with a link to a setup file for Revelo.


When the user downloads the program, I can see their GET request and response. At this point the program gets downloaded. Here we see excerpts from Paros.


The way QUANTUMINSERT is described to work, the download request gets silently redirected to another server where an implant gets downloaded. And according to the FinFisher documentation, there is a method called “INJECT-EXE” which “infects the downloaded EXE file in real time. The agent is installed when the target runs the EXE file.”

There’s not too much details so I can only infer how this is being done. Maybe they would have pre-downloaded popular programs, binded it with a backdoor, then sent the file over via a forged HTTP redirect. This would allow the user to install the real program with real certificates but have their program run too.

But how could you do this in real-time, with any download? If I can write a program that intercepts the GET request to any EXE program, bind it with a backdoor in real-time, update the Content-Length field in the response header, and send the file along…it *should* work. ;)

After some coding, I came up with “Interjector” – Interceptor and Injector (because of the nature of this program I won’t be making this available, sorry). There’s not much to look at I know.


With Interjector off, when I download the file, it looks like this:


However, when Interjector is running, the same download dialog box now looks like this (note the file size):


What’s happening behind the scenes is that there is a specially-crafted EXE file that’s been added to Interjector as a resource. When the program sees a GET request to any EXE file, it loads the resource to a variable and gets ready. When the program sees the response, it reads in the Content-Length value, adds the length of the resource to it, and puts the updated value back into the header. Finally, it injects the variable containing the resource into the download stream.

The advantage of doing it this way is that I don’t need to redirect users to another server, I can intercept/inject any EXE file the user downloads, it’s very stealthy, and all of this happens in real time.

Here’s what it looks like when the downloaded file is executed:


Ugh, the icon makes it look fake but I can fix that. This is going to be a challenge for those programs with unique icons. The best way is probably to use a generic icon like this and hope users don’t notice.


What about the MD5/SHA hash? That’s the biggest hurdle to overcome. I could change the hash on the webpage to match the final file but only for the ones I know about by doing a global search and replace. Or I can search for any hash line and remove it from the webpage.


What if it’s a compressed file download (e.g. ZIP)? I think I would have to rezip the file with a new EXE or rebuild the download which changes the ZIP file to an EXE. The real-time requirement makes this difficult to handle without the user taking notice.

So what’s a user to do?
– Use HTTPS to download programs
– Choose to download a compressed version (e.g. ZIP) instead of a bare EXE/MSI file
– Pay attention to any anomalies and inconsistencies; when in doubt, stop
– Verify the program’s hash before installing (for the paranoid, use an out-of-band device like your phone to view the hash on the webpage)

http://www.kahusecurity.com/2014/a-quick-peek-at-network-injection/feed/ 0
Wild Wild West – 07/2014 http://www.kahusecurity.com/2014/wild-wild-west-072014/ http://www.kahusecurity.com/2014/wild-wild-west-072014/#comments Fri, 25 Jul 2014 19:15:55 +0000 http://www.kahusecurity.com/?p=13149 Added the following packs:

RIG Exploit Kit
Niteris aka “CottonCastle”

Special thanks to Kafeine for his valuable input.


http://www.kahusecurity.com/2014/wild-wild-west-072014/feed/ 0
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:


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


Let’s reverse this script dynamically and then statically.

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


And take a peek at what’s going on.


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


Here’s the resulting file:


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


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.


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.


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


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.


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


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


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.


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:


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.


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


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.


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


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:


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:


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.


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.


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


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.


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


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


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.


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.


The decompiled version looks like this:


Here we see the exploit code:


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


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


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


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.


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


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


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


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.


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.


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


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


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.


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.


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:

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


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.


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


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.


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:


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


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


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


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


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


So this is what’s going on…


Here’s a series of packets showing this:


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:

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


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:


And it looks like this:


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


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:


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.


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


While going through the script, this pops up:


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


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


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


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.


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.


Here’s what the real banking site looks like:


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.


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:


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.


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


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:


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.


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


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.


Here’s another example…

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


Here’s the screenshot of the site:


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


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


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.


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


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


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


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.



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.


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.


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.


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. :)


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:


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:


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


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 0x80 in this case. Search for “M”. We get the result 0xCD which is the first value in the XOR key.


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

0xCD 0x43 0x08 0x9E 0x77 0xA6 0x30 0xFD

Let’s test it out…it works!


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.


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.


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:


I run the program on each of the files:


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


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

<div style=”width:expression(document.location(“http://www.google.com”))”>hello</div>

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

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.


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.


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


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.


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.


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.


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


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.


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


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


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


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.


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.


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.


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


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.


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.


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


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:


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):


Here are some other examples:


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


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.


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.


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.


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.


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


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.


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


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


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.


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


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.


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


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)


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:


There was a reference to an external Javascript file:


The file is obfuscated Javascript which is a red flag:


I found the malicious redirect, or so I thought…


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


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

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


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


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.


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:


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


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.


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


The PHP script defines the values of the status code:


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.

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


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


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


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


It turns out that this was the first appearance of the updated version of RedKit. Then in early December 2013, RedKit v2.0 URLs looked very similar and instead of “cnt.php” it used “post.php”.


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


Near the end of December 2013, the infrastructure and URLs changed once again. Now it’s more efficient and even less compromised hosts are needed. This is what the infrastructure looks like today:


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


And this is the infection chain:


If you’ve been tracking these infections, you’ll notice that the URLs to the exploit landing pages are very inconsistent. Here are several examples:


How are they able to achieve this? The RedKit author(s) are cleverly using the .htaccess rewrite rule so the malicious URLs can be anything they choose. The URLs they have used to date doesn’t have any pattern but the filename will always contain .php, .htm(l), or .asp(x).

If you go to a non-existing file on the compromised website, it will be caught by their script. The script then parses the URI and depending on the results, the appropriate exploits are delivered.

To check if a website has been compromised and part of a RedKit infrastructure, visit a non-existing file with a “.shtml” extension. If the .htaccess and malicious script exists, it will catch the URI and echo it back to you.


RedKit v2.0 Arsenal
RedKit uses one of three Java exploits depending on the version the user has installed. The Java applets have minimal obfuscation. It does have a hidden class file called “NewClass.class”. And as you can see, it builds the URL for the payload using the time (HHmmss) and then appends the string “.mp3”.


In late December, a new exploit, VUPEN’s Internet Explorer Use After Free Vulnerability, was added. The payload URL triggered by this IE exploit doesn’t use the timestamp method. It’s a hard-coded value in the exploit code.


The landing page containing the exploit code has been obfuscated. The script XORs the blob of characters using the value “cdlo” (first red rectangle). At the bottom, the script calls a function called “starter” which passes the payload URL and another XOR key which is then concatenated to a VBScript routine and executed. At the bottom, there’s a link to a malicious Java applet just in case the IE exploit failed.


Here are the exploits used by this version of RedKit:


RedKit Infrastructure
The compromised servers hosting the RedKit script has an .htaccess file which causes all non-existing files to redirect to the “post.php” file. I was able to obtain these files by a helpful website developer.


The post.php file is different depending on the website’s role and can be easily and quickly changed by the author(s). In fact, the author(s) appear to rotate the roles regularly to avoid detection. The PHP script is minimally obfuscated and looks like this:


Redirector Role – Back in November 2013, the compromised websites playing the redirector role checked for the “id” parameter, wrote the IP address to a file called “post.ips”, then redirected the visitor to the next stage. It did check to make sure they were potentially vulnerable Windows machines as you can see here.


Exploiter/Dropper Role – The websites with this role have a different post.php file. The script doesn’t interrogate the visitors’ Referer and UserAgent as thoroughly as in the past. It does check what version of Java they are running then gives them the IE exploit or one of three malicious Java applets.

First, it makes sure the URI contains “.php”, “.htm”, or “.asp” then it writes the IP address to a file. It then does a basic check to make sure the Referer and UserAgent exists and has a long enough value. Then it produces the IE exploit landing page or the following HTML page for the Java applets:


The visitor is then redirected to a non-existent file on the same server but is caught by the .htaccess rewrite rule and sent back to the post.php file. Here, the script checks the Java version and gives the visitor the appropriate JNLP and Java files. The Java URL again leads the visitor back to the post.php file and the applet is delivered. All of the files are stored within the PHP script as base64-encoded strings which are decoded as needed.


A log of visitors is written to a text file on the website which is grabbed by the RedKit author(s) then cleared each time:


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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


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


Finally, the clean file shows the important bits.


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