Kahu Security http://www.kahusecurity.com Mon, 07 Apr 2014 05:40:37 +0000 en-US hourly 1 http://wordpress.org/?v=3.9 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
Converted v0.10 Released http://www.kahusecurity.com/2013/converted-v0-10-released/ http://www.kahusecurity.com/2013/converted-v0-10-released/#comments Thu, 07 Nov 2013 03:23:19 +0000 http://www.kahusecurity.com/?p=12888 Continue reading ]]> The latest version of Converter includes changes to the menus and several new features. You can download this version here.

Filter Menu

2013-11-06_01

There’s two new functions added to the menu. The first is “Strip Whitespace” which removes spaces, tabs, CRs, LFs, etc from your input. Thanks to TW for this request.

The second is called the “Position Filter”. With it you can extract characters with a fixed position or after a certain character. Here’s a quick example. There’s some base64 characters in between those junk characters. We can extract what we need using this position filter.
2013-11-06_02

Format Menu

2013-11-06_03

Under this menu, I’ve added a row numbering capability which will insert the row number starting at 0 or 1 at the beginning of each row.

Beautify Generic is an option to quickly beautify your input using a quick and dirty method. The Beautify HTML and Beautify Javascript functions use the latest JSBeautifier.org scripts (full credit to them).

Stats Menu

2013-11-06_04

All I’ve done here is move the MD5 Hash and SHA256 Hash functions to this menu.

Tools Menu

2013-11-06_05

Two new functions have been added which was described in a previous blog post.

Other Improvements and Fixes

Besides the above new functions, there were several enhancements and fixes made. One change has been made to the “Base64 to Text”, “Base64 to Hex”, and “Convert Custom Base64″ functions. It now does a check of the length of the input. If the input string is not divisible by four then the input string has too many characters or is likely missing the padding character(s). Thanks to JW for this request.

Thank you all for your continued support, ideas, and requests!

]]>
http://www.kahusecurity.com/2013/converted-v0-10-released/feed/ 0
PHP Infector http://www.kahusecurity.com/2013/php-infector/ http://www.kahusecurity.com/2013/php-infector/#comments Sun, 13 Oct 2013 02:47:40 +0000 http://www.kahusecurity.com/?p=12880 Continue reading ]]> A reader wanted me to analyze a PHP file that was found on his hacked WordPress site. The script is made up of three parts as you can see.

20131012_01

The top two sections contain an array of Base64-encoded strings. The bottom section references the arrays and performs the main functions.

My first thought was to replace each of the array variables with the actual decoded strings. Then I could read the script at the bottom and figure out what it’s doing. But replacing each of the variable names with the values from the array manually would be a pain! (Anyone got a better idea? If so, let me know.)

Whenever I come across a problem, I try to find a generic solution that I can keep using in the future. Here’s what I came up with…

First I take each of the top two sections and separate the encoded values by rows. So I take this:

20131012_02

And use search/replace to make it look like this:

20131012_03

Then I modified Converter to base64-decode each row separately:

20131012_04

Then I replaced each row with a pipe delimiter (since it wasn’t being used anywhere):

20131012_05

I did the same for the second section:

20131012_06

I wrote a program that does a search and replace of the array values. I entered the search string that corresponded to the top section and pasted in the decoded strings with the pipe delimiter to get the result.

20131012_07

The second section was next.

20131012_08

All done! This script probably won’t execute properly because some of the strings need to be quoted but at least you can get a much better idea of what’s going on.

20131012_09

Basically this downloads a file from a website, gets the URL and visits it. It essentially serves up a drive-by link to unsuspecting visitors.

20131012_10

The iframe link is the landing page of Sweet Orange. The link changes every couple of minutes or so.

I’ll need to think about this more and see if there’s another generic solution. If not, I’ll add this method to Converter in the future.

]]>
http://www.kahusecurity.com/2013/php-infector/feed/ 0
Deobfuscating the CK Exploit Kit http://www.kahusecurity.com/2013/deobfuscating-the-ck-exploit-kit/ http://www.kahusecurity.com/2013/deobfuscating-the-ck-exploit-kit/#comments Mon, 02 Sep 2013 20:54:22 +0000 http://www.kahusecurity.com/?p=12868 Continue reading ]]> The CK Exploit Kit has been around since 2012 and has its roots in the NetBoom Exploiter kit according to security blog site CySecTa. You can read about its history and other information here.

Output from the NB Exploiter doesn’t resemble the scripts found in today’s CK Exploit Kit so we’re probably talking about a completely new tool. However, when you take a closer look, you will find variable names like “nbcode”, “nbChar”, and “nbencode” so there may be some code reuse after all.

2013-09-02_01

Finding a live instance of the CK Exploit Kit these days is a somewhat of a challenge. The drive-by download appears for less than a day then the files are removed from the server. This exploit kit tends to show up on Chinese and Korean sites.

The CK Exploit Kit is definitely out of date but since it’s still being used today, I thought I would document it here for my reference. I won’t spend too much time digging into the kit since there’s already several good write-ups including this one from KISA – Korean Internet & Security Agency.

The landing page looks like this (you will notice the text “ck” referenced in variable names in several places). The “top.js” file is a plug-in detector and mainly checks for IE and Java versions.

2013-09-02_02

The Javascript is compressed using a variant of Dean Edwards’ packer. You can barely make out the variables p, a, c, k, e, d in between the comment tags:

2013-09-02_03

The variable “p” holds the deobfuscated value so you just need to replace “return p” with “document.write(‘<textarea>’+p)”:

2013-09-02_04

Since this script checks your cookie to make sure you only run it once, you can remove that part or just clear your browser cookies if you need to visit the page a second time. You should see a textbox containing the uncompressed script.

2013-09-02_05

All I did here was add the “script” tags, copy the function “ckl” from the landing page back to this page, and then separated the blocks of script so I can make better sense of it. If you go through the script, you’ll find that you can deobfuscate the script by modifying the function in the red block which is basically “window[document][write](t)”.

2013-09-02_06

Change the red block text to this: “window[X3cQCMIIF][ErTiUlaxlkP](‘<textarea>’+t)” and execute the script. You will again see a small textbox with your deobfuscated script in it. Here’s the final script with an interesting class name. Apparently someone didn’t have a good day.

2013-09-02_07

Inside one of those applets, the hilarity continues with another funny string:

2013-09-02_08

Near the bottom of the landing page, the script will open one of two HTML files depending on the version of IE used to visit the page.

if(ck_wm.indexOf(“msie 6″)>-1){document.write(“< iframe src=zip.html width=60 height=1>< /iframe>”);}else if(ck_wm.indexOf(“msie 7″)>-1||ck_wm.indexOf(“msie 8″)>-1){document.write(“< iframe src=win.html width=60 height=1>< /iframe>”);}

This zip.html page uses the same obfuscation method as the landing page:

2013-09-02_09

When you deobfuscate the script, it should look something like this. This hosts the CVE-2012-1889 exploit.

2013-09-02_10

The second page, win.html, calls up a Flash file which is protected with DoSWF.

2013-09-02_11

By the way, it contains an interesting string “King Lich V” which may be related to PlugX based on this write-up from Jaime Blasco.

2013-09-02_12

The script references an file “Moview1.html” which I wasn’t able to pull down in time. Presumably this is exploiting CVE-2013-0634. The shellcode is XOR’d using the value 0xE2 which is the same as Jaime’s sample from 2012.

2013-09-02_13

The payload file was downloaded from p.wangwangwangwangwang.com (174.139.88.102):

2013-09-02_14

The payload was a Trojan that checked in at qwe.xzczxcasrafdsfzxcvzv.com:3306 (98.126.71.38).

File: logo.swf (dropper)
MD5: ad760c37c4198449b81b4992a3f2d561
VT: 6 / 45

File: ckwm.jar (CVE-2011-3544)
MD5: 4a562094a9d2771507e50faf08a6ca79
VT: 8 / 46

File: wmck.jar (CVE-2012-4681)
MD5: 5b47778d02048bb081b122cb11367217
VT: 22 / 45

File: p.exe
MD5: b8c0bec6b361c971a09d2b6a93692291
VT: 25 / 46

]]>
http://www.kahusecurity.com/2013/deobfuscating-the-ck-exploit-kit/feed/ 0
Chinese Exploit Pack Updated http://www.kahusecurity.com/2013/chinese-exploit-pack-updated/ http://www.kahusecurity.com/2013/chinese-exploit-pack-updated/#comments Fri, 30 Aug 2013 06:17:54 +0000 http://www.kahusecurity.com/?p=12853 Continue reading ]]> If you been keeping up with Java exploits recently, you’ll know that there’s been several exploit packs being updated with them. Check out Kafeine’s blog for the latest!

It seems that at least one Chinese exploit pack was updated recently as well. The “Gong Da Pack” is now using CVE-2013-2465. At the time of this writing, the pack is being hosted on a Korean website.

Gong Da is still using “Dadong’s JSXX 0.44 VIP” Javascript obfuscator athough the identifying comment string no longer appears (and hasn’t been used for awhile):

2013-08-29_01

After deobfuscating the script, there’s a new entry for Java 6 Update 0 through 45. Interestingly, the exploit for Java 7 Update 0 through 10 has not been replaced or updated.

2013-08-29_02

What makes this notable is that the Java applet is obfuscated which is atypical for Gong Da (bottom). At the top is the original POC (Packet Storm Advisory 2013-0811-1) that was made available on 8/12/2013. You can see similarities throughout the code.

2013-08-29_03

Some of the strings within the applet were obfuscated using a five-byte XOR key. Here’s an obfuscated string from the applet:

\013I\bmg\033Y\016Wv\001a\035Pc\037I\016

After applying the XOR key (120, 44, 124, 62, 2), the decoded string appears:

setSecurityManager

While not unexpected, the use of Java obfuscation by Chinese packs is new. We’ll have to see if this is a new procedure or a one-off.

By the way, the payload was a Trojan that checked into a website at ftukl.com:6677.

File: gehYl3.jar
Size: 8K
MD5: 349423e93f5bc75d40f11ed23e7fa1e2
VT: 3 / 46

File: js.exe
Size: 99.2K
MD5: fbc68bc19fda902ccb51231278af4add
VT: 27 / 45

]]>
http://www.kahusecurity.com/2013/chinese-exploit-pack-updated/feed/ 0