Tag Archive: exploit

A few days ago, Polonus posted about the relationships between unknown html and xmlrpc.php malware. Recently, Essexboy, Polonus, and I had the opportunity to help out a website owner that was infected by his own site. Check out the avast! topic.

At first, the website appeared ok. However, with a search referral, I was shown a 302 (redirect) in the header.

HTTP/1.1 302 Moved Temporarily
Date: Thu, 28 Feb 2013 19:29:17 GMT
Server: Apache
Location: hXtp://fpert.qpoe.com/
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 20
Connection: close
Content-Type: text/html

Also see: urlQuery Report & Sucuri Results

So then, I wondered, what was the root cause behind the redirect? At first, I thought it was an .htaccess redirect, but later, Polonus discovered that it was an xmlrpc.php redirect.

Always keep your WordPress up-to-date,


Content In Brief

An exploit kit, namely The KaiXin Exploit Kit, was discovered roughly 4 months ago by the malware analyst community. I also posted a decent report of this malware back in August. Since then, KaiXin has made another go for it, introducing Version 1.1, which was blogged today by Eric Romang.

I immediately set out to compare file sizes and detection number on VirusTotal. What I found out was rather shocking. Check out the results of 2 different variants, both shellcode exploits [Note: names are randomly generated, but the size of the files are so similar as to assume they are different variants]:

KaiXin Version 1.0 (cLpl7.html)
[NEW] KaiXin Version 1.1 (JSZlR.html)

KaiXin Version 1.0 (gADSr.html)
[NEW] KaiXin Version 1.1 (WysBRr.html)

The detection rate is lower than before. Why is that?

Keep searching,

PHP: Local File Inclusion Exploit

LFI allows you to include files through a web server; however, specific injections of parameters in the URL string can lead to other files being called, if not used properly. A basic LFI file looks like the following:

   $file = $_GET['file'];

A legit referral would look like this: example.com/index.php?file=services.php. It searches the current directory and does not induce upper directory levels. This is the safe approach and should be a standard that you use.

There is also the malcreant approach: example.com/index.php?file=../../../etc/passwd. What this does is show all the passwords (in hash form) that are found on a nix-running system. The malcreant would then be able to crack these passwords and get file access.

However, PHP includes an amazing function called str_replace(), which takes three arguments: The value to replace, what to replace it with, and what string we’re dealing with. Naturally, we can remove all the ‘up directory’ symbols as follows:

   $file = str_replace('../', '', $_GET['file']);

There is also the option to exclude the request altogether:

if (strpos($file,'../') !== false) {
    echo 'Invalid Request.';

The PHP parser only detects the given utf-8 value, so how about if we use hexadecimal as follows?


The following would avoid our current security plans because hexadecimal is not parsed when it meets the PHP script, but is parsed by the client’s browser.

The best way to avoid this exploit is to not use LFI unless you absolutely have to and it cannot be done any other way,

Updated 51la Malware ~ No Antivirus Detects

Reported on the avast! forums, a site recently got hacked and was redirecting users. Based on the Sucuri and VirusTotal results Pondus gave, I decided to dig a little deeper. I found the following in the HTML return for the hacked site:

Which can be beautified as follows:

Well look at that! Some HTML if the user has scripts disabled. And look at that! An .asp file for an image tag. Suspicious, no?

There is also a script tag for those who do run scripts. I sent the URL to JSunpack.

The unreadable code strikes again.. I have parsed it into readable content:

The following checks for specifics, then generates a cookie based on the returns. Shortly after, the document is fed an invisible image with a go.asp?… At least one antivirus should’ve considered this suspicious..

Ok, but does it work? I sent the URL to urlQuery to confirm just that. Notice on the image preview it says “Connecting to web1.51.la”, which means that the exploit is live and active.

Below are the VirusTotal results, not detected by any antivirus..

Script Getter (As seen in Figure 2) | Script Original (As seen in Figure 3) | Script Beautified (As seen in Figure 4)


Could use the following syntax: Base([a/random-letter][4-random-numbers])Mix([2-random-letters])


Earlier this week, we explored a new way of phishing via URI.

You can display a full, let me state that again, a full working website using data URIs. In this article, I will show you the steps to change a URL to a URI and how (if) exploit kits can take advantage of this feature.

Lets take this simple page that I made. It utilizes an external file, specifically a 3rd party javascript, to determine the value of the loop. Now, we want our URI to not contain any external URLs, so we need to get the source of the javascript file first.

Remember our syntax for data URI:

data:text/<javascript/html>;base64,<data> where <data> is our base64 encoded string.

In this case, we have a javascript file, so naturally we will use data:text/javascript. Lets use our Base64 Converter to obfuscate the content of code.js.

var ran = Math.floor(Math.random()*(10-1+1))+1; becomes


We then enclose the data as follows:

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

Which is simplified to this:


Now all we have to do is put <script> tags around our main javascript and base64 obfuscate it! You should get something like this:


Testing it out, I get this error:

TypeError: document.body is null
Due to the nature of the DOM, we need to first write our document before we can add code to it in javascript. We will use a simple HTML5 declaration.
<html><body></body> (no </html>) becomes

We insert this before the other two snippets.

We then get this:


So, now we are focusing on shrinking our code. We can use the dreaded document.write instead of document.body.innerHTML, thus <body> tags are not required. Our shrunk code looks like this. Our obfuscated URI looks like this:


Give it a try!

With URIs, if the string is very long, looks suspicious, or is rendered improperly (URIs are handled differently than URLs, I have first-hand experience :P), the browser will not load the page properly, or won’t even load the page at all! This makes converting URLs to URIs by hand harder.

So, in simple words, no. I do not think that authors/contributors of exploit kits would spend explicit time converting their already-working kits to URI. However, I feel that new exploit kits might take advantage of this feature so the exploit kit never meets the internet, thus cannot be analyzed in-depth.

Stay safe,