I'll add my two cents.
Even if you follow the best practices there is still the possibility of backdoors, usually PHP shells stashed away in previously compromised websites. Since the attackers used the Plesk File manager, finding traces of these in logs is almost impossible as opposed to FTP uploads and xferlogs. You need to find these quickly and deal with them.
I came across a tool that helped track down specific malware signatures that us webhosters deal with regularly, and it's sad that there are few other tools out there to address this common problem. I use Malware Detect, or maldet, and it has made a significant difference since neither Clamav nor Rootkit Hunter are designed for these types of threats.
http://www.rfxn.com/projects/linux-malware-detect/
It is quite good at detecting base64 or other types of encoded malware, although I suggest disabling the quarantine feature so you can deal suspect files manually since it has a tendency to flag all encoded files as suspect. But this is a good type of paranoia, in my opinion. Intruders will sometimes add random text as PHP comments to make base64 signatures even harder to detect consistently, so reviewing these files individually becomes necessary.
For Windows, you can use the signature files that come with maldet to scan with Clamwin with a command similar to
Code:
c:\progra~1\clamwin\bin\clamscan.exe --database=c:\rfxndb -r --infected --max-filesize=2M --log=c:\rfxnscan.log %plesk_vhosts%
where --database=c:\rfxndb is where you copied the latest rfxn.hdb and rfxn.ndb maldet signature files and --log=c:\rfxnscan.log will the be the scan results.
Do not underestimate your customer's ignorance as though you may tell them to NOT re-use their old compromised passwords, they may not take you seriously or someone else within their organization who hasn't been made aware will restore the old credentials. For this reason I have renamed or chmodded the get_password.php to be unreadable in case someone within the customer's entourage can't login because of the password change, goes through the "Forgot your Password" procedure and puts back his old password. This forces them to call your technical support department instead. What I really want to do is replace get_password.php with a more polite page asking to contact us for password problems, when I have the time.
I had a customer restore his old password RIGHT IN THE MIDDLE OF A BOT SCAN and his site was compromised less than two hours later!