</img>
wp-core.php
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
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”).
</img>
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.
</img>
‘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:
</img>
‘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:
</img>
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.
</img>
‘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 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.
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':
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.
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.