What about it?

This site was designed to provide helpful information to various malware analysts. If you would like to start website analyzing, or this is your first time here, please check out these excellent tutorials. Thanks, and good hunting!

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:

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:

The Default Approach

Different Variable Names

Additional Variables

Number Obfuscation

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.

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.

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.

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

As you can see, no obfuscation. They aren’t trying to hide anything. Maybe they are trying to reduce general AV detection. And the script looks simple enough, with a redirect to this podarunoki(dot)ru site…

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.