by chebbi abir

A new skimmer attack was discovered this week, targeting various online e-commerce sites built with different frameworks. As of the writing of 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 uses a Cloudflare API in order to get the end-user IP address.


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, which are noted here as attack insight.

  • Data exfiltration using WebSockets. Unlike other skimmers attacks, which mostly exfiltrate the data using XHR requests or HTML tags, this skimmer exfiltrates the 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 lot of CSP policies don’t limit WebSockets usage.


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 the user completes filling in his personal information, he is 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 the credit card information and shows the user relevant error messages. Once the 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 that 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 to sustain it as long as they can 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 Page Integrity Manager, 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, AI, and other factors — allows Page Integrity Manager 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 Page Integrity Manager; it was immediately recognized, and detailed information for troubleshooting was provided for effective mitigation.


To read the original article:



Interdit de copier  ce contenu