Only slightly further inspection reveled a few newly introduced index.php files with the following
// Silence is golden.
Following identification I moved on to attempting to determine the scope of this attack. This turned out to be much trickier then I first thought it would be. For a full run down of how I finally ascertained the attackers access (through blunt force trial and error), please read my post on WordPress and Toolpack. Short of the long is that the attacker had multiple successful attack vectors and was able to execute their own php code on our clients server through a few different instances of Toolspack.php. In order to identify malicious php files that were placed on the server I used grep to search for any files that contained base64_decode. I removed all the files that contained bas64_decode which did not match the core files in Wordress. It is important to note that some of the default WordPress files used for rss and atom feeds utilize basee64_decode. Following removing ALL the malicious code (this took awhile) I generated new keys for WordPress, changed all the passwords to the site using the WordPress Key Generator. You need to check all files on your website and your database for any issues. I used the following script to check my database content
SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%' UNION SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%' UNION SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'
As recommended by this fairly popular post. I will be the first to acknowledge that the above script is absolutely not the end all be all for checking your database content. It is simply a good start for identifying anything obviously malicious. So that was pretty much it, same remediation as every other attack: Discovery, Scope and Vector Identification, Remediation, and Continuous Monitoring following the attack. Here are a few good links that may help you out if you WordPress site is hacked.