Magecart Skimmers Are Alive and Well – Constant Vigilance Is Required
Magecart skimmers are here to stay, and they’re becoming more sophisticated, more creative, and harder to detect. In this post, we reveal a new skimmer infrastructure that targets ecommerce sites all over the world with advanced methods of detection evasion and obfuscation.
In thorough tests, Akamai Client-Side Protection & Compliance was shown to be effective protection against the skimmer attacks described in this post. Client-Side Protection & Compliance successfully detected the read attempts from the sensitive input fields and the data exfiltration, and events were created successfully in our Akamai Control Center console.
Detecting Magecart skimming
Magecart skimmers are becoming increasingly advanced in their ability to steal personal information from ecommerce sites. Let’s walk through a successful detection of Magecart skimming — one in which the attacker had used some of the most elaborate evasion techniques ever seen — and determine why it had worked for so long.
Although skimmers seem to be able to dodge the traditional protection systems running on even the biggest ecommerce sites, hope is not lost for website owners. We’ll explain how Akamai Client-Side Protection & Compliance monitors for abnormal behavior and can alert you to any unexpected activity, malicious code, and outstanding vulnerabilities — making you better able to stop skimmers immediately.
What is Magecart skimming?
A Magecart attack refers to a type of cyberattack that targets ecommerce sites by injecting malicious code into checkout pages, allowing bad actors to “skim” user credit card details input to the HTML form. The credit card information then goes directly to a server, where it’s either used by the attacker or sold on the dark web. Magecart attacks have increased in regularity over the past few years, and high-profile targets have included Ticketmaster and British Airways. In the British Airways attack, the existing JavaScript (JS) on the checkout page was modified — a move that went undetected by both administrators and users — and more than 380,000 credit card details were stolen. Magecart attacks pose a substantial risk to ecommerce sites, and any other site that collects user information, as highly sophisticated attackers use obfuscation methods to disguise malicious code and use geofencing to obscure their own whereabouts.
How we protected our customer
In late October 2021, we came across a Magecart attack on SCUF Gaming International, a leading manufacturer of custom-built PC and console controllers, in which credit card details from more than 32,000 customers were stolen. The skimmer was detected and removed on March 16 after a month of running on the targeted site. What we found out in this instance, turned out to be the tip of the iceberg that led us to investigate and expose a very sophisticated, broadly deployed Magecart skimmer infrastructure. This brand of skimming attack is still active today on many ecommerce websites.
Like most Magecart attacks, the main goal of the scufgaming.com attack was to steal credit card information. Many of the attacked websites were built with Magento, an open-source platform used to build ecommerce sites. We assume the attackers exploited known security vulnerabilities on Magento to gain access and inject their malicious script loaders on the targeted websites.
As Magecart protections keep growing, we see more and more attacks that implement sophisticated anti-detection and anti-research mechanisms to bypass protections. These traditional protection mechanisms were running on all the targeted websites we tracked, and yet this evolved attack method went undetected.
How to track skimmers
One of the main techniques this skimmer uses to evade detection is the registration of new unique domain names for every (or almost every) targeted website. This is an unusual anti-detection technique that makes it harder to track a skimmer. It also gives the skimmer the flexibility to deactivate the attack when it’s exposed on a specific website while keeping the attack active on others.
In our case study of scufgaming.com, the response returned from the skimmer’s domain was an innocent JavaScript code related to a known logger library, without any malicious code. We found that the skimmer's command and control (C2) server responds with clean code when running on nonsensitive pages, and only sends the malicious code if it runs on checkout pages, where credit card information can be found. This ability to hide malicious code and only execute it when needed is another example of Magecart’s increasing sophistication.
The first step of our investigation focused on determining the skimmer’s code and looking for additional targeted websites. We traced after the skimmer and found — and notified — three more websites (whitemountainshoes.com, goldboutique.com, nafnaf.com) that contacted the same resource as the one we found on scufgaming.com.
At the time of this writing, the attack was still active on whitemountainshoes.com, and had been running for at least 7 months. All these websites were attacked by the same skimmer group within one year, and we found even more frameworks and libraries (like AngularJS and Modernizr) that were used by the skimmer to hide the malicious code. Using these sites, we detected more websites targeted by this skimmer. On some of these sites, the attack is still active.
Characteristics of the attack
This particular skimmer had utilized advanced evasion methods, making the attack even harder to detect than traditional skimming attacks. For example:
The malicious code was not injected directly into the page, but rather used short loader scripts that initiated a request to the skimmer web server and fetched the malicious JS code. We found many forms of loaders used by this skimmer, some of which use some interesting hiding techniques.
On www.scufgaming.com, a script tag with base64-encoded string that translates to an xhr request fetches the malicious JS code. The code will be executed only if the user is on checkout pages. The script tag is removed whether a request comes out or not.
- On www.goldboutique.com, the request to the skimmer’s JS code hides inside a legitimate third-party service script loader. The skimmer domain is split with string concatenation, making it harder to search for the domain by researching the html of the page.
- On www.schlafstaette.de/, the skimmer fetches an image from a first-party URL and uses the onload event to inject the malicious script loader. In this case, they also use base64 encoding to hide the URL of the skimmer. The image tag is removed after the malicious code is fetched.
This skimmer registered a unique domain for each targeted website. In some cases, we noticed that domains used by the skimmer are very similar to other domains used by third-party services in the attacked website. This technique enables the skimmer to hide among all the services running on the attacked websites.
- https://www.proaudiostar.com/ (The skimmer is still active at the time of this writing.)
Legit third-party script: https://static.zdassets.com/ekr/snippet.js
Skimmer script: https://static.zdassets.io/ekr/?_=1615235875517
Legit third-party script: https://browser.sentry-cdn.com/5.28.0/bundle.min.js
Skimmer script: https://sentry-cdn.io/5.9.0/
The malicious JS code of the attack is never fetched alone, it’s bundled with some generic JS frameworks code like AngularJS, Logger, or Modernizr. This makes the malicious JS code seem more legitimate, and offline file analysis won't be able to detect the skimmer. As mentioned above, the hosting servers used by the skimmer only return the malicious code in specific conditions, like checkout pages or specific sections\pages, and they exclude sandboxes. When we tried to get the skimmer’s resources directly outside the attacked websites, we always got clean code of some framework or library. The malicious code is heavily obfuscated so it’s hard to understand the skimmer's logic at first sight, but once we get rid of the obfuscation it’s crystal clear which fields are being attacked.
The skimmer waits with the data exfiltration until the end user fills in all the input fields on the page. It exfiltrates the data to its C2 server using a single request including all the personal information. The exfiltrated data is encoded.
- In one of the malicious scripts we investigated, we found usage of WebGL JavaScript API to detect virtual machines. In many virtual machines, graphics card hardware drivers are replaced with some software renderers. The skimmer looks for known graphics engines that are commonly used in virtual machines or controlled browsers, such as swiftshader, llvmpipe and virtualbox. This common anti-research technique is used mostly by desktop malware in order to avoid their reverse engineering. This was the first time we saw an implementation of it inside a web skimmer.
In order to hide their domain name even more successfully, the skimmer tries to mimic legitimate services and websites by redirecting direct requests from their domains to other locations.
Akamai’s solution
Akamai tested our web skimming protection product, Client-Side Protection & Compliance, against the described attack. Client-Side Protection & Compliance successfully detected the read attempts from the sensitive input fields and the data exfiltration. Events were created successfully in our Control Center console that led to fast and effective mitigations.
As skimmers improve their attacking abilities, we will need to improve our defensive abilities. That’s why the effectiveness of Client-Side Protection & Compliance is not restricted to this particular case of web skimming. The software was designed from the beginning to detect behavior anomalies in general and to intelligently assess risk so that website owners can take appropriate actions.
Conclusion
As we have seen, not only is Magecart skimming alive and well, but skimmers are evolving and becoming even more sophisticated. Attackers have developed new and complex methods to evade detection of their malicious code and themselves. Many existing protection solutions rely on predefined allowlists/blocklists, scanning, and/or sandboxing, all of which skimmers are dodging in order to steal information.
However, there are solutions that skimmers are unable to bypass. The ability to detect changes or vulnerabilities in script gives website owners more control and visibility. As a result, they will be alerted to any potential skimmers almost immediately. Akamai Client-Side Protection & Compliance ensures enhanced security and faster action in the case of an attack.
This interesting cat-and-mouse game will continue to evolve for the foreseeable future and it will require powerful, flexible, intuitive solutions to keep ahead of bad actors and their evolving strategies.
Skimmer indicators:
All the IPs used by this skimmer were from same two ASNs:
ASN197695 (AS-REG, RU)
ASN29182 (THEFIRST-AS, RU)
Resource hashes used by the skimmer:
582a1bbd458b78d84e766db3737ab47b4127d3410b85f173c2ec64d242856f0e (Logger)
2a0bf40f45c28e0dbf5ca9cdac539780761626cc98a59e2d3caeaac9166474e2 (Angular) JS
B6a2c36a123a162fd3afa917d727b2ad9a86b32eac510ea39263f84f94f13b5a (AngularJS)
D2b82e612d2a812e8be2a57300dab8923c4f2edbe7a799e7da70791b595646fe (Modernizr)
Skimmer domains (on the websites we investigated):
cdn.pinnaclecart.io
static.zdassets.io
hal-data.org
app.iofrontcloud.com
mantisadnetwork.org
stage.sleefnote.com
js.speed-metrics.com
cdn.inspecltet.com
Sentry-cdn.io
Sources:
