Related

Wordpress error: Cannot write style-custom.css file Question Question
How to manage Wordpress Files through SFTP? Question Question

Question

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

Posted July 28, 2020 165 views
WordPress

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.

Add a comment
CCM
By:
CCM
Add a comment

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.

×
3 answers
CCM July 28, 2020

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.

Reply Report
tony54143fcdd2516652c9e275 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?

Reply Report
  • CCM July 28, 2020

    Hi Tony. Thanks for your reply. In the end, I concluded that the server was hacked via some very malicious scripts. I think I have managed to get things back under control. I’ll provide an answer that explains the steps I took, in case it helps others. Thanks again.

    But to answer your question. The site was never using wordpress at all. The malicious script installed wordpress as a means to facilitate their attacks.

    Reply Report
    • tony54143fcdd2516652c9e275 July 28, 2020

      Oh ok thanks I misunderstood what your problem was. Did you install fail2ban or snort anything similar. Learning these technologies can help you filter out ips you don’t want. It’s sort of funny that they put WordPress folders to gain access. I wonder how it works.

      Reply Report
      • CCM July 29, 2020

        I have used fail2ban in the past. Good idea. Thanks for the reminder. As far as why WordPress? or how it works? — I have no idea. But I assume that since many/most sites are built on WP, that their attack was designed to compromise WP specifically and hide within existing WP files/structure. Since the site isn’t built on WP, it had the opposite effect of taking down the site and alerting me of a problem.

        Reply Report
alexdo 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

Reply Report
  • CCM July 28, 2020

    Thanks Alex. I concluded that the server was hacked via scripts. Essentially the files were being recreated immediately after being deleted via some background process, which I managed to shut down, which I’ll describe below. I’ll check out ‘inotify’, 'inotifywait’, and 'loggedfs’. Thanks again for your help.

    Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help