Interesting to see this post from WP developer Donnacha, on removing various popular nasties from a wordpress install after it has been hacked or compromised.

At work we often see instances where it is not possible to simply return a user’s CMS install to a pre-hack backup and then upgrade (the safest course of action) because of

  1. Confusion over when the hack(s) / compromises first occured.
  2. Confusion over what legitimate content / changes have been made since.
  3. No obviously clean recent backup exists.

So we’re often left with a script / CMS install that needs to be cleaned up and upgraded. Where suspicious files have been uploaded, these are often easy to locate because of the sheer number of requests to these, for example from vulnerable PCs that have been tricked into trying to download a virus or trojan loader. Malicious javascript added to core or template files can be more difficult to spot in this manner as are disguised files referenced from the CMS’s database.

It would be helpful if the development / security investigation teams of most major CMS’s published these sorts of guides. Thanks Donnacha!

Rowan :: Jun.17.2008 :: Security, Support, Web Apps, Web Hosting :: No Comments »