Checklist here: http://www.sans.org/reading_room/whitepapers/incident/incident-handlers-handbook_33901

Search for "incident" on this page; there are several publications: http://csrc.nist.gov/publications/PubsSPs.html

This is a great book as well: http://www.amazon.com/Real-Digital-Forensics-Computer-Security/dp/0321240693

Logs?

IDS/IPS alerts?

Regardless of whether you're looking for compromise on a workstation, webserver, or whatever....it all boils down to what logging do you have in place. Without the logs, you can't do much investigating....

If adequate logging is in place, the incident response/investigation process does not deviate just because it's a webserver.

Exactly what Ziggy said. The techniques are the same regardless of whether its a web server, a database server, a domain controller, etc. You may be looking at a different log file and ancillary evidence, but its the same general process. The resources I provided will answer your questions. Check out the "Hackers Challenges" books as well; they walk you through real attacks and the ensuing IH/IR.

You also have to remember that a web app compromise can lead to a full-blown system compromise. You can't just fix a hole in a web app and call it a day. If a backdoor is left unnoticed and active, you'll still have a big problem on your hands. So again, regardless of whether the initial vector is a web app or a user downloading malware, you should still check when files were modified, running processes, user activity, network activity, etc.

This one is actually tough.  In forensics, we have live system analysis and dead-box forensics.  In order to do a complete investigation of a hacking/malware attack, you would want to capture RAM, other volatile information, and a forensic image of the box.  This is really the best evidence for an analysis.  Unfortunately, many Word Press, Joomla, and other CMS sites are run on shared hosting.  You will not get access to the actual server (or the virtual machine) in most cases. 

In that case you are stuck with log files and the malware itself.  Most Word Press compromises are designed to redirect you somewhere.  Although, some will aim for complete access.  You would want to look at the MySQL database and the code base.  Chances are you will find some malicious (and obfuscated) javascript code.  You may also see a ton of strange content stored in the database, fragments of SQLi or other attacks.  You can look at log files and database logs for the source of the injected files.  Most of the time, you will hit a proxy though. 

Off the top of my head here's a couple of things you need to look at for forensic exam post-compromise on a web server. No doubt there's some repetition of what's been said but here goes.

• Logs - check the access logs for the web server for attack strings, access to admin pages and anything else that looks anomalous e.g. access to backdoor files.
• Web root - what files have changed? Check the MAC times for new files and those that have been modified. Are there any new files that look suspicious e.g. .htaccess files, new PHP or JavaScript files. Use the content for malicious code inserts to try and file the bad files but beware of obfuscation.
• Server config - are there any new configuration added? Check for things like malicious Apache modules.
• database -  most web applications have some kind of backing store or database. Are there new accounts added? Is there anything else in there that could provide persistent access?

Your aim ought to be to determine how the compromise occurred, what was carried out after the attack and remedy the situation. Remember to use Google since the attack is probably not unique to you. What web software are you using? Popular packages such as WordPress and Joomla are often the target for automated and effective attacks.

Regards,
Jim