I found an instance of the 'January 2012 code mutation' mentioned in this blog post on a server protected by ASL: http://blog.unmaskparasites.com/2012/01 ... n-malware/

The ClamAV rules don't block this one apparently?

Sure, they detect it:

Heres the PHP:

clamscan src/malware/incoming/20111212/index.php
index.php: Atomicorp.malicious.javascript.injector.20111212224703.UNOFFICIAL FOUND

And even the latest obfuscated javascript:

clamscan 1.js
1.js: Atomicorp.malicious.javascript.20111211224413.UNOFFICIAL FOUND

But a scanner can only detect what it can see, so for example if you dont have realtime malware protection turned on (or can not due to resource issues) then we're limited to looking at what upload tools we can hook, such as ftp and web. If they used something else, like Plesk file manager or ssh to upload it then theres no opportunity to see the payload. With realtime malware protection it doesnt matter how it gets there, its gonna be seen. Other less resource intensive methods are limited to the technologies used on the system to allow users to upload content.

Realtime scanning is not enabled, but SSH access is not enabled either for this domain user and ClamAV is enabled for ProFTPd. So SSH and FTP couldn't have been the ways this happened. The attacker must have gone through Plesk then?

More than likely. When Plesk changed to lighthttpd for the control panel that eliminated anyway to hook the stream. So if you allow uploads via Plesk Control Panel (which is on by default if memory serves), then a bad guy could get around FTP and web upload scanning on a system with realtime malware disabled. You'd need to either disable uploads via Plesk, or enable real time scanning.

Nothings gonna be more effective or fool proof than real time scanning.