Cleaning the Wp-Page Pharma Hack in WordPress

Pharma hacks are common website infections categorized under SEO spam. With pharma hacks, the attacker exploits vulnerable websites to distribute pharmaceutical content to search engines and the sites visitors. Symptoms of a pharma hack include embedded links and anchor text on pages or modified listings in Search Engine Results Pages (SERPs). These attacks most often target search engines like Google or Bing in an attempt to increase traffic to illegal pharmaceutical businesses.

Finding a site littered with pharma links gets interesting once you dive into the details, tactics, and techniques employed by the attacker. Sometimes a simple cleanup reveals a more extensive strategy by the hacker. Recently, during a routine website infection cleanup for one of our clients, we came across a pharma hack that was dirtying their SEO by targeting the Google SERPs.

The Undeletable Pharma Doorway

In this specific case (originally disclosed by Denis Sinegubko on the Sucuri Labs – The Undeletable Pharma ‘Doorway’), identifying the root of the problem was simple. We traced the infection to a specific file: wp-page.php. It injected a pharma spam redirect page (i.e., doorway) at the root of the site for users coming from search engines.

The payload of this pharma hack produced similar results to this Google SERP screenshot:

The course of action was simple – remove the file by deleting it via terminal or an FTP client. To our surprise, when we tried to verify that injection was removed, it was still there. The spam content continued to show up in the SERPs.

Our first thought was to make sure that the page was not cached.  If it was, we would understand why the spam was still displaying in Google results. When the headers stated that it was not a cached page, we checked the file on the server. Indeed, the file we removed was back with a new modification date. What happened?

We deleted the file again. A few seconds later the file was recreated. This behavior is typical with malware that uses cronjobs to reinfect sites, so we decided to check the user’s crontab. Nothing suspicious was found in the cronjobs. Then our focus immediately shifted to looking for some kind of backdoor.

Identifying the Regenerating Script

After an exhaustive review, we found the culprit.

It came down to a file named nav.php that was embedded in the active theme directory of the site. The first clue was that the file content was adding wp-page.php to legitimate site pages whenever a request was made by Googlebot or Bingbot.

Here’s what we saw:

Appending wp-page.php to legitimate requests wasn’t the real problem; it was the actual regeneration of the file. We found this same file not only appended wp-page.php to the requests, but was responsible for recreating the file (whether it existed or not).

Ok, now we were getting closer! We just needed to figure out what executes that nav.php file.

The answer was inside the header.php file of the active theme:

For those unfamiliar with how themes work, the attacker added an include in the header file that loaded the nav.php file every time the theme was loaded by visitors.

Now we can see why the malicious content continued to appear. The hacker injected this line into header.php to make the malicious code execute every time a public website page was requested. This is mainly done to send the spam to search engine crawlers, but it also recreates the wp-page.php as a “delete protection” feature. After we removed the nav.php and the include in the header.php, we were relieved to see that the spam was gone from the SERP.

There is More to Cleaning Than Deleting Files

This case perfectly demonstrates that a site cleanup is not finished once the malicious files are located and removed. After the initial cleanup, you should always confirm that the malware is gone completely and continue monitoring the site. If you don’t, you may allow hackers to reinfect your site via a backdoor or unpatched security hole. Reinfection may happen within seconds (as seen here) or it may take days before the malware returns, causing another stressful issue.

In this specific case, monitoring the integrity of core files and theme files would have paid huge dividends to the site owner. For those using WordPress, this can be achieved through the use of our free WordPress security plugin.

Additionally, we suggest always completing the following post-hack steps after any compromise.

Lastly, if you find yourself in a position where you feel attackers are injecting spam in your web pages or SERPs, know that we’re here to help.