Thanks for the reply. This is what I got back from our hosting tech support, who suspected a perl vulnerability might have been the culprit:
"The characteristics that led me to believe this yesterday were several perl processes that were running which weren't your typical perl process calling /admin/batch/pop3.pl These rogue Perl processes were calling / referencing a file in /tmp on the server which was owned by the apache user.
Once we killed the perl processes, killed the file, and flushed the queue of any email with "HotPfizer" in the from name, the spam did not return nor did the rogue perl processes, leading us to believe this was a perl injection, fitting the characteristics we have seen for another client who has a weak perl script."
"The characteristics that led me to believe this yesterday were several perl processes that were running which weren't your typical perl process calling /admin/batch/pop3.pl These rogue Perl processes were calling / referencing a file in /tmp on the server which was owned by the apache user.
Once we killed the perl processes, killed the file, and flushed the queue of any email with "HotPfizer" in the from name, the spam did not return nor did the rogue perl processes, leading us to believe this was a perl injection, fitting the characteristics we have seen for another client who has a weak perl script."
