Conditional Malicious iFrame Targeting WordPress Web Sites

We have an email address, where we receive multiple questions a day about various forms of malware. One of the most common questions happen when our Free Security Scanner, SiteCheck, detects a spam injection or a hidden iframe and the user is unable to locate the infection in the source code. It’s not until we explain what Conditional Malware is that they start to understand it’s implications and more importantly how it works. If you’re unfamiliar, conditional malware is very common these days, as the name implies it’s based on a set number of conditions that determine whether a payload (i.e., the malware) presents itself to the browser. It’s employed because it’s easier to evade scanners and reduces the odds of detection by spreading the impact.

WordPress Websites Targeted in Latest Trend

Since last week we have started to see several WordPress sites with a conditional payload that is being injected at the beginning of all JavaScript files on the website:

Sucurii  - GetCookie iFrame Injection
Sucurii – GetCookie iFrame Injection

The malware is simple, it checks first what the browser version is, and if it is Windows 7 or lower, it displays the iframe. It also excludes Chrome, Xbox, IEMobile or any other browser that uses Gecko release version 11.0 (Firefox, IceWeasel, SeaMonkey and other browsers) from seeing the injection. Lastly it performs a cookie-based verification, this makes sure that the malware is only displayed once per user.

During our tests it wasn’t possible to get the last payload (or the final goal of the iframe), the only thing we were able to extract was a redirect to a random URL, like this one:

 HTTP/1.1 302 Found
Server: nginx
Date: Sat, 13 Sep 2014 02:05:29 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 370
Connection: keep-alive
Set-Cookie: ehihm=7MMcADE2AAIAAgBpphNU__9pphNUQAABAAAAaaYTVAA-; expires=Sun, 13-Sep-2015 02:05:29 GMT; path=/;
Location:   httx://

Which resulted in an empty response:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 12 Sep 2014 23:51:11 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.3.3

High Number of Malicious Domains

The guys from Dynamoo also analyzed this injection and they noticed that all injected domains were using the Dynamic DNS served by Which were pointing first to a server on Linode (London – UK) then, after the redirect to a server on DigitalOcean (Amsterdam – NL). Both servers seem to be offline or waiting for the attacker to boot them up and register the malicious domain in (most of them weren’t resolving to any IP).

This is a list of malicious domains we have detected in the last 7 days:;osiue16.html
The Clean Up

Cleanup is straight forward: Look for recently changed JavaScript files or search for the regex it uses to match the cookie and remove the code from the file. You still have to close the doors that allowed the site to get hacked in the first place. Remember, what you see is only 10% of the problem.

Our preliminary analysis leads us to believe that that the point of entry seems to be the recent RevSlide vulnerability. Stay tuned for more info.

  1. We recently saw a nasty infection that was not showing to search engines. Clearly a lot of people are getting their first notice from search engines, so they were trying to hide it so it could remain active for longer. It was then encrypted using the zend framework.

    Until hosts start locking down their systems and having them behind a quarantine zone, these infections will keep spreading and growing.

Comments are closed.

You May Also Like