Tag Archive: malware

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,

More xmlrpc.php malware

Recently, there has been a number of cases involving mxlrpc.php. It appears that these xmlrpc ‘exploits’ are caused by outdated versions of WordPress. Consider reading this RSI Diary post. Although it dates back to 2005, my friend Polonus is finding occurrences of this exploit in 2013.

Read more on the avast! forums,

I was looking at some images on Google and was looking at this particular site when I noticed that there was a unusual url request. I did some investigations and found out that the URL request was a malicious hXXp://hzebw.portrelay.com/jentrate.php

Please note that when I tried using automated analysis on the site, using the same referrers and different scanners, the return didn’t include a jentrate.php. You may also want to see the urlQuery results. Maybe there is a time limit between intervals? Or maybe it’s because I’m using a newer version of Firefox?

Basically, like any exploit, cursor starts flashing and a PDF file is automatically downloaded without user verification. You can only guess what happens next: The downloaded file is immediately ran. I didn’t want to fiddle with the outcome of running this PDF and terminated it upon execution, but if you want to check it out, the VirusTotal results and the download link are below.

Download the PDF (Password: infected): http://db.tt/GAcOjZhx
VirusTotal (6/45) as of 2013-01-24 01:32:17 UTC

Moving along, let’s look for more information about the jentrate.php. A search on Google reveals that this jentrate.php can be traced back to January 15th and 16th of 2013, so this is very new. Jsunpack results show us a somewhat familiar buffer overflow script. We also have analysis on Minotaur and a similar threat on urlQuery. Interesting, no?

Finally, I sent the malicious URL I encountered to urlQuery and was greeted with what I expected. A search on CleanMX reveals many entries for this site. Apparently the domain is also associated with a “jokevity.jar”. Have a look at the Wepawet scan.

For those who wish to dig deeper into subject, I strongly encourage you,

Have you ever seen something like this before?

if(var1==var2) { document.location=”[Insert URL Here]“; }

I have, and today I finally decided to dig a little deeper. In this article we will cover URLs that are used with this redirecting method, other malicious JavaScript files that have adapted to this method, and test this method with various techniques against the AV industry.

Here is the complete list of the URLs I found that are used as the document.location:

hXtp://куда редиректить.ru
hXtp://имя домена.ru

I also found something else rather interesting. There is an “o.js” that uses this method in a more advanced way. Have a look at these two Wepawet results here and here. Notice how they use additional variables whilst using the same concept.

So, let’s make our own redirecting JavaScript! The Wepawet examples are from 2009, so this should have good detection, right?  We will conduct various test to ensure that our results are not flawed. Have a quick look at the list:

  1. The Default Approach
  2. Different Variable Names
  3. Additional Variables
  4. Number Obfuscation
  5. String Obfuscation

Before we move on, for those who would like to do this with me, make sure you have your favorite editor open. I myself use Sublime Text. You can download the samples we will be using from my domain here.


The Default Approach – VirusTotal (5/46)

Conditional Redirect Test 1

Well now.. I didn’t expect that myself. Maybe 8-14/46 but 5/46? More so they show the same threat name? I’m speechless considering this was the first test..


Different Variable Names – VirusTotal (5/46)

Conditional Redirect Test 2

Ok, so everybody can still detect it. That’s a good thing. How about when we add additional variables?


Additional Variables – VirusTotal (0/46)

Conditional Redirect Test 3

And just like that, nobody detects. Seriously, WTF? This kind of simple variable trick passes? In my opinion, more should’ve detected it then the first time, considering it explicitly passes “document” into another variable to be called with with window.


Number Obfuscation – VirusTotal (0/46)

Conditional Redirect Test 4

None detect this simple obfuscation method? No, just no… The document.location was left in place and obfuscation was added. I expected more to detect this..


String Obfuscation – VirusTotal (0/46)

Conditional Redirect Test 5

Err… how does this miss? ._.


We can conclude that the AV industry uses a simple method for checking this kind of exploit. It would look something like this:

When a variable (Var A) is defined,
And another variable (Var B) is set to Var A,
With a conditional between each (Var A and Var B),
And an expression utilizing document.location,
That contains a string (not a variable) with a passed URL,
Then alert and mark as malicious.

Follow the discussion on the avast! forums,


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,