PNG Image Metadata Leading to iFrame Injections

Researchers have discovered a relatively new way to distribute malware that relies on reading malicious obfuscated JavaScript code stored in a PNG file’s metadata to trigger iFrame injections.

Researchers have discovered a relatively new way to distribute malware that relies on reading  JavaScript code stored in an obfuscated PNG file’s metadata to trigger iFrame injections.

The technique makes it highly unlikely a virus scanner would catch it because the injection method is so deeply engrained in the image’s metadata.

Peter Gramantik, a malware researcher at Sucuri, described his findings in a blog post Monday.

This particular iFrame calls upon a simple JavaScript file, jquery.js (below) that loads a PNG file, dron.png. Gramantik notes that while there was nothing overly odd with the file – it was a basic image file – what did catch him off guard was stumbling upon a decoding loop in the JavaScript. It’s in this code, in this case the strData variable, that he found the meat and potatoes of the attack.

The iFrame calls upon the image’s metadata to do its dirty work, placing it outside of the browser’s normal viewing area, off the screen entirely, -1000px, according to Gramantik. While users can’t see the iFrame, “the browser itself sees it and so does Google,” something that if exploited could potentially lead to either a drive-by download attack or a search engine poisoning attack.


The payload can be seen in the elm.src part (above) of the data: A suspicious-looking, Russian website that according to a Google Safe Browsing advisory is hosting two Trojans and has infected 1,000-plus domains over the last 90 days.

The strategy isn’t exactly new; Mario Heiderich, a researcher and pen tester at the German firm Cure 53 warned that image binaries in Javascript could be used to hide malicious payloads in his “JavaScript from Hell” con talk back in 2009.

Similarly, Saumil Shah, the CEO at Net-Square described how to embed exploits in grayscale images by inserting code into pixel data in his talk, “Deadly Pixels” at NoSuchCon in Paris last year and at DeepSec in Vienna the year before that.

Still though, it appears Gramantik’s research might be the most thought out example of the exploit to date using this kind of attack vector.

Regardless of how new or old the concept is, Gramantik stresses that it could still be refined and extended to other image files. Because of that the researcher recommends that going forward, IT administrators better understand what files are and aren’t being added and modified on their server.

“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,” Gramantik warns in the blog.

Steganography, the science of hiding messages, oftentimes by concealing them in image and media files has been used in several high profile attacks in the past. The actors behind the MiniDuke campaign in 2013 used it to hide custom backdoor code while Shady Rat was found encoding encrypted HTML commands into images to obscure their activity in 2011 .

Suggested articles


  • amirbudicecep on

    Except it's not relatively new: Also, see this: And I wonder where the "injection" is.. the entire code is ran from the attacker's page. If the objective is to obfuscate the code, and the attacker already controls the code, he can put whatever techniques, obfuscated or not, in that loadFile() function. So, yeah, not exactly a new PNG script packer, and a dubious claim of "injection" here.
    • bob on

      pretty can response me thinks...
    • puevigi on

      It appears you only read the first half of the article? "The strategy isn’t exactly new; Mario Heiderich, a researcher and pen tester at the German firm Cure 53 warned that image binaries in Javascript could be used to hide malicious payloads in his “JavaScript from Hell” con talk back in 2009." That gives us a better understanding of the author's "x" for relative here. The article itself is about the exploit being refined to allow for detection avoidance under current scanning methods.
    • ZZooooooLL on

      i agree with amir. steganography is not new by any stretch of the imagination. i was taught about it in college 3 years ago. I am also in agreement about the sceptical claims of "injection".
    • Anonymous on

      I assumed the attack vector was some compromised png file, like artwork for a game. In that case it would inject the iframe for anyone who happens to play it.
  • MrCR on

    Unless you're injecting this into advertisements you're distributing via an ad network that would otherwise check for malware.
  • felix on

    Typo in the guys name, gramatik is a DJ/artist
  • fed on

    @amirbudicecep - what if you allow users to upload pictures to your site?
  • dacimvrl on

    i have seen and scripted similar things 10 years ago.... this is definitely not new.....
  • darthba11z on

    Only old people run javascript anyway Here's a tip, never install javascript. The only websites I even see using it are shady anyway. Congrats, you've just become immune to 99% of these 'threats'
    • Bungalou on

      Actually, you don't install Javascript. You must be thinking of Java, which is entirely different than Javascript.
  • amn on

    I am always amazed how most security researchers are totally incapable of explaining their findings to a general audience. At least this article doesn't. I am a computer programmer, and I know my way around web technology, as well as pretty much anything down to how machine instructions and CPUs work, but I failed to understand what details this article tried to explain - does the JavaScript code decode PNG? Does it "run" metadata encoded in PNG? What does the iframe do, besides being shown off screen. C'mon, people, it is not that difficult to talk human language - try a point by point description of the problem. Somewhere between raising your head from looking at the keyboard and your laptop screen, you lost that fine ability to FORMULATE YOURSELVES. Neither this trojan nor being able to explain yourself are well, rocket science. The latter is far more important, too.
  • Nick Knowles on

    Hashes or it didn't happen....
  • rpsw on

    Looking at the code listing, is the payload not in fact in the image data, rather than the meta data as said in the article. It seems to be retrieving a character from every red pixel. Metadata would usually imply it was coming from header information of the image, such as EXIF info or in the case PNG maybe the iTXt/tEXt chunks.
  • Ambidex on

    Shouldn't / Couldn't this be something that browser's intercept? I find it a bit troublesome that this kind of code execution is even possible from a image file.
  • Paul Fletcher on

    @amirbudicecep Isn't the point of this, that most anti-virus software wouldn't bother to scan the png file, which then in turn runs another js file? So it's both a new packer and an injection
  • Jeff on

    To summarize without the sky is falling drama: "If you encrypt javascript in your page, you can decrypt that code and execute it." You don't have to worry about PNGs hosted on your site harming your users because of this. If there already is code on your site that tries to pull data from PGNs in a specific way, decode it, and execute it, then you have bigger issues. As for the idea that obfuscation is a good means of avoiding detection of malicious code for antivirus scanners: no kidding. Encoding data in PNGs is nothing new. Using normal encrpytion to encrypt code also works.
  • Henk on

    Je moeder is een dikke koe die afgeslacht moet worden zodat ik wat te eten heb.
  • Jacob on

    This isn't new, this is how you attack a linux computer with a virus.
  • iGadget on

    ...besides it's vanilla.js, not jQuery...
  • Jeff on

    @amn: I'll have to defend the article in that point. You mentioned that the article doesn't explain how to get this data or how it's stored. The article included an easy to read sample method called LoadPNGData that loads a string from a PNG.
  • SoothSayer on

    Heh, doesn't matter how they hide the virus when you run FortHoodAV, it still detects and removes the threat. Even if its "FUD".
  • Brian m on

    Understand how the hidden code can be introduced, but not so sure why this should be a threat as it's held within the web browser/JavaScript environment which in 'theory' is a sandboxed environment? Or is this environment no longer safe due to gratuitous features being added.
    • Brian m on

      Just got it! The image is somehow loaded on to an innocent web site and the injected code messes with the way the site works etc.
  • amirbudicecep on

    I didn't realize this post invited quite a number of comments.. As I happened to do a search on my throwable pseudonym, it's been 5 months but here's my reply to some of the follow up comments: @puevigi (#3) Both this threatpost and the original article mentioned "[relatively] new" and they're written in Feb 2014. Even if he mentioned Heiderich's 2009 talk towards the end of the article, the "new" verbiage was used to frame the technique as something novel.. which is not. Gramantik didn't even seem to bother searching of the code snippet to get the SAME EXACT code from the links I included above. So, nope, I didn't read only the first half of the article. While I appreciate it gives more people better understanding, this is completely not a new technique. To some people may be, but it's not new. @fed (#8) It doesn't matter or it's not relevant. If you allow user to upload *something*, and that something will just be stored somewhere (i.e. not processed), you can upload any contents with any file extension, obfuscated or not. Yes, steganography or image processing is a convenient avenue to be processed by existing/available web library. But that's it: it's a convenience and not a compulsory vector. For example, as an attacker, if you can write/run some code to load external files, you don't need steganography. Just upload a .png with some obfuscated JavaScript/JSON contents and include it in a . It will not be a valid PNG file but you'll avoid "detection" the same way. @amn (#12) loadPNGData() use HTML Canvas library to load (decode) the PNG. The actual script payload is in the byte values of the pixels, see the loop in line 28-31. To run the payload, loadFile() will need to use something like eval(strData) in line 49 instead of merely alert-ing it. @Paul Fletcher (#16) It's not a new packer (see the links from 2008 I included in my first comment, they even generate/are the SAME EXACT code as what the researcher "found"). As for the "injection", I failed to see where the injection happened. If the attacker can upload their own code (talking about the loadFile(), not the PNG itself), it's pretty much game over. If the loadFile() is the attacker's own controlled code, what injection then?

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.