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.

Massive Malware Infection Breaking WordPress Sites

Update: We identified the root cause: MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

The last few days has brought about a massive influx of broken WordPress websites. What makes it so unique is that the malicious payload is being blindly injected which is causing websites to break. While we’re still researching, we do want to share share some observations:

  1. This infection is aimed at websites built on the popular WordPress CMS
  2. It is targeting sites with outdated (vulnerable) plugins or weak admin passwords.
  3. Malware is highly obfuscated and attempts to inject SPAM to the hacked website

There is, however, one very unpleasant impact of this infection. The infector PHP code is buggy and it is corrupting legitimate website files. It is targeting not only the core WordPress files, but also theme and plugins files. The result are various PHP errors being displayed instead of the normal site content. If you see this error on your site:

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

It means your site is likely hacked. Our sitecheck scanner will warn of this error as well:

corruptedsite

The only known solution (after removal of injected malware)is restoring these corrupted files from the backup. If you are curious about the malware injection, this is what it looks like (randomly generated):

<?php $pblquldqei = ‘5c%x7824-%x5c%x7824*!|!%x5c%x7824-%x5c%x7824%x5c%x785c%x5c%x7825j^%xq%x5c%x7825%x5c%x7827Y%x5c%x78256<.msv%x5c%x7860ftsbqA7>q7825)3of:opjudovg<~%x5c%x7824!%x5c%x782421787825!|!*!***b%x5c%x7825)…

We’ll continue the investigation and will provide more details as they become available. If you suspect you have been impacted by this infection rest assured that our team is ready and actively cleaning this mess up on all websites.

Website Malware – Mobile Redirect to BaDoink Porn App

A few weeks ago we reported that we were seeing a huge increase in the number of web sites compromised with a hidden redirection to pornographic content. It was a very tricky injection, with the redirection happening only once per day per IP address and only if the visitor was using a mobile device (IPhone, Android and a few others).

These types of injections are called conditional redirections because certain conditions need to be met for them to redirect visitors. They are not always present and the malware authors try very hard to hide them from the website owner. The malware code looks for logged in cookies to try to identify whether or not someone is managing the site and then attempts to never redirect someone who is logged in. Finally, if a visitor gets redirected once, the malware will not redirect them again. The goal for the malware author is for visitors to not report something going wrong with a website. In this example, if you were to visit an infected site, you’d be redirected, but from your point of view, maybe it was just something weird so you retype the url and now you aren’t redirected. Since everything is working normally now, you decide not to report it and the malware lives on.

As you can imagine, this sort of malware can be difficult to troubleshoot. In fact, very often webmasters think it’s a typo and move on instead of investigating what happened. For that reason, most sites remain compromised, so if anyone ever complains that your site redirecting to “instabang.com” or a Badoink Porn App, it is very likely your site is hacked.


Read More

Is my website hacked? If you have to ask then, “Yes.”

The problem with phishing, and therefore the reason so many people have trouble with it, is that the code is fairly benign and can be very difficult to spot because it usually looks almost exactly like legitimate code. Oftentimes, a website owner won’t know their site is hacked with a phishing scam until site visitors inform them, which is why finding phishing pages can feel like searching for a needle in a haystack.

That’s what makes the following story so instructive.

Many thanks to our own Ben Martin for walking us through the scam (and for cleaning the client’s website).

The Problem

Recently, we cleared malware from a client’s website and our malware removal expert, Ben, found some interesting phishing pages.

Where was the injection located?

It’s in the hacker’s best interest to hide their phishing pages and they’re often able to do so because the code is so benign. They don’t need to run malicious scripts or inject iframes. In this case, the page doesn’t contain any suspicious functions or calls to Russian domains. It just consists of text input fields, a.k.a. normal sorts of code you’d see on any website. The key then is to know what you’re looking for and to do that, you have to think like a hacker.

What are phishing scams attempting?

This is where it becomes important to remember what a phishing scam is normally attempting to do. In many cases, they’re looking for bank records like credit card or debit card numbers, so we kept it simple and searched, “bank,” and look what we found:

Bank

See it? The title_netbank.jpg looked suspicious and, interestingly enough, all it took was that one reference in index.htm to the .jpg file to lead us to the phishing pages. We didn’t stop there though. We also dug a little deeper and found an .htaccess file in the directory.

htaccess

What you’re seeing here are IP addresses that are allowed to view the phishing page. In this case, only those with Danish IP addresses are being redirected to view the page. In this way, the hackers are able to to narrow the scope of their attacks to those who are most likely to enter their bank numbers, while not showing a suspicious page to extra people who may alert the bank or our client to the scam.

Here’s what this specific page looked like. It was being used to redirect customers to something that looked like a Nordea Bank AB user page (Nordea Bank is a financial group operating in Northern Europe). Even if you’ve never heard of Nordea, potential customers based in Northern Europe would have heard of the bank and would have been put at risk.

Nordea

What did we learn?

The hack we cleaned here isn’t extravagant. It wasn’t obfuscated behind layers and layers of code. In fact, it was relatively simple, which is instructive. Malicious code can affect your website even when its relatively easy to spot. The lesson as always is, if you have a feeling that your site has been compromised, then it probably has been.

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 ☺):

Blog1

The headers tell us that miami.hostmeta.com.br 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 (http://www.siteadvisor.com/sites/presten.com.br). This makes it pretty difficult to tell where the spam came from, right?

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

Blog2

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:

blog3

From that image, we can see that http://www.dbdacademy.com/dbdtube/includes/domit/new/ 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 http://masd-10.com/contenido/modules/mod_feed/tmpl/old/?cli=Cliente&/JMKdWbAqLH/CTzPjXNZ7h.php, which loads an iframe hosted on http://www.gmff.com.hk/data1/tooltips/new/.

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.