Question

Wordpress automatically installed on droplet without permission; can't remove files.

Somehow WordPress was automatically installed on one of my client’s droplets (or at least the files – I don’t see a WP database) on-top of an existing website (not wordpress). I was able to delete/move most of the files, however there are 2 files and 1 folder which I cannot remove or overwrite even as root. When I try, they are immediately restored. I also cannot change permissions on the affected files, which currently have only read access.

Specifically: public/.htaccess public/index.php public/wp-admin/*

There also seem to be files in the ‘wp-admin’ folder that are also regenerated (perhaps on any web request; not sure). Looking at the contents of the ‘index.php’ file, I also notice a long string of hex code. I don’t know if that is normal for workpress or not. If not, it could be an indication that the system has been hacked.

The server was scheduled for a migration, which according to the history was completed 16 hours ago. I do not know if this is related.

I have no idea how this is possible. Would this be a result of the DigitalOcean “migrate”? Or perhaps a hacker? What would cause files to be locked/auto-restored like that?

Any ideas would be much appreciated. Thank you.

Submit an answer
Answer a question...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

CCM • July 28, 2020
Accepted Answer

Update: After reviewing the log files, I concluded that the system had been hacked via malicious php scripts. The scripts essentially installed components of Wordpress, as well as additional hidden php files in ‘assets/’, ‘resources/’, and some other common folders.

I was initially not able to delete or modify some of the malicious files due to a background process, which would immediately regenerate them if modified or deleted in any way (including permission changes, etc).

To combat this, I changed the ownership/permissions on the ‘public/’ folder (which cut off access to the background process); at which point, I was able to delete the malicious files, and then reboot the server to kill the background processes. After restarting, I restored permissions on the ‘public’ folder and (cheer!) the malicious files did not return. I was then able to restore the proper files, and get things working again. I have taken additional steps to further restrict permissions, to hopefully (knock on wood) prevent this in the future.

As far as I can tell the attackers never had ssh access, but was acting solely through malicious php scripts. How they were able to inject these into the system is still a mystery; but hopefully the steps I have taken will work. I’ll continue to monitor the situation.

For other people experiencing a possible attack, I found these articles and tools very helpful.

https://www.gregfreeman.io/2013/how-to-tell-if-your-php-site-has-been-compromised/ https://www.gregfreeman.io/2013/steps-to-take-when-you-know-your-php-site-has-been-hacked/ https://bash-prompt.net/guides/server-hacked/

Thanks Alex and Tony for your replies.

alexdo
Site Moderator
Site Moderator badge
• July 28, 2020

Hi, @CCM

Is the droplet a plain CentOS, Ubuntu server or it’s a droplet provisioned from the marketplace? Some of the scripts might be re-executed upon reboot and hence cause the issue here.

I will recommend you to check the user owner of the files and also check the files using stat:

stat public/index.php

as this will give you some additional information about the files. You can also try using tools like inotify and inotifywait to watch when the file will be recreated.

Alternative solution will be loggedfs which is tool that monitors the filesystem that will log every access.

Hope that this helps!

Regards, Alex

toni alfaro • July 28, 2020

Have you tried changing the permission on the folders to give you full rwx access? “chmod -R 700 folder1” to the folders or files that you can not delete or modify may allow you to delete this files. What command are using to try and delete the folders. (chmod -R 700 gives the user rwx permissions and 777 will give that user, group and “other” the same permissions. I had a few troubles too when I was using wordpress. It was different though because I couldn’t update the pages I kept getting a “json” error. I couldn’t take this error away so I had to restart the whole site with a different theme and so far it hasn’t given me any errors. Hope this helps. By the way, are you using a third party theme or a theme from wordpress?