When you use third party software programs, both open source and commercial, there is an increased possibility that they will have security flaws which are exploited. This is true because the programs are well-known, often make the source code publicly available, and because hackers realize that security holes in these programs will exist on a lot of servers.
Recently, I noticed that one of my servers was sending spam emails. I knew this because I was getting mailer daemon notifications of failed emails. Now, these types of email are so common they are easy to overlook. But, in this case, the mailer daemon sending the notices was my own server so I decided to investigate. Sure enough, there was a real problem. But, the question was how I could find the cause. I think most people would say that you should investigate the server logs and I am sure that would be smart, but I wasn’t really sure what to look for or where. When I contacted my hosting company for some help, they were able to determine that the server didn’t appear to be hacked and that the emails were probably being sent from a PHP script using the mail function. They also referred me to a very useful article which offers a method of determining which directory is sending the emails. It does this by adding an extra X-Mailer header (an informational header field in emails) and it also writes all email activity from PHP scripts to a log file.
The process is pretty simple. First, you create a “wrapper” shell script which will add the additional X-Mailer header. Note that at first I had a problem because I created this file on my PC and then FTP’d it to the server and it contained a carriage return symbol that isn’t supported on *nix systems. Just be careful to save your file in *nix format or create the file directly on your server.
The second step is to create a log file to save the header information of the emails with this extra X-Mailer header. You will then run a couple of symbolic links to append the wrapper script to the regular sendmail (or qmail) program. You let it run in this mode long enough to generate some of the problem spam emails and then you undo the process and investigate the results.
Of course, once you know what folder is being used to send the offending emails, you still have to investigate the manner in which the script was compromised, but clearly that is much easier to do when you actually know what script is causing the problems.