New iFrame Injections Leverage PNG Image Metadata

We’re always trying to stay ahead of the latest trends, and today we caught a very interesting one that we have either been missing, or it’s new. We’ll just say it’s new..

We’re all familiar with the idea of iFrame Injections, right?

Understanding an iFrame Injection

The iFrame HTML tag is very standard today, it’s an easy way to embed content from another site into your own. It’s supported by almost all browsers and employed by millions of websites today, use Adsense? Then you have an iFrame embedded within your site too.

Pretty nifty, I know. Like with most things though, the good is always accompanied with the bad.

In today’s attacks, especially when we’re talking about drive-by-downloads, leveraging the iFrame tag is often the preferred method. It’s simple and easy, and with a few attribute modifications, the attacker is able to embed code from another site, often compromised, and load something via the client’s browser without them knowing (i.e., silently).

It would look something like this:

Attackers normally embed a malicious file from another site, often in the form of a PHP file or something similar. This of course is not the only method, but the most prevalent. From a detection and remediation standpoint, these are often fairly straight forward to fix.

New iFrame Injection Method

Today however we found an interesting type of iFrame injection.

The uniqueness is not in the use of an iFrame tag to embed the content, but rather in how it distributes the malware. You see, the attacker obfuscated the payload inside a PNG file.

I can almost hear the lot of you snickering, pff.. this isn’t new…. but it’s all in the details my friends.

You see, the iFrame was loading a valid file, nothing malicious, it was a JavaScript file, jquery.js. For all intents and purposed, the file was good. Here, look for yourself:

At first, like many of you, we were stumped. I mean the code is good, no major issues, right? Then we noticed this little function, loadFile(). The function itself wasn’t curious, but the fact that it was loading a PNG was – var strFile = ‘./dron.png. You’d be surprised how long of staring it takes to notice something like that, I know hindsight is a real kicker.

Naturally our next step was to open that curious dron.png file. I mean, what could go wrong?

Well, absolutely nothing, it’s perhaps the most boring thing I have ever seen, lovely. What a waste of time…

But wait, we then noticed this interesting little loop:

Well that’s surely curious, it has a decoding loop. Why would it need a decoding loop for a PNG file?

Like any good researcher, I went about it the easy way, why worry about breaking down an image when I can just load the image on a test page and take the content. For the win!!

After loading it on a test page this is what we were able to pull from the strData variable:

Do you see what it is doing?

It’s taking the normal behavior of an iFrame injection, embedding it within the meta of the PNG file and just like that we have a new distribution mechanism.

A couple of areas to pay special attention too. You see where they use the createElement to use an iFrame, then you should see where they place the iFrame out of view to the naked eye via their elm.style.position.left and elm.style.position.top elements by placing it at -1000px. That’s right, you can’t see a negative placement in your browser, everything is positive. But you know who can? That’s right, the browser itself sees it and so does Google, nice little technique both for drive-by-download and Search Engine Poisoning (SEP) attacks.

Lastly of course we have the payload, which can found on that domain set in the elm.src element.

Why is this Unique and what is the benefit?

This is unique because in the level of effort being taken to obfuscate the payload. Most scanners today will not decode the meta in the image, they would stop at the JavaScript that is being loaded, but they won’t follow the cookie trail. This also talks to the benefit, at least for attackers, it’s exceptionally difficult to detect.

Do make note however that while in this specific case we’re talking about PNG, the concepts do and can apply to other image file types as well. This only puts more emphasis on the importance of being aware of the state of your web server, understanding what files are and aren’t being added and modified and ensuring that vulnerabilities are not being exploited.

As is often the case, some creative sleuthing and troubleshooting allowed us to spend the time required to find this lovely little gem. Do we detect it now via our Website Malware Scanner? Absolutely!!!

Stay frosty my friends!!