Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Digging Deep into Magecart Malware Part II

Magecart is the name given to notorious groups of hackers that target online shopping carts, usually Magento. We provided an overview of the group's malware last year and earlier this year, we shared details of a specific Magecart malware case we encountered during the course of an investigation. In this second installment of “Digging Deep into Magecart Malware”, we highlight a couple more Magecart attacks that we encountered during investigations. In our first case, we discuss how the Magecart attackers were able to compromise an e-commerce website and install a server-side PHP script to intercept customer data from the store’s checkout page. And in the second case, we take a closer look at a domain used to exfiltrate data by the attacker that we believe was a compromised server.

Episode I

Most of the time, Magecart attacks we have encountered are malicious client-side JavaScripts that are inserted into a compromised e-commerce website. Commonly, these “card skimming” JavaScripts are heavily obfuscated and hosted at a third-party web server which may either be compromised or hosted by the attackers themselves. However, there are few attack types we encounter that use server-side PHP scripts to intercept sensitive data. Take for example this PHP script:

Figure 1: Malicious PHP Script that intercepts the customer and credit card data from the checkout page

Figure 1: Malicious PHP Script that intercepts the customer and credit card data from the checkout page

This script was found in a seemingly innocent path in an undisclosed e-commerce web server.

Figure 2: Malware path in the web server

Figure 2: Malware path in the web server

The PHP script was planted by the attacker to intercept information, including credit card details and billing information entered by their customer in the checkout page. The information collected is as follows:

  • Customer name
  • Email address
  • Physical address
  • Telephone number
  • Credit card information

Each of the items are delimited with a vertical bar character “|” then encoded with simple Base64 encoding. This encoded data is then saved to a fake image file of which the path was set to ‘/media/wysiwyg/<compromised website domain>5944.jpg

How did the attackers exfiltrate this data? Well, they planted a web shell to access the files, specifically WSO version 4.2.5. WSO is a full-featured PHP web shell that is used by attackers to maintain persistent access to a compromised web server.

Figure 3: WSO web shell's console

Figure 3: WSO web shell's console

So how did the e-commerce website got compromised, you may ask? – the attacker exploited a vulnerability in a Magento utility installed in the webserver called Magento Mass Importer (Magmi). The attack exploited a local file inclusion (LFI) vulnerability in a PHP script component that allowed the attacker to retrieve the credentials for the e-commerce website’s Amazon Relational Database Service (AWS RDS) instance. It also allowed the attacker to execute a Wget command to download a web shell into the webserver that enables the upload additional malicious PHP scripts.

Figure 4. Web server log shows a "Local File Inclusion" attack

Figure 4. Web server log shows a "Local File Inclusion" attack

On a side note, this was not the first vulnerability in Magmi that was discovered, we also reported back in October 2015 of another vulnerable component “download_file.php” which was also vulnerable with LFI.

Figure 5. a vulnerability in download_file.php discovered by SpiderLabs

Figure 5. a vulnerability in download_file.php discovered by SpiderLabs

Moving on, the technique of dumping stolen data to a local drive and then exfiltrating it later on, is nothing new. In 2016, it was reported that over 6000 online stores were infected with the Visbot malware that uses a similar technique. Visbot, however, uses stronger asymmetric encryption to encrypt stolen data and the fake image file, where the dumped data is saved in one of the compromised web server’s publicly accessible folders. In our case, the attacker had complete access to the webserver by planting a web shell and they also opted to use a simpler Base64 algorithm for encoding the stolen data.

Episode II

Another case we encountered was a Magecart infection in a couple of online stores based in Australia. These two e-commerce websites were hit with malicious “card-skimming” JavaScripts. Both incidents involved JavaScripts injected into the websites that were externally hosted at the same domain: darvishkhan[.]net

Figure 6: Injected Magecart JavaScript in compromised e-commerce website

Figure 6: Injected Magecart JavaScript in compromised e-commerce website

With the usual Magecart tactic, the JavaScript skims customer information and credit card details from the checkout page and the stolen information is then encoded twice with Base64. The data is then exfiltrated through an HTTP POST tunnel to the attacker’s domain.


Figure 7: HTTP POST header and body containing the exfiltrated information


Figure 8: Decoded exfiltrated data

We took a closer look at this exfil domain darvishkhan[.]net and found another infected e-commerce website based in Mexico.

Figure 9: Injected Javascript in an Mexican e-commerce website

Figure 9: Injected Javascript in a Mexican e-commerce website

The darvishkhan[.]net domain was also mentioned in a blog from a Korean security firm ESTSecurity. The domain once hosted a malicious file which ESTSecurity linked to Lazarus APT group. 

However, this exfil domain seems to be a compromised website based in Iran which sells musical instruments.

Figure 10: Brick and mortar shop of darvishkhan.net

Figure 10: Brick and mortar shop of darvishkhan.net

Using a compromised webserver help attackers hide and make them more difficult to track. It also helps that they used legitimate looking names in their JavaScripts such as “google.tag.min.js” or “gtm.min.js”. As this server is also an e-commerce website, it is also possible that customer information in this website may have also been compromised. On that note, we have notified darvishkhan.net regarding this issue but haven't heard from them yet.

Episode I IOCs:



Skimmer PHP


Skimmer PHP


WSO Webshell



Episode II IOCs:

  • hxxps:// darvishkhan [dot] net/wp-includes/js/dist/gtm.min.js
  • hxxps:// darvishkhan [dot] net/wp-content/plugins/zendesk/google.tag.min.js
  • hxxps:// darvishkhan [dot] net/wp-content/plugins/zendesk/index.php


Thanks to Alejandro Baca and Damian Lazarus for providing us additional information