> Meaning an insecure PHP form or the like? Any general words of wisdom > on how to ensure the my PHP forms are secure? I'm more than happy to > read up on this, but I just haven't found any material that seems to > describe my problem. PHP scripts are notorious for exploits because the language is just too easy to use. Too many people who either don't know what they are doing or don't care as long as it works put scripts out on the web and get the boxes running them owned. If you allow any sort of user input it needs to be validated to make sure someone isn't injecting commands. Based on what I've read from your posts, it sounds like a PHP script is the culprit. > All the files are owned by user apache and the perl process that is > sending the spam is running as user apache. Good indication that you are correct. >> 3) How did you clean up after the first hack? > > Killed the process removed the files. Used RPM to verify the integrity > of all the binaries on the system. If this were a system level exploit, you wouldn't have actually cleaned up the attack, but you did a good job in verifying the binaries. If the exploit was system level the attacker could have either replaced rpm or installed a root kit to hide her stuff. However, based on what you are saying, I think PHP is the culprit so your cleanup was sufficient, it just didn't plug the hole. Are you running custom PHP scripts (written in-house) or something you grabbed from the web? I would audit them to identify problem areas. Look for any sort of form posting. Also, do you have "register_globals" on or off in your php.ini? j