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:

iframe sample

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 and 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!!

Scan your website for free:
About Peter Gramantik

Peter has been working in Information Security over 10 years. He previously worked as a Virus Analysis Specialist for AVG and now holds the Sucuri flag as a Senior Malware Researcher on the SucuriLabs team. When he’s not on the clock, you can find him singing and playing guitar or ukulele in one of his bands, fishing, riding his Harley Davidson Sportster, or researching malware on his own. Follow him on Twitter at @petergramantik.

  • blog.sucuri

    Did you forget your own debug code in there?
    var oText = document.getElementById(“output”);

  • netsi1964

    Will search engines index contents generated using javascript?

    • Wolf Software

      The main ones like Google etc can process javascript so it will be very interesting to see if this can be used to push malware directly into the search results themselves.

  • Jim Walker

    A worthwhile investigation.
    “You’ve done a man’s job, sir. I guess you’re through, huh?”

  • Alex Fortune

    This is actually not really big thing. Encoding algorithm is really simple and nothing you could saw on the internet before, and also nowhere as complicated as some obfuscations I have seen while reverse engineering various malware in JS.

    Nevertheless, I did enjoy the article :) Thanks!

    • Wolf Software

      I agree, but what it does do is open a new set of attack vectors that most people haven’t considered before. Some of the JS I have pulled apart over the years has been a lot of hard work as I am sure you understand, but at least I wasn’t having to decode images to get to the JS in order to decode that as well.

  • Wolf Software

    That is very nice and very sneaky. I do a lot of work in and around software security and that is a new one on me. Well done on catching and decoding that and it opens up a whole host of other things to consider now.

  • Nick Knowles

    Hashes or it didn’t happen…. Rookie mistake…

  • A

    It isn’t metadata that’s being read. The function takes the actual image data of each pixel, and then takes the (color? transparency?) code of it, then converts it to a character with String.fromCharCode.

  • Tim

    Do you play Dota2? “Stay frosty my friends!!”

  • RdeWilde

    I dont get where the string in the png actually gets evaluated? Its seems to stay a string of javascript thatll just popup in the alert to me?

  • Djfe

    Created a bug report on bugzilla to convince Mozilla of using something like the popup block method/click to play (plugins) to prevent javascript from creating iFrames without the users permission as this is used more and more to push exploits/drive-by downloads unnoticed to the user

  • Autoankauf start

    Vielen Dank!

  • Bill

    Interesting article, but apparently not a new technique. On a side note, as this post is seemingly related to a commercial enterprise, and is definitely code related, I would have thought that more effort would have been paid to the grammar and syntax of the article too. “For all intents and PURPOSED”? That’s pretty funny, but it’s also sad that literacy is becoming so unimportant, including in the comments.