Home » Security Bloggers Network » Magecart activity and campaign enhancements

Magecart activity and campaign enhancements

by [email protected] on June 26, 2019

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