If you have a WordPress site that is suddenly attacking your site visitors and you discover Silence is Golden in some of your index files then you may find this post helpful. I had to deal with this security issue as well for one of our customers. The following is how we dealt with it. The first portion of remediating any attack is obviously discovery. The discovery portion for this particular attack was blatant… Google blacklisted my client. Doesn’t get much more obvious that you have a problem with your website, then when the gods of the internet blacklist you. Anyhow, first inspection of the site immediately revealed the following javascript at the top of my client sites pages.

if(window.document)try{new location(12);}catch(qqq){aa=[]+0;aaa=0+

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.