WordPress Security: Removing a WordPress Backdoor

WordPress Security: Removing a WordPress Backdoor

Related Query: How to stop wordpress from overwriting the default .htaccess rules &
How to stop wordpress from changing the .htaccess permissions to 444
Level of expertise required: medium

A few months ago, we received a case where all the WordPress sites’ .htaccess files on a client server were getting reset to 444 and the custom .htaccess rules were getting re-written to the default WordPress rules. I recently saw some questions being asked regarding that attack but there wasn’t an obvious conclusion so I decided to do this quick post.

The Problem:

.htaccess rules keep getting re-written and the file permissions keep getting changed to 444.

After a bit of looking around, I discovered a few stray files in the uploads directory. The files had been uploaded to the server via the contact form. A quick security tip: disable the execution of php in your uploads directory via your .htaccess file. Those files were possibly used to add malware in a an obfuscated form to the other directories of the site. A file in core wordpress directory wp-admin – nav-menu.php had some extra bits of code.

There were more stray files in the WordPress core directory and some of the core files had encrypted code injected into them.

The solution

You can spot and remove this backdoor by following these steps:

  1. Take your site offline as soon as possible & change the permissions of the site directory to 600
  2. Re-name the website’s directory (public_html or your domain name) to something else and create a different directory with the same name as the original. Put a file called .maintenence in this directory. this will put your website in maintenance mode. You can use any html you want in the .maintenance file.
  3. Download WordPress. Make sure you download an appropriate version. You can find the version of this wordpress install by viewing the version number in /readme.html (not recommended to keep this file).
  4. Delete the following directories
    wp-includes and wp-admin and replace these with the directories from a freshly downloaded WordPress. This will clean up the core files. It is important to delete these directories instead of merging them as a merge will not get rid of the files that are not part of wordpress core.
  5. In the root directory, delete all files but from wp-config.php.
  6. Replace these with the files from the freshly downloaded wordpress instance.

Now it’s time to do some digging.

Search in files (using grep via ssh) for some classic harmful strings like:

preg_replace, base64_decode, ini_set, $z26[

If you want to dig deeper, here’s a comprehensive list:

There will be a lot of false positives and hence you would need some familiarity with wordpress code and PHP here.
Here’s what I found in one of the stray files:

The deobfuscated version of the code looks like:

There were other pieces of encoded code injected into the WordPress core file and again in the theme’s footer.

When you decode the strings being encoded using the base64_decode function in this code, you see that the second base64_decode string translates to:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

These are the default wordpress rules which our .htaccess file was getting re-written as. You can decode and echo the other strings if you are curious to see their contents on your localhost or on base64decode.org.

Everytime this code gets executed (in this instance, when a front-end page was being loaded) it will chmod the permissions of .htaccess file and hence reset to wordpress default.

After the removal of all this code in all the files, the problem should be resolved.

Get rid of this code in all the files manually.

Once you have spotted and removed all the malicious code, you can go ahead and rename the original domain root directory. Change it’s permissions back to 755. If you do not frequently change the code in your files, you can set their permissions to 444 recursively as an additional security measure.

In SSH, you can use the following command to achieve this:

find . -type f -exec chmod 444 {} \;
  1. Now go ahead and change the name of your original directory back to it’s original name so that your site is live once again.

Preventing such hacks in the future:

You can prevent such hacks by keeping your plugins up to date and adding multiple layers of validation to your forms. To keep a track of the modified files and not found attempts, install Wordfence and iThemes Security. I will do a post on hardening wordpress some time in the future but for now this is it. Hope it helped.

Oziti: Smart Online Marketing.

Not familiar with WordPress or PHP development? Hire us to clean up your hacked site.



  • Nick on May 29, 2015

    Nice walkthrough. I had a similar htaccess related issue on my website and following these steps fixed it. I had spent hours cleaning up the mess created everytime my .htaccess was getting rewritten but all of my work was getting wiped out when this code was getting executed.

    Also the plugins recommended by you are awesome. I automatically assumed that WordPress is secure enough to fend off these attacks but turns out it isn’t. I was able to hide/redirect the wp-login which was I was going for and had some bad experience, it also offered amazing security tweaks. I just installed it and checked some features and I am so excited that everything worked!!

    Thank you so much for this post.

  • Tiago on June 23, 2015

    Thanks my friend. It helped me find the malicious code.

  • W on September 9, 2015

    Hello there,

    I’ve been infected with this backdoor. This page is the most relevant to the symtoms and file changes I have experienced.

    I’d like to know if I can find more info on this backdoor, specially up to which extent can it infect the systems where it is hosted.

    It seems a quite unknown infection, with some simmilarities to darkleech, but not exactly the same. This page has the only description I’ve seen that fits quite a lot with what I’ve seen in my system, so if you could point me in the right direction I’d be very thankful.

    • Oziti on September 10, 2015

      Hi W,
      See if this article is of any help.

  • David on January 1, 2016

    Just fixed this by using wordfence.

    here are the settings for wordfence that worked for me.

    once i deleted the bad code, or had word fence modify the code for me everything was fixed and i could upload the corrected htacess file.

    Note that you need to turn on the disabled sections of wordfence to have it run through the other folders on your wordpress install

    Go to wordfence “options” page
    Scroll to the bottom Set “Maximum execution time for each scan stage” to 15 seconds. Don’t forget to “Save”.
    Try another scan.
    If the scan does not complete, try this instead:
    Go to the bottom of Wordfence “options” page.
    Click the option to view your configuration.
    Look for max_execution_time
    Set the “Maximum execution time for each scan stage” to about 80% of that value. So if it’s 90, try setting the option to 75.
    Try another scan and see if that works.

    Explanation: Wordfence scans run for a few seconds up to several minutes. Most web servers don’t allow processes that run for several minutes. So the way we get around that is that we start a scan, and then after “Maximum execution time for each scan stage” we pause the scan and launch another process and pick up where we left off. We try to auto-detect what the max execution time should be for your server, but sometimes we get it wrong. So we’ve added this advanced config parameter to allow you to tell us how long a process should be allowed to run on your server.
    When you set this value, you must make sure it’s not greater than the maximum execution time that PHP allows. That is the value set in “max_execution_time”. If your web host has set an Apache config variable that limits process execution time or if they have a “killer daemon” that kills long running processes, you also need to make sure that your “Max execution time” is shorter than the max process time that these allow.
    However, you don’t want to set this value too low because it will increase load on your server as Wordfence pauses and restarts every time it hits the time limit. So the trick is to find a happy medium. Often this seems to be around 15 seconds, so try that first.

  • Njengah on March 11, 2016

    Does the resetting of htaccess permissions to 444 always mean you are hacked. Could there be other permissions settings in the server overriding your settings?

    • Oziti on March 26, 2016

      I wouldn’t say always. Perhaps best to contact your hosting company and see if there are any overrides.

  • onur on March 27, 2016

    Guys I cant find a word to tell you. Three words are reflecting my feelings. “I love you.” I fixed the problem by wordfence and were looking for this for several weeks…

  • Tushar on September 17, 2016

    Hi I have same issue and found some code in wp-blog-header.php in top.

    I removed it. Then change file permission of .htaccess to 755 and upload default .htaccess.
    Then rechange to 444 avoid hack again

Leave a Reply

Cross Compatibility

With production and the sales of a variety of devices rising, at Oziti, we are committed to make your website look great on all browsers & Devices.

Optimised Code

Your website comes optimised for the Search Engine Bots. We support Schema.org code, which allows you to output microdata in your site’s code.


Your website is automatically backed up on the server after a specified period of time. If you have made a mistake, we can restore it for you.


Let's get the project started. Just fill in the details below and we'll be in touch with you shortly. Please include any queries and your deadline (if any) in the message.

Please leave this field empty.


Perth's leading website design services provider for the small businesses, professionals and entrepreneurs. We make you look like a million bucks so that you have a strong online identity and can focus on delivering excellence to your clients.
Oziti Web Design, 62 Molonglo Crescent, Baldivis, WA 6171 Phone: (08) 9523 6998

© Oziti Web Design ~ All Rights Reserved