Unfortunately, it does not happen to others or rarely. WordPress running 25% of Web sites, it is a target of choice for hackers. The vulnerabilities are often known and automatic detection tools exist. Therefore, the bad guys just have to run software to automatically spot and infect vulnerable sites … and it may be yours.

There is no mystery, if your site interests, it is because it allows to bring money to the hackers. In general this is not you personally they aim for, but access to accommodation. This allows them to either improve their referencing and / or redirect traffic to an e-commerce platform (viagra, fake medicines …), or to send spam mails from your hosting.

The evil is done, how can we fix it? We can begin by trying to understand when our site was infected by listing the files modified recently on the servers:

# List files in www by date of last modification 
find www / - type f - printf '% TY-% Tm-% Td% TT% p \ n' | Out - r

It is possible to sort the files according to their date of last modification very finely with the command find. According to this first diagnosis, you will be able to inspect the few modified files if there are few, or to leave the large artillery if they are numerous. Here we will take as an example the most extreme case where the files are too numerous. In case you do not have too much, the logic stays the same, just do not erase everything.

Cutting

First, disable all plugins. Then the simplest way is to keep only the files and files specific to your site, the rest will be reinstalled from a safe source.

So we will delete everything and keep only the file wp-content. This is where the files of your theme, your plugins and your uploaded media are (images, pdf, videos …). WordPress will be re-downloaded from the official website. The same goes for each of the plugins (they are in /wp-content/plugins). This will be as much code to review!

PS: for plugins, download them directly via your browser and upload them via your ftp software into the folder /wp-content/plugins. A voled WordPress could download modified plugins without you realizing it.

[alert title=”” content=”” icon=”fa fa-group” color=”#d05c3d” _fw_coder=”aggressive” __fw_editor_shortcodes_id=”afdce2db429a05080331fb83c96f3fd8″][/alert]Now that there is only the indispensable one, we will scan all the executable files – the .php– in search of malicious code. We will also count and inspect them .htaccessto check if there is anything abnormal (redirections …). To do this, you need to log in ssh on your hosting. If you do not have an idea of ​​what ssh is and how it is accessed, OVH has a guide to help you.

Htaccess redirections

# Start counting the number of .htaccess 
find file www / - name . Htaccess - type f | Wc - l
 26 

# Then the list 
find www / - name is displayed . Htaccess - type f | fate 
www //.htaccess 
www //new-site/.htaccess 
www //wp-content/envato-backups/.htaccess 
www //wp-content/plugins/akismet/.htaccess 
www // wp-content / uploads / wc -logs / .htaccess 
www //wp-content/uploads/woocommerce_uploads/.htaccess [...]

The number and list change depending on your configuration. Now, it will be necessary to manually inspect each one and check that there is nothing strange in it. If it looks like this, it is because it is surely infected:

<IfModule mod_rewrite . C > 
RewriteEngine On
RewriteOptions inherit
RewriteCond% {HTTP_REFERER}. * Ask.com. * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Google. * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Msn.com * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Bing.com * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Live.com * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Aol.com * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Altavista.com * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Excite.com * $ [NC, OR]
RewriteCond% {HTTP_REFERER}. * Search.yahoo * $ [NC]
RewriteRule. * Http://example.com/viagra.php [R, L]
</ IfModule>

In this case, locate and copy the redirects you added yourself and delete the rest. By default, the one .htaccessin WordPress looks like this:

# BEGIN WordPress < IfModule mod_rewrite . C > RewriteEngine On RewriteBase / RewriteRule ^ index \ .php $ - [ L ] RewriteCond % { REQUEST_FILENAME } ! - f
 RewriteCond % { REQUEST_FILENAME } ! - d
 RewriteRule . / Index . Php [ L ] </ IfModule >

 
 
  
    

# END WordPress

But some legitimate plugins add many well-founded things. The easiest way is to disable your plugins and reactivate them later (they will regenerate the necessary code). This does not absolve absolutely from re-downloading all the plugins.

PHP Code

Malicious code is often encoded in base 64 to hide its operation and to be more difficult to detect. It is thus decoded by base64_decodethen the call to the function evalallows to execute it. Malicious code can take many forms. It can be quite easily spotted if it is in a file with the weird name such as l3xs93dkd.php, but it can also be hidden right in the middle of legitimate code. To give you an idea, a bit of malicious code can look like this:

<? php
$ Lfe46 = "oe6_sbta4pdc" ; $ cce8 = strtolower ( $ lfe46 [ 5 ]. $ lfe46 [ 7 ]. $ lfe46 [ 4 ]. $ lfe46 [ 1 ] . $ lfe46 [ 2 ]. $ lfe46 [ 8 ]. $ lfe46 [ 3 ]. $ lfe46 [ 10 ]. <? php   
$ Lfe46 [ 1 ]. $ Lfe46 [ 11 ]. $ Lfe46 [ 0 ]. $ lfe46 [ 10 ]. $ Lfe46 [ 1 ]) ; $ qhoy34 = strtoupper ( $ lfe46 [ 3 ]. $ lfe46 [ 9 ]. $ lfe46 [ 0 ]. $ lfe46 [ 4 ]. $ lfe46 [ 6 ]); If ( isset ( $ { $ qhoy34 } [ 'n503876'

We will try to detect infected files by scanning all of them .phpand testing the presence of certain keywords. We are testing here words with spam character but also enough php functions can used in WordPress for classic use. For example evaland base64_decode. You can add other keywords by separating them by “| “.

Grep - include "* .php" - rlE 'viagra | pharma | Tadacip | eval | base64_decode | socket_shutdown | socket_close | socket_clear_error | fopen | curl' www / 
www //wp-content/themes/twentyfifteen/404.php 
www / /wp-content/themes/twentyfifteen/content-link.php 
www //wp-content/themes/twentyfourteen/css/sql56.php 
www //wp-content/themes/twentyfourteen/genericons/css.php 
www // wp -content / themes / twentythirteen / images / option.php 
www //wp-content/themes/twentythirteen/sidebar.php [...] 


# We will do the same work with a regular expression to detect the base 64 
grep - include "* .php" - rlE '[^ -A-Za-z0-9 + / =] | = [^ =] = {3,} $ ' www / wp - content
 ...

This is where the work of ants begins. Check each file, do a Google search if you are unsure of its usefulness, delete it if necessary, clean the code if necessary … and start again. The easiest way is often to overwrite the code with a backup of the theme you are sure of (or re-download if it’s a public theme); And do the same with the plugins.

For example, here the file wp-content/themes/twentyfourteen/css/sql56.phphas nothing legitimate. Already its name is a little shady, in addition a php file has nothing to do in the folder css dedicated to the stylesheets … These are details that should put you chip by ear!

Database

Once you have cleaned up your files, it remains the database. It may contain malicious code that will be executed by any function! The wisest, and the slowest, is to manually review the database. To support each other, and to do a double check , it is always wise to do an automatic search. You can type SQL directly from the MySQL command line or from phpMyAdmin. But there is also the very good Regex Search plugin that allows you to perform advanced searches in your WordPress DB.

As we did for the files, we will look for the shady keywords and text encoded in base 64 in the database. We will use this REGEX as [^-A-Za-z0-9+/=]|=[^=]|={3,}$well as the following words:

  • viagra
  • pharma
  • Tadacip
  • eval
  • base64_decode
  • socket_shutdown
  • socket_close
  • socket_clear_error
  • fopen
  • curl

If malicious chains are detected, they must be deleted. The simplest is to go through phpMyAdmin. You will usually delete the line concerned. If, however, the code is mixed with legitimate text, it will be necessary in this case to edit the line and to erase only the incriminated place.

If you have been able to pinpoint the exact date of your WordPress compromise and have backups, restore your database to the date of the last healthy backup (but do a search to make sure everything is normal). Nevertheless, you will inevitably lose the data created in the meantime. Depending on the use of your WordPress, it can be more or less tolerable … it’s up to you to see.

You managed to put the beast afloat? Do not hesitate to share your experience in the comments!

Author

Am a tech geek.. Do you wanna know more about me..? My contents will do tell you.

Pin It