Fig 1: Hits of compromised websites in the last three months
Fig 3: Crawler’s heuristic detection
Fig 4: Malicious script after three levels of deobfuscation by the crawler.
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
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 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
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.