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, or send out spam, create doorways, inject hidden links or 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 lots of WordPress site lately. It creates doorways for pharmaceutical keywords and redirects visitors that come search engines to third-party sites. But 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' ); }

Such 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 its 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”).

wp-core.php

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

It 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

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

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

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 that fast. As I told 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 hackers can use sites with such a “bruteforce protection” in their email spam, phishing and malware campaigns — they will redirect visitors to whatever websites hackers specify.

Doorways

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

If visitors are not bots and come from majors search engine Search Engine Result Pages (SERPs), they get redirected to a pharma TDS (traffic directing system) passing alone 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

Before the redirect, the malware sets a cookie with the same name as the doorway URL parameter (in case of ?th=doryx+150mg+exclusivity 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 such a 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 Only

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.

Summary

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.
• That’s why it uses the wp-core.php file name, which doesn’t visually stand out from the other legitimate WordPress files that you can 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. And the first non-comment lines of that file show that it tries to steal sensitive information. So 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 should be 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!




Via Sucuri.net