Category: URI Analysis

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,