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)
We are finding many sites infected with malicious redirects inside the .htaccess file, to secondtds.mooo[.]com/go.php?sid=3. That domain is a TDS (traffic controller) which redirects visitors to another website pushing your browser to download this malware: https://www.virustotal.com/en/file/0b6eab15961f92da95a0a4b0d55fee8a8bd0eb39fec1027aa43575802d7a199e/analysis/1441223870/
The redirect chain is:
Here is the .htaccess content:
The attack is quite buggy and doesn't check whether a site is already infected, thus multiple identical redirect rules in the same .htaccess file.
If you find this code, remove it right away!