Magento Platform Targeted By Credit Card Scrapers

We’ve been writing a lot about ecommerce hacks and PCI Compliance recently. The more people buy things online, the more of an issue this will be come and the more important it will be to talk about it. We live in an online world where a single mistake can lead to catastrophic results; that impact is amplified when we’re dealing with commerce. In this article, I’d like to describe some interesting credit card scrapers for Magento which are on the rise.

My colleague, Denis Sinegubko (a.k.a., Unmaskparasites), wrote a very informative article about e-commerce hacks specifically affecting the Magento platform back in April. It is a good read, encourage you to give it a once over if you have time – users and webmasters. By coincidence, the sample he used in his article is a Magento Credit Card stealer as well. His example, along with what I’m seeing leads us, me, to believe that we’re in for a new trend of Magento based credit cards stealers.

Recent Wave In The Wild

Now let’s have a look at an example, or in other words – a real threat that can be affecting you.

The sad part is that you won’t know it’s affecting you until it’s too late, in the worst cases it won’t become apparent until they appear on your bank statements.

So how does attack work? We’re still investigating the attack vectors. It seems though that the attacker is exploiting a vulnerability in Magento core or some widely used module/extension. Using this vector, the attacker is able to inject malicious code into the Magento core file.

We’ve seen several different files being injected with this:


After this code is injected, nothing else happens – attacker has everything he needs to successfully spy and steal sensitive/personal information from the infected website. In fact, the attacker gets the content of every POST request.  This is more than enough because POST requests contain data being sent to the server for storage.

Let’s have a look at few interesting parts of this code.

Part One: Conditions


While we’ve seen and detected several slightly different variants, but the PUBLIC_KEY variable seems to be a constant. This indicates that it’s likely the same author who created this whole family of credit card stealers. The variable is later used for encrypting stolen content which means that only the attacker will be able to decrypt it. Also, there’s a nice little purge function implemented for clearing the trails.

How does it work?

There are two conditions:

  1. The visitor must have a Visvo user agent. The attacker is able to use whatever user agent they like,  this is probably used to make malicious requests harder to spot in the access logs. There are tons of crawlers out there that show up in your logs with different names, using a random agent helps mask the events. This is important, because such requests are almost always ignored when searching for suspicious activity manually – which is a mistake.
  2. Another custom parameter is set. In our case it’s this pbf7aac5 stored in the $k2 variable, the file in which all the stolen information is stored is cleared. The malicious script even preserves the file change time to make sure that it won’t trigger suspicion.

If there is no custom parameter passed via the GET method, the script shows the word “Pong” in the browser. This simple   function checks which of the infected sites are still infected. The attacker could use this on regular basis, and I’m sure the attacker has a nice collection of infected sites that he keeps tabs on.

Part Two: Collection


In this part of the malicious code, we can see the attacker is grabbing all of the POST requests. The attacker even tries to store the content transferred by the POST method based on some structured rules which identifies the payment details.

If the structure of the POST parameters match, the attacker stores them all – nothing more, but nothing less. They’ve got all the billing details processed by the infected site. What else do they need?

Part Three: Hiding


Here we can see the encryption and storing of the stolen data that was collected. As I mentioned bit earlier, the data is encrypted using the Public Key that the attacker defines in the beginning of the script. After the billing data is processed, it’s saved in the fake image file which is also defined in the beginning of the script:

$y0 = ‘/home/cloudpanel/htdocs/';

Again, they’re modifying the file modification timestamp so it looks like the file has not been touched for some time, thus making it less suspicious. They’re also adding a fake JPEG header and put the base64 encoded (and previously encrypted) data after this header.

Too complicated?

No, it’s actually quite clever! If somebody loaded this “image” file via the web browser by coincidence, all the visitor would see is the broken image. Nothing more.

The attacker, however, is able to download the whole “image” file to decrypt the stolen contents using their Private Key, and Voila! – now they have all the billing information processed by the Magento e-commerce website. It’s all nicely packed, formatted and collected. All they need is to use the data…

I’d also like to mention one great post which I found during my research of this malware. You can find a nice description of one of the malware variants here:

It was a pleasure to read about their findings (which correlate with my own research) and even more to read – at the end of their article – they recommend our services to affected website owners. Thanks guys!

Another Variant Example

In the previous case the attacker stole sensitive data by checking all POST content and storing it in case of a recognized structure, thus the injection can be placed in any core file that is loaded when the CMS starts. In this second case study, the attacker aims the Checkout Module and the attack itself is more straightforward.

This is the code we found injected:


Yes, it’s one (and not really long) line of injected code. Here it is decoded:


The code is pretty clear – it’s a simple mailer. It doesn’t modify the data, just steals them “in the middle” of the transaction processing so that it’s not detected. All the data which should be secured is sent in a plaintext form to the attacker’s email.

The only interesting thing about this is realizing how the attackers received the data. This time the attack is dependent on a particular module. The attacker knows how the module works and the code it’s built on; all he needed to do was use the module’s own variable in which all the sensitive data is stored unprotected.

It’s the $data variable which is used in the savePayment() function:

public function savePayment($data)

The attackers are getting all of what they need from this variable as you can see in the decoded code screenshot. Simple and effective. Now all your billing data is traveling the internet in the plain-text form!


Magento credit card stealers are indeed on rise.

Is there a solution for avoiding these thefts? Sure there is! Merchants need to understand that they are responsible for the processed data and should do everything they can to secure their environment. The answer to this is hidden behind PCI Compliance. Daniel Cid, our Founder / CTO, released a nice intro to E-Commerce and PCI Compliance post recently that you should definitely read if your website depends on online commerce.

While the information here is specific to Magento, realize that this can affect any platform that is used to support E-Commerce. As the industry grows so will the specific attacks targeting the industry.

Keep your eyes open and stay safe!

  1. Peter,
    Thanks for this post. I do have the following questions:

    Do you have any stats of the number of sites affected by this attack and their patch status?
    Did all these sites that you have analyzed applied the latest patches from Magento including SUPEE-5994?
    Is there a correlation between their patch status or Magento version and these attacks?

    1. Hi Cesar – we’re still investigating so no stats right now. Unfortunately, we’re not always able to find out all the information, but if we’ll find any interesting news, we’ll surely share! 🙂

  2. I’ve just found another instance of this hack, slightly different though …

    its saving all POST data to /skin/adminhtml/default/default/images/fam_layout_bg.gif

    which obviously compromises all users/passwords

    if (isset($_POST) && sizeof($_POST)) {
    $a5 = ”;
    foreach ($_POST as $h6 => $n7) {
    if (is_array($n7)) {
    foreach ($n7 as $f8 => $l9) {
    if (is_array($l9)) {
    foreach ($l9 as $l10 => $v11) {
    if (is_array($v11)) {
    } else {
    $a5 .= ‘:’ . $h6 . ‘[‘ . $f8 . ‘][‘ . $l10 . ‘]=’ . $v11;
    } else {
    $a5 .= ‘:’ . $h6 . ‘[‘ . $f8 . ‘]=’ . $l9;
    } else {
    $a5 .= ‘:’ . $h6 . ‘=’ . $n7;
    $a5 = $i4 . $a5;

    1. Yes, there are several variants and new may come soon. The point is always the same – to steal sensitive data.

  3. “The attacker, however, is able to download the whole “image” file to decrypt the stolen contents using their Public Key…” – that should read “…Private Key…”.

    1. Almost every type of hack has been used somewhere somehow already. This case was interesting for me mainly because it was aimed on Magento and evidently done by same attacker (group). Encryption method and the method of getting the data from the compromised site (merchant) was interesting as well. That’s the reason for the blogpost.

      1. Magento warns admin user about not having applied the critical patches. So the tough moral question is: should Magento warn visitors if admins keep ignoring or disabling this warning?

  4. I’ve been looking into the same issue for about a week with a clients site, I noticed that same PGP public keys in the source which is as good as having base_64 code (:P) and since firewalled the site from the net. Good work guys.

  5. This smells like SUPEE-5344 either not being patched on the affected installs, or the patch is defective.

  6. can someone tell my why having an ecommerce site protected with an SSL doesn’t protect customers in this case? Ie. I thought with an SSL that the data is encrypted. Is this hack somehow capturing the data before it gets encrypted?

    1. TLS = Encrypted in transit. TLS/SSL is for secure TRANSMISSION of data.

      Once it has traveled from the browser to the server, the contents of the transmission are decrypted so the server can use what was sent to it. For example, an encrypted card number is of no use unless it is decrypted so it can be sent to the credit card processor gateway.

      Encryption doesn’t do squat during the period where the data is actively being used, and if your server has been compromised, encrypted transmission and encrypted storage will do nothing to protect you because the attacker has access to the routines and can insert code to skim off whatever they want despite incryption. It’s also why criminals love to get privileged user credentials so they can directly access the data.

  7. This happened to a client of mine but the code wasn’t exploited into their system. They were using a paid third party plugin and asked them for support. The third party tech login into their server to fix an issue with the plugin and injected the code in the customers index.php file. I found it during an investigation of something else and noticed the index.php file that had the code was editing by the same IP the plugin dev used….somewhere in Germany. It was on the clients site for a good 2-3 weeks before we found it and someone in Puerto Rico was downloading the ipg file with the credit card files. I believe they downloaded the file every 3-4 days. When I found it the file was loaded code. They named the file logo and had it in a folder /images/logo.ipg. If you glance over the name you would have never noticed it.

  8. I got live companies cc very high balance straight 7 digits I do western Union transactions at affordable prices you can contact me at Skype:Mr_david_982 sign certified hacker wester union transfer available to all countries worldwide…..

  9. Hey I had a thought. If there are hosting companies that are proactively patching this issue for their customers, would it make sense to add a list of them to this post? Could serve as a useful reference for customers to be pointed in the direction of solid magento hosting companies.

    1. I think that’s a great idea, Kalen. When this was being actively exploited I remember comunicating with Ben Lassani over at Sonassi Hosing and the guys over at Byte & Nexcess on the Magento Stack Exchange and the Magento Community forums about the work they were doing to proactively address the issue for their hosting clients. They’re the only ones I remember communicating with directly, but there may have been others as well.

Comments are closed.

You May Also Like