A New Skimmer Uses WebSockets and a Fake Credit Card Form to Steal Sensitive Data
A new skimmer attack was discovered this week, targeting various online e-commerce sites built with different frameworks. As I write this blog post, the attack is still active and exfiltrating data.
Attackers are exploiting an expanding in-browser attack surface and continually evolving web skimming techniques. This attack implements many sophisticated capabilities, which we don't usually see among skimmers attacks.
Online stores are increasingly outsourcing their payment processes to third-party vendors, which means that they don't handle credit card data inside their store. To overcome this, the attacker creates a fake credit card form and injects it into the application's checkout page. The exfiltration itself is done by WebSockets, which provide the attacker a more silent exfiltration path.
Attack overview
[!] The following information is publicly available and hence spreading. By providing high-level detail of this new attack method, Akamai encourages website owners and security teams to be aware of the problem characteristics and has provided insights on how to defeat this specific attack.
The skimmer injects a loader into the page source as an inline script. Once executed, a malicious JavaScript file is requested from the skimmer's command and control (C2) server at:
https[:]//tags-manager[.]com/gtags/script2
The skimmer loader is injected into the targeted store
When the external script is loaded, the skimmer stores in the browser's LocalStorage its generated session-id and the client IP address. Those parameters are sent as part of the data exfiltration later in the session.
The skimmer saves the session ID and the user IP in the browser local storage
The actual malicious behavior of the skimmer occurs, of course, in the application sensitive pages, such as the checkout, login, or new account registration pages. The skimmer checks the page URL in order to decide whether it runs on a sensitive page.
Once loaded in a sensitive page, the skimmer initiates a WebSocket connection with its C2 server.
The skimmer checks whether it runs in a sensitive page
After that, the skimmer registers new event listeners on all the input, form, and button elements in the page. Once fired, the skimmer maps the input field values and exfiltrates them using its opened WebSocket connection to the C2 server.
The skimmer serializes and exfiltrates the user's information
New abilities and mechanisms
The attacker implemented some sophisticated mechanisms, which we don't usually see among web skimmers, noted here as attack insight.
Data exfiltration using WebSockets. Unlike other skimmer attacks, which mostly exfiltrate the data using XHR requests or HTML tags, this skimmer exfiltrates users' sensitive information via WebSockets. Once the skimmer is loaded in the target page, it initializes a WebSocket communication with its C2 server and keeps it open by sending ping sockets in intervals.
The skimmer tracks the sensitive input fields in the targeted page and sends their values for every change occurring in their content.
The usage of WebSockets provides the attacker a better hiding mechanism as the requests that are being sent will be more "silent." Also, a content security policy (CSP) limiting WebSockets usage is often not in place.
WebSockets communication with the skimmer's C2 server
Fake credit card form. Some of the targeted stores don't handle the payment process by themselves, but use a third-party provider to handle the payment process. In that case, once users fill in personal information, they are redirected to the third-party vendor in order to provide credit card information and complete the transaction. The skimmer will not be able to inject itself into the third-party vendor to get the end-user credit card information.
For this case, the skimmer creates a fake credit card form in the page before it is redirected to the third-party vendor. The form even validates the user input and credit card information and shows the user relevant error messages. Once that user clicks on the fake "Pay" button, the skimmer shows a message that the payment cannot be processed and lets the user continue with the real flow of the application.
The fake form that the skimmer creates in the page
In summary, the evasion and obfuscation attempts by the skimmer present a level of sophistication and evolution of such malware strains. We see this escalation as a growing trend among adversaries that are always willing to advance their tactics to gain as much as they can from their campaigns and continue as long as possible before detection.
Detecting and preventing skimmer attacks
Akamai sees new and subtly modified web application client-side attacks, such as this example, on nearly a weekly basis. Given the obfuscated nature and supply chain origination of in-browser attacks, traditional CSP-reliant approaches miss most of these types of attacks.
Our security portfolio has embraced and invested in bringing to market a web skimming protection product called Client-Side Protection & Compliance, which focuses on the script execution behavior with unprecedented visibility into the runtime environment. It collects information about the different scripts that run in the web page, each action they take, and their relation to other scripts in the page. Pairing this data with our multilayered detection approach -- leveraging heuristics, risk scoring, artificial intelligence (AI), and other factors -- allows Client-Side Protection & Compliance to detect different types of client-side attacks, with a high focus on data exfiltration and web skimming attacks.
This particular attack using WebSockets and fake credit card pages has been tested against Client-Side Protection & Compliance; it was immediately recognized, and detailed information for troubleshooting was provided for effective mitigation.
To identify if your organization has been targeted, indicators of compromise follow:
Domains
tags-manager[.]com
URLs
https[:]//tags-manager[.]com/gtags/script2?utm_referer=[variable]utm_source=[variable]&utm_content=[variable]&utm_referer [MD5=191ed582a2ba6294f15fe5475e1908ee]
wss[:]//tags-manager[.]com/compare
