Lately we see waves of a strange WordPress infection.
It usually adds backdoor code at the top of theme files (footer.php, page.php, etc)
and injects the following code at the top of the core WordPress file wp-blog-header.php
and a later modification
which (after decoding) injects the same script from the same server, using its IP address this time: hxxp: //45 .34 .72 .187/1.js
What make this infection strange is the oxxtm’s wp-logo.js script. It redirects visitors coming from search engines to www .oxxtm[.]com but does it in a really surprising way. The script defines 54 URLs, randomly pick one of then and redirects to it. This trick would make sense if those 54 URLs were different, but the script defines 54 virtually identical URLs. The differences are negligible: one with trailing slash after domain name, one without “www.” and the rest 51 with “www.“, plus one slot for “document.location.href”, which adds 1/54 chance that the page will not be redirected.
Now what’s the point of doing this random selection? The only explanation I see is the attackers expected to sell the redirected traffic to multiple clients but failed to find them, so they are leaving their own site in all 50+ slots as a placeholder.
Let us know @sucurilabs if you have a different explanation.
MyFileStore[.]com redirects from vBulletin sites have been a problem since 2011. It is associated with the VBSEO plugin with multiple unpatched vulnerabilities that has been discontinued for more than 3 year now. You can find more information about this hack here
Since then, the code remains pretty much the same. Only minor changes in variable names. Just search either the datastore table or the includes/datastore/datastore_cache.php file for = preg_replace( with strtr inside of it like:
preceded by long gibberish stings that look like this:
Despite the fact that that this hack is very old and VBSEO is no longer supported and should have been already removed from sites, we still regularly clean vBulletin websites affected by this infection.
Please, keep your sites software up-to-date. Secure it to prevent future break-ins.
We regularly find malware that tries to steal client credit card details from Magento sites. Hackers use a few tricks and slightly modify their code from time to time.
For example, we've seen multiple modifications of the code reported in this article. Instead of using HTTP requests to send data to their own site, hackers often just email the stolen data to their emails.
To hide the email address they use the following modification:
where Y3NfdG9vbHM0dXNAeWFob28uY29t decodes to email@example.com
Regardless of the actual code, the best way to mitigate this issue is preserve integrity of Magento core files. The files hackers usually modify are:
Of course, removing the malicious code is not enough. You should find and close security holes to prevent reinfections.
There are many tricks to hide malicious code. One of them is placing it to the part of legitimate files where people don't normally expect to see executable code so they don't skip such places during manual reviews.
Comment blocks are one of such places. For example, this is a comment from an infected wp-config.php file found by our security analyst Brandon Benavente. Can you spot the malware there?
I hope, you noticed, that hackers use */ and /* to close the multiline comment block and open a new comment block. And between them they placed executable PHP code, which may look as a part of the comment. To make it even less prominent, they even split the code in two pieces on two different lines.
include on one line
and "\x2fhom\x65/...skipped...\x2fpub\x6cic_\x68tml\x2fwp-\x63ont\x65nt/\x75pgr\x61de/\x6cogi\x6e.ph\x70"; two lines below.
Since PHP interpreter skips everything in comment blocks, the real code that it sees is:
or, after decoding:
Basically, hackers created a wp-content/upgrade/login.php file with malicious code. To execute it every time when someone loads any WordPress pages, they included that file into wp-config.php. This way the only changed core WordPress file is wp-config.php - the file that is never updated during WordPress updates and the file that normally not checked for integrity because it has custom code (keys, DB credentials, custom settings) and is different on every site.
This means that, depending on the tools you use, you might not be alerted about the file change, so you'll need to review it manually. And when you do it, remember about tricks like this. On one hand, using a code viewer with syntax highlighting may help. On the other hand, make sure you have a backup copy of your wp-config.php. Whenever you are not sure in its integrity, just restore it from a clean backup copy.
Cleaning and protecting websites may be a challenging task. If you need a professional help, you can always count on us.
As we clean many sites infected by the VisitorTracker malware, we see vulnerabilities in multiple plugins being exploited by attackers.
For example, my colleagues John Castro and Marc-Alexandre Montpas analyzed many sites where hackers exploited quite an old version 1.4.6 of the FormCraft premium plugin (current version is 3.2.4). FormCraft 1.4.6 contains a file upload script that is not protected in any way. Which makes it really easy for an attacker to upload backdoors on vulnerable sites.
And here are logs entries that show how this vulnerability is being exploited in the wild:
Remember, both free and premium plugins and themes should always be up to date. If you can't update some software, you should remove it from your server. Alternatively, consider virtual patching provided by Website Firewalls.
WordPress-specific malware is slightly different than generic PHP malware. Inside WordPress files, it can use WordPress API and WordPress database. This allows to create this kind of injections:
It was found in WordPress theme files. The code executes the value of the "render" (deobfuscated) option from the WordPress wp_options table, which it extracts using the get_option WordPress API function
This piece of code can be used both as a backdoor (say to execute arbitrary code passed in a certain request parameter), or to inject a client-side malware (it was found right after the <body> tag in theme files). We actually found the "render" option in the database, but by the time we began working on the site, that option had already been cleaned, so at this point we can't tell what exactly was there. If you find this malware and the original value of the "render" option on your site, please let us know at firstname.lastname@example.org
Here is a mailer script we recently found that appears to be designed to send spam emails.
These kind of scripts are pretty common, there are multiple variations but in most cases they are only designed to send spam. Accessing the file directly without passing a specific variable would cause it to just display a blank page which is used by spammers to hide the functionality of the script.
We recently found another malicious script used to steal credit cards that appears to be injected into compromised websites running Magento, it appears to be sending the information to payment.authorize.ga which is a recently registered domain that mimics the Authorize.net payment gateway
The malware was found in file: ./app/code/core/Mage/Payment/Model/Method/Cc.php
We regularly detect malware that targets Magento payment modules:
In this case, the entire code from the $object all the way to the last line ending with $ctx2); should be removed from the Cc.php file in order to stop the credit card details from being sent to the remote website.
Other files could also contain this malicious code or even different code that will re-add the injection back in the site even after the above is removed, so just contact us if you have any questions and we will be happy to inspect the website.
Just a reminder that your hacked site may be used to anonymously hack third-party sites.
This Joomla com_Myblog exploit script was found on one hacked site:
This code uploads a PHP backdoor disguised as a JPG file using a vulnerability in a really old (and it looks like, not longer supported) My Blog Joomla component.
Still some webmaster use it on Joomla 1.5.x sites and this exploit has proven to be efficient as you can read in this blogpost. This blogpost also provides a quick fix for this vulnerable component. Apply it if you still use legacy versions of this component, but also consider upgrading your site to use software that is up to date (Both Joomla and third-party components, plugins and templates)