2

Related:

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...

Community
  • 1
Shadur-don't-feed-the-AI
  • 31,260

2 Answers2

3

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
Gilles 'SO- stop being evil'
  • 829,060
1

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.

Javier Elices
  • 111