We have an email, email@example.com 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.
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.
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:
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.
First, after running the php -i command (which displays full php info), I got the location of the main php.ini configuration file. When I took a look at it, I saw the following suspicious entry:
I was actually searching for the auto_append_file entry (because it is a very commonly used malware entry), but this time, auto-append was empty. Right above it, however, there was an auto_prepend_file entry that had some files assigned and it was this /etc/.loger.php, that looked very suspicious.
Here’s what we found when we opened the file:
Be careful because simply removing the file will cause a crash of your site and will lead to a 500 internal server error, which is why Apache needs to be restarted. However, if you want to schedule the restart for a more appropriate time, removing all of the content from this malicious file (.loger.php in this case) would do the trick and then you can remove it after restarting your apache.
What did we learn
We already knew this, but there is a lot of money to be made by redirecting website links to porn and some malicious agents will do this by hacking legitimate links and websites. In this case, there is still a lot of traffic being driven specifically to Badoink’s App. It’s important to remember that, if you hear reports of visitors being redirected and can’t get redirected yourself, your site is still at risk as much of the malware we’ve seen is conditional. Finally, remember that we can prevent, detect and fix sites built on any platform (examples: WordPress, Joomla, Drupal) so if you’re having a hard time getting rid of the malware or any symptoms of malware, sign up for a plan and our team will clean your site today.
Stay safe and keep your eyes open!
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
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:
220.127.116.11 - - [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/:
18.104.22.168 - - [05/Jul/2014:01:41:31 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php HTTP/1.1" 200 12 "Mozilla/5.0" 22.214.171.124 - - [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.
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):
This is based on sites scanned on our free sitecheck scanner. The number of hacked sites is likely much bigger.
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.
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:
- This infection is aimed at websites built on the popular WordPress CMS
- It is targeting sites with outdated (vulnerable) plugins or weak admin passwords.
- 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:
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.
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.
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).
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:
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.
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.
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 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.
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 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:
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 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/.
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.
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):
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
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?
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.
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:
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.
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.