Spotting Malicious Injections in Otherwise Benign Code

Being able to spot suspicious code, and then determine whether it is benign or malicious is a very important skill for a security researcher. Every day we scan through megabytes of HTML, JS and PHP. It’s quite easy to miss something bad, especially when it doesn’t visually stick out and follows patterns of a legitimate code.

Let’s take a look at this screenshot:

seo-position-report .net  - Good or Bad?

seo-position-report .net – Good or Bad?

We can see two scripts at the bottom of the HTML code. The scripts are not obfuscated, have variables with clear names (seoJsHost, amount, orderId) and comments. The structure and placement of the scripts resembles Google’s scripts (e.g. Google Analytics). And we can see that the first script loads a JS file from “seo-position-report .net/SEO-report/js/seoTrac.js“, which suggests that it’s some kind of SEO tracker.

So far so good. There are many little-known third-party trackers — it’s probably one of those. It’s typical for them to load additional scripts from their sites.

The second script most likely configures the code loaded by the first script and prepares it to work with the current site. Quite plausible. So nothing suspicious — let’s move on to the next file…

Stop! Not so fast. You should not trust the code that you see for the first time. Let’s dig deeper, what exactly does the seoTrac.js do? Here is the complete source code:

window.location='http://js.seo-position-report.net';

It’s a page redirection code. It always redirects visitors to that js.seo-position-report.net page. This is not an expected behavior for a script that positions itself as a tracker. Moreover, this redirect prevents execution of the second script.

Now it’s clear that both scripts are simply masking the unwanted redirect and can be considered malicious, regardless of what that js.seo-position-report.net does. By the way, currently it redirects to various ad networks which point to scam ads, adultfriendfinder, and sometimes to parked domains.

Don’t Judge a Book by It’s Cover

What looked quite benign at the first glance, ended up being malicious after a more thorough analysis. So don’t be fooled by the look of code. Scrutinize everything that you can’t recognize.

As a website owner or webmaster, you should be familiar with all the third-party scripts that your website uses so that you could easily spot anything that doesn’t belong. I realize, that it may be not trivial for modern sites that use dozens of different scripts. No problem, you need to employ some sort of integrity control for your site. For example, use a version control system, or simply compare (e.g. diff) server files with canonical backup copies. This way you’ll eliminate the “human factor” and won’t need to rely on your code reading skills only.

Popular Brazilian Site “Porta dos Fundos” Hacked

A very well known Brazilian comedy site, “Porta dos Fundos,” was recently hacked and is pushing malware (drive-by-download) via a malicious Flash executable, as you can see from our Sitecheck results:

SiteCheck Found Malware on Porta dos Fundos

SiteCheck Found Malware on Porta dos Fundos

If you do not want the joke to be on you, do not visit this site (portadosfundos) until it has been cleaned.

The infection starts with malicious javascript injected at the top of the code, which loads content from another compromised site, www.gpro.co.mz:


Read More

Manipulating WordPress Plugin Functions to Inject Malware

Most authors of website malware usually rely on the same tricks, making it easy for malware researchers to spot obfuscated code, random files that don’t belong, and malicious lines injected at the top of a file. However, it can become difficult when the malware is buried deep within the lines of code on normal files.

Why is some malware harder to spot than others?

An attacker’s primary goal is to retain access to an infected site, so they go to great lengths to hide their access methods. There may be hundreds of malicious files that are easy to find. As long as the attacker can regain access, ultimately reinfecting your website, it doesn’t really matter how clever they are in hiding the payload. It’s why it is so important to place extra emphasis in identifying the access vector, most often known as a backdoor.
Read More

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 googlesyndication.com 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 http://www.artevegan.com.br/tpl/conteudo/contador/contador.php was disabled.

Screen-Shot-2014-10-16-at-2.12.23-PM

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 .* - [E=VWM:oktovia.jonesatlarge.com]

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, labs@sucuri.net 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 (politica.estadao.com.br) 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

Website Malware: Mobile Redirect to BaDoink Porn App Evolving

Recently, we wrote about a malware redirection on this blog where the malware was causing compromised sites to redirect their visitors to pornographic content (specifically, the BaDoink app). You can read more about what we found by going to our previous blog post.

As described in the original post, some particular files were infected (examples were the index.php, wp-config.php and others). We thought that was enough malware for one app. However, while we were working on an infected site today, we found a new malware injection causing this redirection.

Since all of the sites web files were clean and we didn’t find any suspicious Apache modules or binaries, it took a while for us to figure the problem out. However, it became much more clear once we investigated the PHP binary and found some suspicious entries.

Read More

Website Security Analysis: A “simple” piece of malware

For regular readers of this blog, there is one constant that pops up over and over: malware gets more complex. When malware researchers, like myself, unlock new obfuscated code, it’s a signal to the black hats that they need to up their game. For me, figuring out their new hack attempts and then putting the findings online to help others is a day’s work, not to mention a big part of the fun. So, let’s get to the fun.

A colleague of mine, Ben Martin, sent me a piece of malicious code that had gone undetected for analysis. It’s important for us to understand how a piece of code goes undetected so that we can update our signatures and catch it the next time. After giving it a quick look, everything seemed to be clear. It certainly didn’t look like anything exceptional. Like I said before, the bad guys are always a step ahead, creating more and more sophisticated malware every day (even every hour), and we’re doing our best to make their “work” as hard as possible. This particular sample would just be properly detected and cleaned like the others. That would be the end of it except I felt like something was a little off.

Every malware researcher has some kind of sixth sense that alerts them when there’s something wrong in seemingly benign code. In this case, something just felt off and this led to me spending several hours with what turned out to be a very interesting analysis


Read More

MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

A few weeks ago we found and disclosed a serious vulnerability on the MailPoet WordPress Plugin. We urged everyone to upgrade their sites immediately due to the severity of the issue. The vulnerability allowed an attacker to inject anything they wanted on the site, which could be used for malware injections, defacement, spam and many more nefarious acts.

This is not something we’re excited to report, but we were right.

A few days ago we started to see a massive number of WordPress sites compromised with malware. The malware code had some bugs, it was breaking many websites, overwriting good files and appending various statements in loops at the end of files.

At the time of the post, the root cause of the malware injections was a bit of a mystery. After a frantic 72 hours, we are confirming that the attack vector for these compromises is the MailPoet vulnerability. To be clear, the MailPoet vulnerability is the entry point, it doesn’t mean your website has to have it enabled or that you have it on the website; if it resides on the server, in a neighboring website, it can still affect your website.

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account (cross-contamination still matters).

Exploited in the Wild

The attacks always start the same, with the attackers trying to upload a custom (and malicious) theme to the site:

194.79.195.139 - - [05/Jul/2014:01:41:30 -0700] "POST /wp-admin/admin-post.php?page=wysija_campaigns&action=themes HTTP/1.0" 302 - "http://site.com.com/wp-admin/admin.php?page=wysija_campaigns&id=1&action=editTemplate" "Mozilla/5.0"

Once they succeed, they upload the malicious theme, they access their backdoor inside /wp-content/uploads/wysija/themes/mailp/:

194.79.195.139 - - [05/Jul/2014:01:41:31 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php HTTP/1.1" 200 12 "Mozilla/5.0"
194.79.195.139 - - [05/Jul/2014:04:08:16 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php?cookie=1 HTTP/1.0" 200 12 "-" "Mozilla/5.0 (Windows)"

They get full control of the site.

The Backdoor is very nasty and creates an admin user called 1001001. It also injects a backdoor code to all theme/core files. The biggest issue with this injection is that it often overwrites good files, making very hard to recover without a good backup in place.

So if you see this error on a site:

Parse error: syntax error, unexpected ')' in /home/user/public_html/site/wp-config.php on line 91

It means it was likely hacked through this vulnerability.

Mass Infections

MailPoet is a very popular plugin with almost 2 million downloads, so as you can expect, when such severe vulnerability is identified, it can be mass exploited.

This is the total number of hacked sites that we were able to identify so far (per day):

Sucuri-MailPoet-Infections

This is based on sites scanned on our free sitecheck scanner. The number of hacked sites is likely much bigger.

Upgrade Mailpoet!

If you are running MailPoet, we recommend upgrading it asap to the latest version. Users of our Website Firewall (CloudProxy) have been protected against this threat since day 0. However, if you do not have a firewall (WAF) on your website, you have to upgrade the plugin or remove it altogether to avoid more issues.