Sucuri Blog

Website Security News

Main navigation

WordPress Redirect Hack via Test0.com/Default7.com

EspanolPortugues

Update 9/14/16:

We released a new guide that provides better instructions on how to clean a hacked WordPress site using the Free WordPress security plugin.

We’ve been working on a few WordPress sites with the same infection that randomly redirects visitors to malicious sites via the default7 .com / test0 .com / test246 .com domains. In this post, we’ll provide you with a review of this attack, investigated by our malware analyst, John Castro.

Header.php Injection

In all cases, the malware injects 10-12 lines of code at the top of the header.php file of the current WordPress theme:

Malicious injection in header.php
Malicious injection in header.php

When decoded, you see this main part of the malware:

Decoded malware
Decoded malware

The logic is simple. It redirects visitors to default7. com if it’s their first visit to this site after the infection, then it sets the 896diC9OFnqeAcKGN7fW cookie for one year to track returning visitors. If they are not search engine crawlers, it checks the user agent header.

Random Redirects

Even for eligible visitors, the redirects are random. The chances of the redirect are specified in the $chance variable, which is currently set to 15%.

Default7 .com is not the final redirect destination. Depending on the IP and the browser, the visitor gets redirected further. We detected the following domains were used in the redirect chains:

  • default7 .com
  • test246 .com
  • test0 .com
  • distinctfestive .com
  • ableoccassion .com

Fake Updates for Internet Explorer Users

The most interesting scenario is when you use Internet Explorer. In this case the redirect chain may look like this:

default7 .com
 -> advertisementexample .com/d/p/test246.com?k=e88965c228fb1da3ff5ecff0d3034e7a.1462363771.823.1&r=
 -> maintainpc .soft2update .xyz/vtrescs?tyercv=5qe5FetFrItyco5HNTadzxMu9Nwdv__MlK_dmzyotoo.&subid=102860_bebd063b36f47778fce4592efccae37a&v_id=e5tsIAwpqr6ffJ2kShbqE1F3WXTIU4auGIx7jpVqifk.
 -> intva31 .saturnlibrary .info/dl-pure/1202331/31254524/?bc=1202331&checksum=31254524&ephemeral=1&filename=adobe_flash_player.exe&cb=-1388370582&hashstring=oZy9K7h7eaHC&usefilename=true&executableroutePath=1202245&stub=true

This leads to websites that push fake Flash and Java updates:

Fake Adobe Flash player update

The above redirect chain ended with downloading of the adobe_flash_player-31254524.exe file which was recognized as malware by 27 antivirus vendors on VirusTotal.

Facebook Side Effect

There is an interesting side effect that may help reveal this infection. When you post a link to an infected site on Facebook, you may see (or may not since the redirects are random) a snippet from another site – e.g. test0 .com.

test0 .com redirect when sharing an infecting site on Facebook
test0 .com redirect when sharing an infecting site on Facebook

When you clean the site, the Facebook link will keep redirecting to test0. com when people click on the link. Why? Because of the shared cache. It should be reset here.

Bugs in Malware

There are other side effects of this malware caused by obvious bugs in the malicious code.

For example, in the decoded version you can see this line #9:

if ($_GET['6FoNxbvo73BHOjhxokW3'] !== NULL) {

For some reason the malware checks for the 6FoNxbvo73BHOjhxokW3 parameter, but does nothing if a GET requests contains it. It’s not a problem though. The problem is that the code doesn’t make sure such a parameter exists before checking its value. In PHP, this causes a notice like this:

Notice: Undefined index: 6FoNxbvo73BHOjhxokW3 in /home/account/public_html/wp-content/themes/currenttheme/header.php(8) : eval()'d code on line 9

Many servers turn off PHP notices, so it’s not a big problem. Some still show them, and you can find infected sites just by Googling: “Notice: Undefined index: 6FoNxbvo73BHOjhxokW3”. For me, Google returns 6420 results for this query.

Footer.php

If you check the results for the above query, you’ll see that most of them also mention errors in the theme’s footer.php file:

Fatal error: Cannot redeclare enc() (previously declared in /home/account/public_html/wp-content/themes/currenttheme/header.php(8) : eval()'d code:56) in /home/account/public_html/wp-content/themes/currenttheme/footer.php(9) : eval()'d code on line 2

The reason for this is that this attack previously infected footer.php files where it injected similar obfuscated code at the top. That code declared functions with the same names as the malware in header.php.  As a result, once the attack switched to header.php (in April) and reinfected a site that already had those injections in footer.php, the PHP engine started to show errors about redeclared functions. In essence, both header.php and footer.php were being executed in the same context.

The footer.php variation of the malware was more sophisticated. It injected JavaScript code that would redirect visitors or create popups. It stored the encrypted redirect URL in the .SIc7CYwgY (or .SIc7CYwgY1) file in the site root, or in /var/tmp/.SIc7CYwgY if the site root was not writable. It could also update the stored redirect URL using requests to an infected site that included 8Yx5AefYpBp07TEocRmv as a GET parameter. Nonetheless, they used the same default7 .com domain (encrypted as: IyUOPGlbfjUHCiwgXwZ1aRIpFA==) for the redirects.

Joomla variant

The same search results show as this attack also affects Joomla sites where it injects the same code into the administrator/includes/help.php file.

Infection Vector

In most cases, the infected sites had multiple vulnerabilities. The infection itself was part of a number of other infections in the environment (it wasn’t an isolated event). In some cases, the infection was the only infection and found within the active theme’s header.php file. This is a typical infection scenario when attackers have access to WordPress admin interface and can edit the current theme’s files directly from there.

Log analysis has proved this hypothesis:

203.116.84.253 - - [07/Apr/2016:13:01:35 -0400] "POST /wp-admin/theme-editor.php HTTP/1.1" 302 268 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36"
203.116.84.253 - - [07/Apr/2016:13:01:36 -0400] "GET /wp-admin/theme-editor.php?file=header.php&theme=Chameleon&scrollto=0&updated=true HTTP/1.1" 200 49057 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36"
203.116.84.253 - - [07/Apr/2016:13:01:39 -0400] "GET /?6FoNxbvo73BHOjhxokW3=1&url=http%3A%2F%2Fdefault7.com&chance=7 HTTP/1.1" 200 22 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"

For example, this log excerpt shows how someone with a Singapore IP logged into the site and went directly to the theme editor to modify the header.php file. Then, just a few seconds later the same person used curl to verify the injection using the 6FoNxbvo73BHOjhxokW3 parameter, which is only known to the attacker.

A simple way to address this is to disable the a users ability to edit PHP files via wp-admin (Good source on WPBeginner). You can do this by adjusting your wp-config.php file with the following code snippet:


# Disable Theme Editing
define( 'DISALLOW_FILE_EDIT', true );

That’s why after you remove the malware, it’s important to change all passwords, check for rogue admin accounts, and of course, make sure WordPress and all third-party themes and plugins are up to date. We have a more complete list of steps you can take post-compromise, and you can also find specific post-hack steps in the post-hack section of our free WordPress security plugin.

  • Dave

    Nice work!

  • ok… so how do you stop this from even happening?

    • Philip Ingram

      Exactly. How is WP exposed to this? What is the new vulnerability?

      • hi @philipingram:disqus and @universalindierecords:disqus there isn’t a new vulnerability, it’s a new malware campaign we’re seeing. As stated in the post, there are a number of possible vectors based on the data we’ve been analyzing. Still working to pin point the exact vector, the minute we know more we’ll share.

        • Matt Brighton

          I think what everyone is alluding to is that if you’re going to alert everyone to a problem – it’s probably best to have a solution. Otherwise you get a lot of people worried with no real way to fix it.

  • And the solution to prevent it from happening?

    • It’s hard to give a blanket advice without knowing the exact source. It could be because of vulnerabilities being exploited, could be access control. We’re working to ascertain the exact vector, see if we can’t provide better insights on preventive steps.

      As I’m sure you’re aware, a website attack surface is complex and the vector can be anywhere. There are a number of steps you can take, we highly encourage leveraging a Website Firewall if possible, but it needs to be on all sites on the server, not just one.

      • CatsAreGods

        That’s kind of difficult with shared servers. And your own pricing policy doesn’t encourage that, unfortunately. Perhaps you could look into pricing bundles for clients, who sometimes own a number of minor or quiescent sites that are still technically attack vectors. I forget whether you cover subdomains as part of the prime domain, but if not, that would be a big factor as well.

  • Raising Natural Kids

    How do we remove it?

    • To remove it, either replace the header file with a known good, or manually remove the malicious code snippet.

  • thanks! And the way to stop it from happening is… ?

    • Just updated the post with a snippet to disable a users ability to edit PHP files via wp-admin. This would slow the editing via the wp-admin interface, but won’t if it’s automated via the backend. One good solution is to look at employing Website Firewall across all sites on the same server.

  • Daniel P. Brown

    We’ve already seen it out in the wild with some clients’ sites beginning about a week or two ago. Infiltration was done via the normal means, including existing backdoors that had been on their sites as long ago as 2013. One of them was detected because the code was incompletely injected and caused a parse error.

    • CatsAreGods

      Shouldn’t this be blocked by your firewall?

      • Hey @CatsAreGods:disqus

        If the vector is a software vulnerability it should, but not all Firewalls are the same.. 🙂

        • CatsAreGods

          I was referring to your Sucuri WAF. I recommended it to one of my clients for his WordPress site but he was still hacked a few weeks after putting it in place.

          • Mind send me more info at tony@sucuri.net.. that most likely means it didn’t come from an external attack, but an internal one, but hard to say without more information.. the biggest contributing factor is often cross-site contamination

    • Oh yes, been going for a bit…

  • Use strong passwords (preferably with a random password generator), get loginlockdown or some other bruteforce protection. I have seen some WordPress sites that have had over 200 bruteforce attempts in a single day.

    • Great advice @disqus_ewOQ2zbhZe:disqus

      Also recommend looking at something like a Website Firewall.. you spoke of Brute Force, which specifically targets Access Control, but that won’t do anything about software vulnerability exploits.. 🙂

  • rotexhawk

    Would be great to know if this is a common plugin/theme vulnerability or wether it is a WordPress core issue ? How was the code injected ?

    • Hey @rotexhawk:disqus

      Highly unlikely to be a core issue, if it’s a vulnerability exploitation issue then it’s likely coming from a plugin. But it’s hard to say, most sites have so many different vectors..

      Thanks

      • rotexhawk

        Thank you.

    • Denis Sinegubko

      In the post, I showed how exactly the code was injected. The attacker logged into WordPress and used the theme editor to inject the malicious code into header.php. That’s it. No vulnerability is required when someone has the admin password.

      It’s hard to tell how exactly they obtained the password though. It was either a brute-force attack (the password was not strong and they guessed it) or they stole it somehow (e.g. there are other types of malware that hijack the login form and steal passwords) – In both cases, the best you can do is to change all passwords, check for new rogue admin accounts, restrict access to the admin area of your site.

  • John SomeJerk

    Keep fighting the good fight, thank you

  • Meh. Thanks for the notice, but… I thought this was going to tell us how to prevent it, and what security settings to make sure we had configured in a certain way to guard against it.

    ;-|

    • Hey @ThePrez919:disqus

      Well it depends, what security controls do you currently have in place? This was designed to be informative to help people diagnose what is going on, based on what we’re seeing. Prevention depends on a number of factors, if you’re treating it as DIY project then we’d need to understand what all you have already done. You might already be doing what you need to do. Hard to say, but one of the best recommendations we can employ is to look into a Website Firewall to help prevent any potential attacks against software vulnerabilities.

  • Thanks for letting me know! I already have script that prevents users from editing source from backend. Does it prevent it?

    • Denis Sinegubko

      This will definitely shrink the attack surface. But if the attackers know the admin password they still have some other options to inject malware. For example they can install a malicious plugin, add a malicious widget, or add malicious code directly into your posts.

      So if you suspect a breach, you should always change all passwords and check if there are any new accounts. You should also make brute force attacks harder by limiting number of login attempts or customizing the login URL (there are plugins that do it). You should also consider restricting access to the admin area to trusted IPs only (plugins, server configuration, website firewall).

      Security is an ongoing process. You can’t just close one security hole and be sure that you are now safe.

  • Love this kind of things that you do. Thank you for the analysis, it is very useful.

  • Danny Bahl

    Thanks for your ever supporting posts!
    Will your plugin’s website scan flag this malware?

  • Birgit Kern

    Thanks for digging into this issue and posting it! Appreciate your good work.

  • Charissa

    Excellent article…you guys do a great job of explaining the technical side of site security. I learn a lot from your blog.

  • Marcelo Passos C

    Delete my post Why?
    I was just passing information, can not you?

  • Thanks. Just sent a link to a web connection who found his site redirecting to porn yesterday.

  • abdelhamid

    i delete the header.php and footer.php and i replaced with new one and i change the admin password but nothing comeback

  • Daniel Montanez Jr

    Im about to be depressed as my website just experienced this as of today, this is the most accurate article of what is going on with my website … Just wondering if we had a solution ? .. Or any ideas on where to start getting this fixed

  • Devon

    I think this is what is happening to my website. Although present content does not appear to be affected, I noticed that when I went to preview an unpublished post it redirected to a bogus Windows7-8 website. My Facebook debugger also previews info from the bogus site instead of my content. Will the steps in the article “fix” my site? I am really uncomfortable tinkering with code, do you offer a service to help the less code savvy bloggers like me?

  • Alain

    I checked all the files, no infected ones.
    However, the database seems to be infected as when I changed to an old backup, the redirect stopped immediately. I found that the webmaster left the Search & Replace DB script accessible to everyone, which pretty much gives anyone the chance to replace whatever they want within the database. Warning to everyone : if you use this (handy) script when moving your website, make sure you delete it immediately after usage.
    That being said, if anyone knows how to search the database for malicious code, any help is appreciated.
    If not, I am stuck with a 2 years old backup version of the website as all daily backups made during the past months contain the malicious code as well.

Shares
Share This