Two weeks ago when I tried to access one of my WordPress sites through the browser, I was redirected to an ad page. I went inside of the public_html directory and found tons of PHP files with random names (gibberish alphanumerical names). I also found out that a lot of WordPress PHP files had been altered and had an @include at the top which included random files (most of them had ico extensions). This was not limited only to the site which was redirecting to an ad page, it was also happening to all the other WordPress sites in my /var/www/ directory - they were all filled with malicious PHP files.

I found a few files with incorrectly set up permissions and corrected them. I changed all the directory permissions to 755 and all the file permissions to 644. After using WordFense, I was able to eliminate all the malicious PHP files and @include statements and everything returned to normal.

Today however, I again found a ton of malicious PHP files with gibberish alphanumerical names which do not belong. Going through the same process of deleting the malicious files and removing the @include statements seems pointless as this will happen again - its just a matter of time.

How can the attacker generate these files where there is no other write-permitted files? I searched the entire system for write-permitted PHP files and couldn't find any.

Any idea has to how I can solve this?

Edit: We are sure that there is no SSH access. We went through the ssh auth logs several times and couldnt find any successful SSH connections.

We noticed changes in the chmod of several files. How is it possible to change file permission without having ssh access?

We found several users in the WP admin which were not created by us (admin users).

Our server is running on Ubuntu 18.04 - it is hosted on Digital Ocean. Our PHP version is 8.0.8. Our WordPress version 5.7.2

3 Answers 3


First steps:

  • Take the server offline, if you can access it directly. - The chance of your server being part of a larger scheme at this point is pretty high.
  • If you can't take it offline, check your authorized_keys files in ~/.ssh/authorized_keys and remove entries that don't belong to you. (Repeat this step for every user, where ~ is their home-directory. Changing the port only is not sufficient at all - would prob. only take seconds to find the new one.


  • Nuke the server completely and restore a backup from before this occured
  • Check for available updates on the server + the wordpress installation and make sure you're not using deprecated addons/php-code.
  • Have a look at linux-hardening and especially your wordpress installation.
  • Check the authorized_keys files as well as other ssh-configuration files (f.e. /etc/ssh/sshd_config on some systems like debian).

Without finding the root cause for this, it's very likely to happen again in the future, so make sure to secure it, monitor ssh connections/only allow from your IP, etc.

Without further information, there is not much more detail to provide. - Feel free to leave OS information/software information if you need further assistance.

EDIT: Disable root login via password if activated and use in general a non-root user for setup. Sudo is way better in those regards.

  • Hi Sys, I have edited my question, please find the specified software versions and latest information regarding the intrusion. Jul 15, 2021 at 15:04

Once they compromised your site, they added themselves (or retain) to SSH shell access to the server. They no longer require access via Wordpress or html.

At the very least, you need to change all access passwords to the site via your host's control panel, nuke everything, and then evaluate your site's vulnerability (e.g. the manner in which they got in) before putting it back up live.

It might be worthwhile putting a ticket in to your host to kill the hosting and rebuild it so as destroy any trace of the intrusion.

  • Is changing the SSH port a possible solution? Then the intruder would not be able to access my server through SSH as easily. Jul 15, 2021 at 6:38

I have been having this issue for a while now myself and wish I could find a solution. I have done several things including re-imaging to a fresh Digital Ocean Server, cleaning plug ins, reinstalling Wordpress fresh several times, moving the folders used, changing permissions, changing file ownership.

I have temporarily stopped it, but it's not a real fix but I'll get to that.

What I have found, it's connected to some hidden .ico files.

``find / -name ".*.ico" -print``

should find them. You should definitely delete any of them in your web folder.

This will also infect other files in Wordpress, wp-config.php, wp-settings.php, index.php, also possibly the header files.

it will also infect any folder it can write to. I had some basic HTML files in folders for some custom sub pages and while the .html pages were not infected, the folder was full of those garbled letter .php files.

How I have temporarily stopped this. This is NOT a fix, I have not found a fix and I've looked for one off and on.

Whatver is causing this is running as the www-data user or group. I changed the permissions of all my webserver's files to be a different user, but readable in a way that the web server would still function. This has some downsides. I can't update easily without SSHing to the server and changing the user back to www-data temporarily. I also can't upload files.

To get around the uploading issue, I changed the current year's upload folder back to www-data. This meant rogue files started appearing in this folder again. Since everything I put here is image files, I created a cron job that runs every 10 minutes in the root crontab and sweeps any PHP or hidden ico files out and deletes them.

``/usr/bin/find /var/www/html/PATH TO WORDPRESS UPLOADS FOLDER -name "*.php" -exec rm {} +``


``/usr/bin/find /var/www/html -name ".*.ico" -exec rm {} +``

And once again, for the third time, before someone jumps all over my case like they tend to do around here, I KNOW this isn't a proper solution.

  • Aside: the "jumping on cases" is usually the result of the guidelines established for our review queues - and really, more broadly the StackExchange network's, as I don't think any of our queues have rules unique to this site. If a reviewer rubber-stamps a post as "fine" in neglect of the guidelines for that queue, not following the established procedure may well create more work for the rest of the community later. There's nothing personal in it, for what it's worth.
    – bosco
    Aug 1, 2021 at 23:08
  • All that said, yeah, the only solution is to deep-clean the installation, rebuild it from scratch without porting the FS or DB, or hire a well-regarded security firm or freelancer to clean the site for you. E.g. WordFence/Securi/Patchstack's incident response services. Operating a site known to be compromised is super inadvisable, and may well lead to the compromise escalating to much more dire effect. Removing such files with a cron is just suppressing an insignificant symptom. FS access is not necessary in order to use your site to attack your visitors.
    – bosco
    Aug 1, 2021 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.