Project / Support Center
Welcome, %1$s. Please login or register. February 28, 2024, 09:48: AM
Web Global Net Web Application & Web Development Project Center  |  Technical Issues  |  WHM/Cpanel Topics  |  : Catching Outbound spam from compromised scripts 0 and 1 Guest are viewing this topic. « previous next »
: [1]
: Catching Outbound spam from compromised scripts  ( 22511 )
« : April 09, 2009, 01:00: AM »

Outgoing spam is likely to come from two sources:

   1. Indirectly from a compromised web script in a clients account
   2. Directly from a client

The starting point for both will be the exim mainlog:

    /var/log/exim_mainlog (Linux)
    /var/log/exim/mainlog (FreeBSD)

For the purpose of this document I am going to assume a Linux OS.

The most laborious way to track messages down is to trawl the exim mainlog and to look for anomalous behaviour. This is actually very difficult to do and you really need to narrow down exactly what you are looking for.

Tracking down spammers is a difficult affair, but can be made easier with some preparation of your servers environment. I would strongly advise that you add the following to the exim configuration to enable some extended logging that greatly improves the ease in tracking down on-server spammers:

In WHM > Exim Configuration Editor > Switch to Advanced Mode > in the first textbox add the following line and then Save:

    log_selector = +arguments +subject

This tells exim to log the path on disk from where the email was executed and the subject of the email. You can then interrogate the exim mainlog more easily.

The best way to do this is to obtain the original email header from the spam originating from your server. This you should receive either from the person reporting the spam, or from remnants of a spam attack in the exim mail queue.

The part required in the email is the exim message id in the Received: header line within the email header of the spam.

As an example, take the following email header:

    Return-path: <>
    Received: from [] (
         by with esmtps (TLSv1:AES256-SHA:256)
         (Exim 4.52)
         id 1FZ8z3-0006M4-Do
         for; Thu, 27 Apr 2006 17:04:49 +0100
    Received: from forums by with local (Exim 4.43)
         id 1FZ8zt-0005lz-E7
         for; Thu, 27 Apr 2006 12:05:41 -0400
    Subject: Buy Me!

The Received: header lines are added to the email header, so the original Received: line that we're interested in is:

    Received: from forums by with local (Exim 4.43)
         id 1FZ8zt-0005lz-E7
         for; Thu, 27 Apr 2006 12:05:41 -0400

And the id we want is 1FZ8zt-0005lz-E7

This is the unique identifier for this email that has originated from the server. With this, we can follow the exim transaction on the server to see how it was processed using:

    grep 1FZ8zt-0005lz-E7 /var/log/exim_mainlog

(be aware that the exim_mainlog files may have been rotated so you may have to expand compressed archives and search them instead)

This transaction may look something like this:

    2006-04-27 17:43:41 1FZ8zt-0005lz-E7 <= U=nobody P=local S=4001 T="Buy Me!"
    2006-04-27 17:43:50 cwd=/home/ClientX/public_html/phpBB/ 5 args: /usr/sbin/exim -Mc 1FZ8zt-0005lz-E7
    2006-04-27 17:43:53 1FZ8zt-0005lz-E7 => R=lookuphost T=remote_smtp [] X=TLSv1:AES256-SHA:256
    2006-04-27 17:43:53 1FZ8zt-0005lz-E7 Completed

In this example, we can see that the email originated from the nobody user locally on the server. This means that the likely spam was sent from a script on the server. The nobody user is used to run the Apache web server and is the default username and group that Apache will execute web scripts as. Two things can affect this:

   1. suexec, if enabled, will run CGI scripts as the owner of the script file, typically the cPanel account name
   2. phpsuexec, if enabled, will run PHP scripts in the same manner as CGI scripts

suexec is typically always enabled on web servers and phpsuexec may or may not be. If phpsuexec is not enabled, then in all likelihood, the script run under the nobody account will be a PHP script.

From the example above we can see that a script was run from with the /home/ClientX/public_html/phpBB/ directory on the server, which would suggest a compromised PHP script within that directory.

Here's another example of a spam originating from a client instead of a script. This can happen either with malicious intent, or if the clients PC has been compromised by a virus or worm:

    2006-04-27 17:54:51 1FZ9lT-000707-O2 <= ([]) [] P=esmtpa S=715 id=ABCDEFG T="Buy Me!"
    2006-04-27 17:54:51 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1FZ9lT-000707-O2
    2006-04-27 17:54:51 1FZ9lT-000707-O2 => R=boxtraper_autowhitelist T=boxtrapper_autowhitelist
    2006-04-27 17:54:52 1FZ9lT-000707-O2 => R=lookuphost T=remote_smtp [] X=TLSv1:AES256-SHA:256
    2006-04-27 17:54:52 1FZ9lT-000707-O2 Completed

In this example, the key part is:

This shows that the email was authenticated for relaying using SMTP AUTH (i.e. fixed_plain) and the username from that clients PC.

As you can see, there is a great depth to the amount of work needed to track down spammers on a server, plus there's the additional work of closing holes in insecure scripts if they are the cause. Some instances can be much more complex and require trawling through the Apache logs for domains in /usr/local/apache/domlogs/* which is not a trivial matter.

The best security from such exploitation is to keep your server secure and to be aware of who and what you allow on your server.
: [1]  
Web Global Net Web Application & Web Development Project Center  |  Technical Issues  |  WHM/Cpanel Topics  |  : Catching Outbound spam from compromised scripts « previous next »

Powered by MySQL Powered by PHP Valid XHTML 1.0! Valid CSS!
Sorry, the copyright must be in the template.
Please notify this forum's administrator that this site is missing the copyright message for SMF so they can rectify the situation. Display of copyright is a legal requirement. For more information on this please visit the Simple Machines website.