How Client-Side Protection & Compliance Detects Real—World Magecart Attacks
Magecart is the name given to a number of criminal groups targeting a variety of online businesses, mainly e-commerce, with the goal of harvesting sensitive end-user information from browsers (e.g., skimming credit card data from buyers at the checkout page). In a Magecart attack, malicious JavaScript code is injected through one of the site vendors' scripts or through the company's first-party assets, usually by identifying and leveraging a specific vulnerability that allows the attacker to alter the website resources before the traffic reaches end-user browsers.
Let’s take a closer look at and break down a recent Magecart attack detected and mitigated by Akamai’s Client-side Protection & Compliance. The impacted customer operates a large international e-commerce business in which one of its websites was compromised with a malicious script.
The origin
The attack we detected was a first-party JavaScript injection, embedded as an inline script tag in the index HTML page. It is unclear exactly how the attackers managed to infiltrate the first-party environment and sneak their skimmer inside the website. The breach could be the result of a compromised insider or development pipeline, or an exploited vulnerability, such as obtaining remote code execution (RCE) or overwriting a lightly secured file.
All users visiting the website were exposed to this script, but it was only effective on specific pages -- the mobile checkout form and one of the web checkout forms.
The attack used string manipulation techniques to try to evade reflection detection of sensitive data by employing a UTF-16 charcode shift cipher algorithm, swapping letters with a corresponding UTF-16 code representation and 10-place rotation. As an example, with the shift cipher method described above, the string "a" which has a UTF-16 charcode of 97, would be represented as 107 in the payload sent to the C2 server.
The malicious skimmer code found on the customer website
The attacker's C2 server used a name very similar to the brand name of our compromised customer, with a different top-level domain. This is a common characteristic of this type of attack and a good way to evade the human eye, since the domain looks legitimate.
The detection
In the checkout page, when a user submitted the payment form, the injected JavaScript attack attempted to read all of the form inputs (credit card number, cardholder name, cvv, expiration date), apply the cipher algorithm described above, and send it to the C2 server.
Client-side Protection & Compliance observed the described behavior and raised it as a "Suspected Web Skimming" attempt.
Client-side Protection & Compliance: incident report overview
In the incident detection report, we displayed the script behavior chain highlights, which break down the malicious code execution behavior detected by Client-side Protection & Compliance, after running it through a series of classifiers, detectors, and AI models. The events that the AI models found as anomalous were given an "Unusual Activity" tag, indicating they were not expected in this code execution context based on observed historical application data.
Zooming into the summary, it is clear that the anomalous events were of type "Read from sensitive data" and "Sent outbound traffic" -- indicating that there was an anomaly in reading values from sensitive fields (e.g., obtaining the values of the credit card input) and there were unexpected network requests.
Script Behavior Chain: showing highlights from the tree representation of code execution events collected from the page
Furthermore, Client-side Protection & Compliance also provided information about the individual user sessions that were affected by the incident, to better track and understand impact.
Incident report: affected session log
Incident report: affected session over time
The action
The customer immediately received an automated alert with detailed information to understand the suspicious behavior, and the customer's web team double-confirmed that the suspicious activity did not belong to them. This prompted the customer to take action. It applied an Incident Response policy, one of Client-side Protection & Compliance's core features, to protect realuser browser sessions from contacting the attacker's C2 server in real time, which prevented sensitive data from being exfiltrated from end-user browsers. This happened in parallel to the customer updating its app to no longer include the malicious script.
Incident action taken: "Deny outbound traffic"
The lesson
This Magecart attack is a typical example of what Client-side Protection & Compliance can identify, flag, and resolve quickly. By having always-on, always-detecting monitoring and alerting, our customer was able to see a zero-day event, and understand and mitigate it in minutes. In addition, creating a policy based on detected suspicious behavior with a single button press alleviates delays and heavy security team workloads.
Magecart continues to be an active threat vector that targets e-commerce companies of all sizes -- some use via generic skimmer code while others employ very targeted and tailored skimmers such as the above example. And these attacks are not isolated to third-party hostnames and services -- malicious scripts can impact your real users from both first-party and third-party assets.
To minimize the impact of threats like Magecart, in-browser protection needs to be an integral part of any business with a significant online presence. Learn more about Client-side Protection & Compliance.
