0

Have just had a hacked website flagged by Sucuri

There were a number of backdoor PHP files flagged, which I HAVE been able to delete

However, the index.php file has a spam link injected in to the bottom of it.

I've tried deleting it - which DOES work, but file instantly regenerates.

I've tried changing permissions (it is set to -rw-r--r-- www-data:www-data) to root and editing the file - it instantly changes back to the above permissions on save, and my edit is gone

Sucuri is now flagging the site as clean i.e. no more backdoor present BUT there's obviously something there that is still doing this.

Server has a lot of other sites on it too, and none of these are compromised (obviously, anyway) - and so it seems to be something in this specific site's folder that is responsible.

Is there a way of monitoring WHAT is manipulating the index.php file in order to trace where the problem is being generated from? Any other ideas? (Other than start again from scratch, which I CAN do, but not easily).

Any input welcome - thanks!

freestate
  • 109
  • 2
  • Not sure who closed this, but I disagree that this is a duplicate. I am aware there's a process for dealing with a compromised server but I'm asking a specific question about how to identify which file is changing this file - which is a separate thing, and I dont think you're helping any one else who might experience this issue by just closing as a duplicate – freestate Oct 29 '21 at 21:16
  • 1
    Many on Server Fault will not touch compromised system questions, and have strong opinions that the only response is clean install of known good software, backup restore, and change all the passwords. Especially when its not clear you have fully investigated how threats could persist. Maybe bring up for discussion on meta Server Fault? – John Mahowald Oct 29 '21 at 22:47
  • 2
    The problem with hunting down the source of the changes is that malware does hide things in several ways. You cannot be sure your system is clean in any other way than to reinstall from clean state. Any other action is not professional, and therefore it is offtopic for this site. – Tero Kilkanen Oct 29 '21 at 23:20

1 Answers1

1

With a 644 access flag, the write is comming from the user account, say apache. Maybe you can play a trick on the lurking APT.

Make the crazy move to give this file 406 (r-----wr-) permission and use an account from the others group to edit the file. If the change stays, setup file access auditing, revert to permissions to 644 and see.

If the file changes despite the 406 permissions, your APT likely has root access and you should start rebuilding. It's not your server anymore.

Good luck, and congrats for the cleaning you did so far...

ixe013
  • 928
  • 2
  • 7
  • 25
  • Thanks - the file access auditing link was a big help... So using this I can see that it IS usr/sbin/apache2 that is updating the file back to it's prior state after I edit it. On a whim I stopped apache and THEN edited the file - and it was not overwritten, even after restarting apache. So spam is now gone, but I'm not sure where in the apache logs I can look to find out exactly WHICH file was using apache to overwrite it? – freestate Oct 29 '21 at 21:29