Even visiting security-oriented websites can sometimes be risky. If you’ve visited the security blog zerosecurity.org this month and you’re also a user of ESET’s security products, you might have encountered an anti-virus alert such as this one:

The detection names may vary. Different variants of the following “generic families” were detected on the compromised websites on different days:

  • JS/Iframe
  • JS/Kryptik
  • JS/Agent

Allow me to shed some light on what these (statistically very prevalent) detections are about. As the platform identifier (the part before “/”) suggests, they are detections of malicious JavaScript code. JS/Agent is a very broad generic group. JS/Kryptik is applied to malicious JavaScripts containing obfuscation intended to:

  1. avoid detection by continually generating variants which look different but do the same thing and
  2. make analysis more difficult (that is, deobfuscation, debugging or emulation are needed to find out what exactly the code does).

JS/Iframe is the detection name for those kinds of JavaScripts that inject a (usually invisible) IFRAME for the purpose of diverting the user to an arbitrary URL provided by the attacker.

The screenshot below (taken on March 7) shows one of the injected malicious JavaScript on the compromised website:

Here’s the “decoded” code after deobfuscation of the injected JavaScript:

Of course, the functionality and purpose of such IFRAME injections depends on the code behind the URL that it points to, and can be very dynamic. Typically, these techniques are used in drive-by downloads, where a user ends up inadvertently and unknowingly downloading and running malicious code when browsing a (even legitimate) website.

It should be noted, that the administrator of zerosecurity.org responded very promptly after being contacted by us and removed the malicious code from the websites.

Similar compromises can happen to any of us and, as has been documented before, they occasionally do. The most probable explanation for this particular case would be WordPress exploitation, which has been on the rise recently (more reports here and here).

Now, these threats are an HTML thing, so they’re found mostly on compromised websites. But we also see them in HTML emails, such as in this purported flight ticket:

As you can see, this particular fake email will display no content apart from “Loading … Please Wait….”. A similar scenario is also described here, although the issue is somewhat exaggerated in this case. There is actually nothing new about emails that try to infect on opening: script viruses that do that were very common in the late 90s and early in the last decade. There were even examples that tried to exploit a design flaw in Microsoft email clients that sometimes allowed infection even if the message showed in the mailbox pane without being opened. However, email clients have moved on since then, and don't normally exhibit such dangerous behaviour.

Here, it looks as if Eleven misinterpreted a default feature of the Thunderbird mail client, which renders the malicious code in the reading pane but doesn't actually execute it. Because of the way part of the code is rendered, it does look as if the code is actually loading. However, that could only happen if the recipient of the mail is tricked into opening the attachment.

However a similar scenario could potentially lead to execution of malicious code from an email if the victim’s email client were to execute the JavaScript code, perhaps because of a different vulnerability.

As a final note, detections such as those listed above (along with others with names like HTML/ScrInject, which also signifies the detection of HTML pages containing a malicious script injection) are in the top rankings of most prevalent malware detections, as indicated by our ESET Live Grid statistical system. This strongly suggests that drive-by-downloads are currently the number one malware distribution vector. For more information on the most prevalent threats, see our Global Threat Report for January and February.

Kudos to my colleqgue Peter Stancík for pointing out the zerosecurity.org infection.

Robert Lipovsky
ESET Malware Researcher

David Harley CITP FBCS CISSP
ESET Senior Research Fellow