-1

We have a shared hosting cgi-server with apache2+php fcgi and dma as mta (it forwards messages to mail relay) - it's Debian Wheezy - on it and with ability for clients to run perl/cgi scripts.There's one client with 70+ sites, and he had been spamming from his ftp-account like crazy. Thing is he doesn't know where the spam script originates from and so do we.

The process(es) who is sending out spam is perl-script hidden as crond - when you check /proc/$PID/cwd it's always /tmp and the file who started the process is already deleted. strace on the process doesn't help - all you see is system calls to make another mail message and headers etc. Searching through the access logs of his few most visited sites for repetitive/suspicious GET/POST requests gets us nowhere.

Should I say regular grep on .php/.cgi/*.pl for base64,eval,fopen,gzinflate and their combinations gives zero result.

The question is - are there any more effective methods/software to find the spam script(s) or to watch which script ran what? Thanks.

kK-Storm
  • 474
  • 1
  • 4
  • 16
  • 1
    "ftp account"? It's a system level account? Did you check for logins for that account? Regardless, offtopic. Not a programming question. This is system administration more than anything. – Marc B Nov 18 '14 at 14:30
  • Maybe an obvious question; is there any antivirus, malware detection or similar software installed on the server? – RichardBernards Nov 18 '14 at 14:30
  • one thing i once saw at a customers server was a hacked wordpress theme that was able to run because eval was active in php. after looking at the hacked php script it became obvious that the script just decoded using the attackers private key and only was called once. it also created a hidden cron job but the file that was executed or the one that created it did not exist. – ITroubs Nov 18 '14 at 14:33
  • @ITroubs yeah, thanks, but how do you find those kind of scripts? Also, a 'hidden cronjon' what's that? – kK-Storm Nov 18 '14 at 18:58
  • @RichardBernards sure, the regular clamav + bunch of modified grep scripts for most known base64,eval etc combinations. – kK-Storm Nov 18 '14 at 18:59
  • @MarcB it's a regular ftp account (/etc/passwd) that can ssh, no logins from it. Good hint about serverfault, thx. – kK-Storm Nov 18 '14 at 19:01
  • the cronjobs in a nutsheel are scripts that run automatically/regularly on the server at a stipulated time . Try going through the apache documentation of cron jobs. Indeed it can be a cron script. – Ahmad Bilal Nov 19 '14 at 17:36

2 Answers2

1

I think, the mal-script here, is not in the usual .pl/.cgi/.fcgi/.fpl extension form, but still executing on system level as a cgi script. You need to check Apache Handlers/Apache MIME types, to see what other extensions are being run as cgi script. Once you narrow down on that, a simple grep should work.

Ahmad Bilal
  • 380
  • 1
  • 2
  • 15
  • Nothing unsual. Each virtualhost has `AddHandler fcgid-script .php` – kK-Storm Nov 19 '14 at 11:16
  • hmm, how about if a normal script is calling another script(the malicious one), which means that the malicious script is not actually on your HDD, but offsite. It is running in your memory. That could be a possible explanation, if not a cronjob or apache-handler thing. – Ahmad Bilal Nov 19 '14 at 17:38
1

I had a similar problem, and following ITroubs's hint, found a cron job, which in this case scheduled a command to be run every 15 minutes, in /var/spool/cron/apache:

*/15 * * * * /var/tmp/lkvnTiofU >/dev/null 2>&1

Commenting this out, changing the file owner and group to root, and finally killing all processes by the apache user with the command perl and deleting /var/tmp/lkvnTiofU seems to have solved the problem.

Looking at open files of the offending processes, with lsof -p [PID] | more where [PID] is the process ID, it seemed that two of the three processes were busy establishing SMTP connections to lots of different servers to send spam, bypassing my servers MTA entirely, and a third process was listening on port 39331, probably a backdoor handling the spamming.

In my case, this was a leftover from an attack I patched a few weeks ago, but in your case, you may need to first identify the original exploit, which may be using a different language altogether, before going through the above.

J Griffiths
  • 701
  • 6
  • 14