Unable to track the spammer

Firstly, please put all shell listings in [code][/code] tags, otherwise they become unreadable due to lost linebreaks and monospace font.

You say you used "clamscan" to find the malicious script... Do you mean you used the virus scanner that comes with Virtualmin? In that case I'm not surprised that it didn't find anything, since it's not "tuned" for web malware, but only for stuff that tries to infect Windows machines and so on. :)

You might want to download the software "Linux Malware Detect" and run it against your /home directory. That's specifically for malicious web scripts. It can also run automatically and periodically, which you should have it do.

Regarding Postfix... Provided the bad script uses SMTP connections to deliver its stuff, you can do several things. For one, remove the directive permit_mynetworks from the lines smtpd_*_restrictions in the file /etc/postfix/main.cf. That will force all deliveries, also local ones, to be authenticated.

Local websites will then be unable to send out mail without SMTP authentication. (Be careful about this, it might break email delivery from legitimate sites, but you can certainly do this while searching for the bad website.) If a bad script tries to, you'll see this in the mail.log and auth.log. In turn, when the bad script does authenticates itself, you can see the username used in the mail.log.

You can also do watch -n 1 "netstat -tpn | grep :25" to catch all connections being made from/to port 25 of your system. The number in the last column is the process ID, which you can then match against ps aux | grep ID to find out which website makes the connections. This is, provided you're using FCGI as PHP execution mode, only then will each site get its own process.

If the bad script puts the spam directly in the Postfix queue using local delivery, it's gonna be more tricky. In that case, you need to closely watch the mail.log, and disable one website after the other, until the spam influx stops. Actually, this disable-one-by-one method you can use in any case if you can't catch the culprit otherwise.

In all cases, you should check the process list ps aux for any processes that should not be there, especially running non-php processes under users, or files in the /tmp directory or so.

With those steps combined, you should be able to find out the responsible site. If you need advanced help with this stuff, I can offer you to do a screen sharing and Skype session.

Howdy,

Also, are you able to see a copy of any of the spam mails that are going out? They will typically contain information regarding how they were sent, and what account sent them.

You may not actually have any malware, it could just be an account that was broken into, or a web app with a security issue, or similar.

If you can share the email headers from one of the messages that was sent out, we can review that and help identify the source.

-Eric

Yes Eric has a good point there. If you're not sure whether it's a regular email user or a website, it could well be the former. In that case, you have information about the user both in the mail.log and in the mail itself. In the mail you'll have a received header like so:

Received: from HELONAME (HOSTNAME[1.2.3.4]])
 (Authenticated sender: sendinguser@domain.tld)
 by MAILSERVERHOST.tld (Postfix) with ESMTPSA id 8BB134482D
 for <recipient@domain.tld>; Wed, 26 Feb 2014 16:47:08 +0100 (CET)

BTW Linux Malware Detect is located at https://www.rfxn.com/projects/linux-malware-detect/

R-fx Networks has some great admin scripts -- I have used them for many years.

This can be a big pain. As the guys above said, especially Locutus, Maldet scanning and removing 'permit_mynetworks' to force authentication is a good way to go to quickly tackle the problem. Another quick way to trace and shutdown this type of problem is to view the list of Virtualserver logs, eg: '/var/log/virtualmin' and sort according to 'Last modification time'. The offending Virtualserver will quickly give itself away.