Inverted WordPress Trojan

A trojan (or trojan horse) is software that does (or pretends to be doing) something useful but also contains a secret malicious payload that inconspicuously does something bad. In WordPress, typical trojans are plugins and themes (usually pirated) which may have backdoors, send out spam, or inject hidden links and malware. The trojan model is easy to understand: package malware inside something useful and have webmasters install it themselves.

This week I came across something that I can call an inverted trojan — malware (installed without webmaster consent) that added useful features to WordPress.

This is a typical Black Hat SEO hack that has affected a lot of WordPress site lately. It creates doorways for pharmaceutical keywords and redirects visitors that come from search engines to third-party sites. The way the doorway code work is quite interesting.

The main malicious file is wp-core.php in the site root directory. To use it, hackers inject the following line into index.php

if ( file_exists( 'wp-core.php' ) ){ require_once( 'wp-core.php' ); }

These kinds of index.php injections look suspicious and tell us that wp-core.php was not installed naturally since this breaks basic WordPress conventions.

Lets take a look inside this wp-core.php

Brute-Force Protection in wp-core.php

The file has 500+ lines of code and the beginning tells us that it’s a part of the “WordPress-Protection” package that “Creates the bruteforce protection for WordPress CMS. Makes 302-redirect to protect SE juice” and tells us that in order to use it it should be loaded directly first (as a “WordPress bootstrap”).



I personally don’t buy it, but lets check what it does to be sure.

In the middle of the file, I found the bootstrap code.

First it injects “Bruteforce protection” code into wp-login.php.

‘Bruteforce protection’ injection

‘Bruteforce Protection’ Injection

This adds the onsubmit handler to the login form that sets the antibot_ajax’ cookie. Then it also adds a code that checks if that cookie is set, and if not, doesn’t allow to log in. This looks like real protection against bots that don’t execute Javascript. It’s not bullet-proof, but not malicious either.

Then we see the “Auth 2nd level” code:

‘Auth 2nd level’ injection

‘Auth 2nd level’ injection

This one looks more suspicious since it injects an encrypted code (again, into wp-login.php). However, once un-encrypted, the code appears to be benign. It does exactly what the comment says: it’s the second step of authentication. If the login/password pair is valid, it retrieves the user email from the WP database, replaces all the characters starting from the 3rd and up to the “@” with asterisks and asks to verify this email, providing it in full unmasked form:

Added Email Confirmation Step

Added Email Confirmation Step

So even if a bot supports Javascript and cookies, and passed the first layer of the added anti-bot protection it will fail on this second step since it needs to know the user’s email address. The same is true for humans who might have guessed/stolen the WordPress password — they won’t be able to log in without knowing the email address.

For users that confirmed the email address, this additional step sets the WP_FLV_EMAIL_CONFIRMED cookie for 10,000 days so that they don’t have to confirm the email every time.

The final “bootstrap” part injects the code that includes wp-core.php into index.php (you can see it at the beginning of the post). It makes sure the “bruteforce protection” is used all the time and restores it if its code was removed from wp-login.php.

‘Patching’ index.php

‘Patching’ Index.php

So if we forget the unconventional way to add functionality to WordPress, this code indeed adds a real brute-force protection mechanism. Of course it’s not perfect and won’t help against a targeted attack, especially if the attacker knows the protection method. But it certainly will make WordPress more secure and protect against at least 95% of real-world automated brute-force attacks.

So it seems to be a useful benign software. Right? Not so fast. As I mentioned the wp-core.php file had more than 500 lines of code and this “bootstrap” code accounts to less than 100 of them. So what does the remaining 80% of code do?

The Malicious Part of wp-core.php

The rest of the code doesn’t have anything to do with protection. Actually, it does the exact opposite.

For example, it can show all email addresses stored in WordPress database (this function is buggy and won’t work for many WP installations though). So who needs the email authentication step of that protection if no authorization is required to extract the emails?

It also installs an open redirector. Now the hackers can use sites with this “bruteforce protection” in their email spam, phishing and malware campaigns — they will redirect visitors to whatever websites the hackers specify.


The main function of wp-core.php is managing pharma-spam doorways. If a blog URL has a specific parameter, for example “th“ in http://www .example .com/?th=doryx+150mg then wp-core.php begins to serve spammy content instead of the normal blog content.

If visitors are not bots and come from major search engine Search Engine Result Pages (SERPs), they get redirected to a pharma TDS (traffic directing system) passing along the keywords of the visited doorway. Right now they use these two TDS:

    • hxxp:// alltds .com/v2/search.html?key=…
    • hxxp:// besttdsfarma .com/site/search?q=…
Redirects Detected by Unmask Parasites
Redirects Detected by Unmask Parasites

Before the redirect, the malware sets a cookie with the same name as the doorway URL parameter (in case of ?th=doryx+150mg URL, the cookie name will be “th“) for the next 100 days so that if the same visitors open this page again (even without a search engine as a referrer) they will be redirected again.

If the visitor doesn’t have that cookie, doesn’t come from search results or is a bot, then the visitor is shown a pure spam page staffed with lots of pharma keywords and links to doorways on other sites used by the same black hat SEO campaign.

The content of the spammy doorways is stored in the wp-admin/update-backup.db file.

Not Specific to WordPress Alone

I should mention that although this malware is supposed to work on WordPress sites (WP-specific brute-force protection, paths and filenames, ability to generate doorways using current WP-theme, etc.) it will work just as well on other PHP sites that use index.php as a default index file. The only difference is the WP-specific function will no longer be used and doorways will be generated using the pre-built template in the update-backup.db file, which in case of non-WP site will be stored in the root directory.


This malware is really strange.

      • It tries to target all kinds of PHP sites and has to inject itself into index.php (which can be found literally on any PHP site), but at the same time the main target of the campaign is WordPress sites.
      • It uses the wp-core.php file name, which doesn’t visually stand out from other legitimate WordPress files that you find in the root directory. But this very file name will be suspicious on, say, Joomla or vBulletin sites.
      • Index.php and wp-login.php injections, along with the new wp-core.php file can be easily detected by most security plugins that check integrity of core WordPress files. To make such injections less suspicious the malware contains code that adds useful features to WordPress.
      • Although the “brute-force protection” features do work, the malware author chose to place the its code in the middle of the wp-core.php file making them less prominent. Also, the first non-comment lines of the file show that the code attempts to steal sensitive information. Why bother with real “protection” code if those who can read PHP see the malicious code first, and for those who don’t read PHP, the comments at the top of the file make it clear enough.
      • BTW, it’s typical for hackers to hide malicious code inside larger legitimate files. They usually get some existing plugin or module and add their own code there. In this particular case, I couldn’t find the source of that “brute-force protection” code. Either it comes from a lesser known premium plugin or the hackers wrote it themselves!
    1. Thats a good question. If some can just write whatever they want to index.php then can they not do whatever they want anyway? More explanation would rally help.

      1. In this case we don’t see one particular vector. It’s just what hackers do when they get access to a site.

    2. What are the recommendations for removal? Did I miss that? And, will a Sucuri Scan catch this?

      1. Basic removal instructions are:
        1. Restore index.php and wp-login.php from the original package (restore the whole WordPress core is even better)
        2. Remove the wp-core.php file
        3. Remove wp-admin/update-backup.db (if not done in step 1)
        4. Scan your site for backdoors
        5. Close all security holes (change passwords, update software)

        Our server-side scanners do detect this

    3. outdated plugin (with public submit forms ) or old theme (timthumb.php etc)

      sometimes malware attaches to your ftp session (browser plugin or pc trojan)
      so stay away from FREE theme sites and pirated content in general (no torrents for you)

  1. Interesting, it seems that the attackers were a bit jealous about who can hack their victims. I think their intention on this were more about keeping competitors out more than adding useful features to WordPress. A good wat to kill two birds with one stone.

  2. My site was pharma hacked a few days ago (actually looks like it was hacked on April 30th and was not activated until May 12th… just out of reach of my hosts standard file backup timeframe…

    It seemed to a a little different variation of the one explained in this post though…

    I have now removed/cleaned the source files (3) that were injected/hacked as well as upgraded/disabled plugins and upgraded my cms (wordpress).

    3 infected files….
    /wp-content/uploads/2013/04/cache.php (looks like this initiated the attack) *deleted
    /wp-head.php (this file was inserted, containing the code that inserted the urls/redirects) *deleted
    /wp-config.php (code was injected here to load wp-head.php as the header rather than wp-blog-header) *replaced “wp-head” with “wp-blog-header”

  3. My site was hacked this way but it appears to have inserted code in about 25 sites. I am a bit overwhelmed and am thinking I will just rebuild a few I really want to keep. Probably came in on a plugin that was out of date. I was also hosting a site for a friend that had a very weak admin password I suspect. I feel a bit sick about it at the moment. Good site.

Comments are closed.

You May Also Like