I have a customer with a webhosting server that's running linux who is suffering from this problem. It is not a Wordpress site, although he does run Wordpress sites on that same server.

We're both aware of the problem and that some of those files do indeed have malware content - however, there are also some false positives, and they are affecting the site's functioning (by rendering include files unreadable), so he's asking me to track down which part of the installed software is doing this and to put a stop to it.

Trouble is, I'm not 100% sure what is causing the rename and why. I suspect clamav/amavis because it's in their purview, but nothing in cron really springs out to me as a possible cause for what appear to be weekly scans...


Use a file change audit mechanism such as LoggedFS or Linux's audit subsystem. See also How to determine which process is creating a file?, Log every invocation of every SUID program?, Stump the Chump with Auditd 01...

Assuming that the server is running Linux, the audit system looks like the best solution. Log all file renaming operations in the relevant directory tree, e.g. /var/www:

auditctl -a exit,always -S rename -F dir=/var/www

The audit logs are normally in /var/log/audit/audit.log. Here's a sample log from cd /var/www; mv foo bar with the rule above:

type=SYSCALL msg=audit(1489528471.598:669): arch=c000003e syscall=82 success=yes exit=0 a0=7ffd38079c14 a1=7ffd38079c18 a2=20 a3=7ffd38077940 items=4 ppid=5661 pid=5690 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts11 ses=1 comm="mv" exe="/bin/mv" key=(null)
type=CWD msg=audit(1489528471.598:669):  cwd="/var/www"
type=PATH msg=audit(1489528471.598:669): item=0 name="/var/www" inode=22151424 dev=fc:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
type=PATH msg=audit(1489528471.598:669): item=1 name="/var/www" inode=22151424 dev=fc:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
type=PATH msg=audit(1489528471.598:669): item=2 name="foo" inode=22152394 dev=fc:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
type=PATH msg=audit(1489528471.598:669): item=3 name="bar" inode=22152394 dev=fc:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
  • I ran that command (modified to have arch=x68_64 ) and then created and moved a file, didn't get any log messages about it. – Shadur Mar 14 '17 at 9:57
  • @Shadur Works for me (test scenario: touch /var/www/foo; mv /var/www/foo /var/www/bar). Did you check the proper log file, i.e. /var/log/audit/audit.log (I forgot to mention that in my answer)? – Gilles Mar 14 '17 at 21:55
  • Correction. I've gotten audit logging of the event; however, I'm no further toward discovering who made the change or how it was done, as apparently it doesn't record PID/process name and/or UID of the cause... – Shadur Mar 15 '17 at 12:42
  • @Shadur Uh? The audit logs do contain the PID and the path of the executable. I added a sample log entry to my answer. Do you get something different? – Gilles Mar 15 '17 at 13:18

I know the question was asked some time ago, but the renaming of .php files to .php.suspected keeps happening today. The following commands should not come up with something:

find <web site root> -name '*.suspected' -print
find <web site root> -name '.*.ico' -print

In the case I have seen, the infected files could be located with the following commands:

cd <web site root>
egrep -Rl '\$GLOBALS.*\\x'
egrep -Rl -Ezo '/\*(\w+)\*/\s*@include\s*[^;]+;\s*/\*'
egrep -Rl -E '^.+(\$_COOKIE|\$_POST).+eval.+$'

I have prepared a longer description of the problem I have seen and how to deal with it at GitHub. I suspect that many variants of this malware have been showing up in the past. The way they infect a web site depends on the CMS used and the vulnerabilities available at the time of the attack. In this case, it was most likely Drupalgeddon2.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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