Infected files? False positive? How to find out where the gap is?

Today I needed to upload some files (use SFTP + Filezilla) and had this:

Clearly it was infected, creation of several files, external calls and change of header.php with codes before the opening of the file. That’s what I could find. Visually and in the code generated for those who visit, nothing was changed (I made sure all caches were deleted).

I did a check, and could not find any breakthrough: I do not use admin, only I have administrative access to the WP control panel, I use iThemes with almost all active modules: Brute Force Protection, System and WordPress Tweaks and others. The database also does not have the wp_ prefix. And I always install plugins and repository themes (very few) or at most purchased from TeslaThemes.

On this server I have about 10 sites, all small businesses that receive a maximum of 50 visits / day. Everyone is infected the same way. In some, even in the .well-known folder there was an infected file (Kaspersky does not even let it open). And in all of them, the same security measures are taken.

Based on this, I thought that maybe the contamination had come from the server (I only access by SSH [] with password) and only from a machine, which I’m sure was not infected.

And I found the following infections:


Searching for rootkit RH-Sharpe's default files...          Possible RH-Sharpe r                                                    ootkit installed:


Searching for Suckit rootkit... Warning: /sbin/init INFECTED


Rootkit checks...
[12:55:40] Rootkits checked : 307
[12:55:40] Possible rootkits: 1
[12:55:40] Rootkit names    : RH-Sharpe's Rootkit

Found in wp archive

[12:54:52] Checking for RH-Sharpe's Rootkit...
[12:54:52]   Checking for file '/bin/lps'                    [ Not found ]
[12:54:52]   Checking for file '/usr/bin/lpstree'            [ Not found ]
[12:54:52]   Checking for file '/usr/bin/ltop'               [ Not found ]
[12:54:52]   Checking for file '/usr/bin/lkillall'           [ Not found ]
[12:54:52]   Checking for file '/usr/bin/ldu'                [ Not found ]
[12:54:52]   Checking for file '/usr/bin/lnetstat'           [ Not found ]
[12:54:52]   Checking for file '/usr/bin/wp'                 [ Found ]
[12:54:52]   Checking for file '/usr/bin/shad'               [ Not found ]
[12:54:52]   Checking for file '/usr/bin/vadim'              [ Not found ]
[12:54:52]   Checking for file '/usr/bin/slice'              [ Not found ]
[12:54:52]   Checking for file '/usr/bin/cleaner'            [ Not found ]
[12:54:52]   Checking for file '/usr/include/rpcsvc/du'      [ Not found ]
[12:54:52] Warning: RH-Sharpe's Rootkit                      [ Warning ]
[12:54:52]          File '/usr/bin/wp' found

Based on all this, can anyone help me? Are these server files really infected or is it false-positive? Is there a way to delete these files? How can I find out how all this originated?

In your case, I would:

  • Delete everything suspicious or restore it back to a good working state
  • Download everything locally and search every single exectutable file for suspicious entries (eval ones, etc) by using a tool that searches text (i.e Agent Ransack) *
  • Apply maldet scanner and set it to a daily cron entry
  • Apply the golden rule: UPDATE EVERYTHING

*If you are lazy about this step, keep your wp-config.php, your wp-content/themes/themefolder/ and wp-content/plugins/ folder locally, remove everything in the webhost and apply a fresh WordPress installation there. This will help you move to the next suggested step, but wont save you from troubles outside public_html.


I followed almost every step:

  • Deleted everything I suspected in /htdocs and /.well-know
  • Fresh WordPress installation from all sites, and checked the writing properties if they were adequate
  • Scanned with Maldet in /www/?/htdocs and nothing was found

It remains only to download all content and check locally.

I also want to do a check on the databases, to make sure nothing was saved there.

As for the golden rule, there is only one thing that was “outdated”, Ubuntu in version 14.04 LTS, that is not necessarily outdated. All the rest I update periodically between 15 and 30 days.

With all these measures, I still can not understand what I may have missed, what gap has been left open. I’ll keep monitoring and see how the server behaves. My idea is to create a new server with Ubuntu 18.04, but if it behaves strangely, I’ll create a new one and move all the content.

Many thanks for the help @ggloveswp.

And my problem has not yet been solved.

There is a “rglosaiw” folder on all websites.

Follow these steps:

  • Scanned the server root with Maldet. It indicated 1 plugin used that could be infected (downloaded from the official repository). I deleted it as it was out of use.
  • Fresh install of all WP (delete all content, I only keep the wp-content folder), I downloaded it in the repository and extracted the files.
  • All themes and plugins, there were no strange files or even codes. In all header.php it added information, but I removed one by one.
  • Everything was up to date and no other user with administrative access to the facilities.

In addition, these are the main processes currently running. Is there anything suspicious?

Can be Putty or FileZilla that are causing this?

I wanted very much to find the cause, because if it is from a WP installation, even if I create a new server, the same can happen.

Felipe, Putty and FileZilla might be an indirect issue: in case your passwords leaked (due to a keylogger in your Windows, e.g.) an attacker would possess all your accesses.

However, I see a stronger possibility on an outdated WP install. A few days ago one of my servers got infected and we couldn’t identify the entrance point, but all the symptoms lead to the same theory because WPs up to date, in the same server, were not hacked.

A good practice, besides keeping everything up to date, is disallowing published .php files under wp-content. Some customers complain, because plugins like the one responsible for webpush notifications don’t work anymore, but in the medium term the rigid rule proves its value.

I also block all xmlrpc.php without thinking twice.

Sorry, I wrote a lot and of course was not able to pinpoint a direction to find out what’s wrong with your server. But I really think it must have been an exploit on a not so up to date WordPress install.

Portofacil, any and all help is very welcome, so without problems do not guide me on the problem itself. :slight_smile:

For installations WP, I have 10 sites on this server, and everything is updated. I visited directory by directory, erased all files (except wp-content), downloaded version 4.8.2 from the official repository, and extracted the files. After this, I accessed each of them to make sure everything was ok.

About two days after this procedure, there were already infected directories.

I’ve always used iThemes Security to block xmlrpc.php and Disable PHP in plugins, themes and upload. But is there any way I can do this directly on Nginx?

Finally, I also follow practically every step of this list.

The Nginx rules created by iThemes Security are perfectly fine.

Just make sure they are included in vhost configuration in first place (not in last, as default EE setup), otherwise they might never be interpreted by Nginx.

Where (file and folder) should be, to be read correctly? The plugin saves the file (nginx.conf) on site’s root.


The .conf file should be placed in /var/www/ in order to work.

Just create a sylink and let it be:

cd /var/www/
ln -s ../../htdocs/nginx.conf ithemes.conf
nginx -t && service nginx reload

This should do the trick.