Archive for September, 2012

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”, 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])


The VaNcZwAmM Variant

This interesting topic on the avast forums I just had to examine. Check out the Sucuri results; I’ve never seen that before! =O

I sent the URL to Quttera. Check out the results. Ok, lets pick one of the URLs. I picked GET /forum/forumdisplay.php?fid=124. Look what I found just below the ending HTML tag:

We can beautify the following code as follows:

By looking at the first line, we can instantly see v%@a~@@#r, and because we see a function with the string.replace() containing a regular expression, we can determine that symbols such as above will be omitted in the return. If you look at the code on lines 29 and 30, you can make out .appendChild(o). This is the fully deobfuscated content:

Of course you want to see the VirusTotal results ;)

Original (As seen in Figure 2) | Deobfuscated (As seen in Figure 3)

Notice that each scan gives different antivirus findings. The original obfuscated content being detected by Avast! (JS:Iframe-EQ [Trj]) and Kaspersky (HEUR:Trojan-Downloader.Script.Generic), while the deobfuscated content being detected by Commtouch (JS/IFrame.GN.gen), F-Prot (JS/IFrame.GN.gen), and K7AntiVirus (Riskware). A fail for the antivirus community, I must say.


Since the most used variable is VaNcZwAmM, I will call this the VaNcZwAmM variant,

Today, there were numerous topics related to this relatively new hotspot on the avast! forum. I will give a few:

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] ..

This is what I got from essexboy:


It is a good thing avast! blocks the url, n’est-ce pas?

What do you think?


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,

A smart man named Henning Klevjer recently discovered a new phishing technique. In which all sites can be hidden in a single link.

Before, phishing was contained on servers on the internet. Utilizing URIs, you do not need a server to make a phish site.

In this article, we will examine the method in which URI is received, implantation, sharing, and how antiviruses must react. This article is divided into 8 parts.


Part 1: Understanding The URI

Using the data URI scheme it is possible to present media content in a web browser without hosting the actual data on the internet. Data URIs follow this scheme: data:[<mediatype>][;base64],<data> [1]

So the general syntax would be data:[<metatype>][;base64],<data>

The mediatype is a MIME type string, such as “image/jpeg” for a JPEG image file. If omitted, defaults to text/plain;charset=US-ASCII

If the data is textual, you can simply embed the text (using the appropriate entities or escapes based on the enclosing document’s type). Otherwise, you can specify base64 to embed base64-encoded binary data. [3]

Ok, we want text/html or text/javascript. And the other part is base64. So our code so far looks like this:

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


Part 2: Generating The Phish Page

This is when you would, like any other regular phish page, attempt to replicate as much of the website itself as possible without having to use a high amount of scripts. This can be done via using external stylesheets. For this test, we will use a basic javascript function.



Part 3: Obfuscation Using Base64

Next, we will use a tool called Base64 Online [4] to obfuscate our code.



Part 4: Implantation In The Browser

So now, the full code is:


Enter that in your browser and give it a try! You should be greeted with an alert box.


Part 5: Implantation On A Website

So now what we do is take our code and put it in a hidden iframe:

<iframe src=”data:text/html;base64,PGh0bWw+PGhlYWQ+PHNjcmlwdD5hbGVydCgndGVzdCcpPC9zY3JpcHQ+PC9oZWFkPjwvaHRtbD4=” width=0 height=0>​​​​​​​​​​​​

Check out the jsFiddle [5].


Part 6: Sharing The Payload

Generally, it’s easier to make your own link than to infect other sites, so how do we share a long url without making it look suspicious? Why TinyURL [6] of course!

TinyURL handles our code! [6]

Note that Google Chrome has a built-in feature that detects redirects such as this and prevents connection. However, if the user attempts to reload the page, the error doesn’t occur a second time. Note that this safety feature does not work with previous examples.


Part 7: How Antiviruses Must React (Conclusion)

Due to the nature that these links are not really ‘sites’, they don’t have IPs, which means you can’t blacklist them. This means that website heuristics is a must, and any suspicious elements found must be reported accordingly. Lets develop a ‘rough-draft’ of how we want to protect our users. I will use a mix of Lua and JavaScript as well as english.

If document.contains “data” then

If typeof data is script then

— Deobfuscate Base64 & Signature Check, if fails:

— Heuristics, if fails:

— Sandbox




Part 8: Resources [1] [2] [3] [4] [5] [6]


Stay Safe,