Stealing Seconds: Web Skimmer Compromises Casio UK and Growing Number of Websites

with David Alves and Pedro Marrucho

We just uncovered a new batch of web skimmer infections affecting multiple websites, including casio.co.uk. So far, we have confirmed 17 victim websites, though this number will likely increase as our investigation continues. We are actively reaching out to the affected websites so they can take down the infections. For that reason, we are not disclosing the names of all victims' websites.

The web skimmer infections likely resulted from vulnerable components installed in Magento webstores, which has been one of the most common reasons when the victims are running on Magento or other similar software solutions.

One of the victims is the well-known electronics company Casio, namely their casio.co.uk website. In their case, we have determined that the infection became active between January 14th and 24th. We detected the threat on January 28th. We immediately contacted Casio UK, and in less than 24 hours, the infection had been removed.

The Casio.co.uk skimmer

The skimmer loader could be found right from the homepage and, untypically, did not use any obfuscation. It looks like an ordinary third-party script loader that uses an asynchronous script element and sets its source to the skimmer’s location. The script is then added to the page before the first existing script, and as soon as it gets loaded, it also removes itself from the page.

Stage 1 Loader

Skimmer running on casio.co.uk

Stage 2 Skimmer - Phase 1

While the initial loader was unobfuscated, the second-stage skimmer employed multiple layers of obfuscation, including:

• A custom encoding method that makes variables and strings different across victims. This particular technique has been used since at least 2022 by web-skimming threat actors. 

• An XOR-based string concealing technique - although not particularly resilient, this technique can be effective in defeating static analyzers and WAFs.

Typically, skimmers purposely limit their activity to the checkout section of victim websites, where users enter their personal and payment data. However, this attack deviated from that pattern, as the skimmer was active on all pages except the “/checkout” page.  

The reason for that odd behavior has to do with a change to the usual payment flow.  The threat actor expects users to first add items to their carts and then go to the cart page “/checkout/cart” to check out and pay. In the Cart page, the skimmer then captures clicks on the “checkout” button, and instead of the user being taken to the /checkout page, it is presented with a fake payment form using a model window, asking for their personal details. This is, at first, a seemingly unsuspicious 3-step form, with field validation and transitioning loading screens. 

In the first step, the user is asked to enter their email, country, first/last name, address, city, country, postcode, and phone number. When submitted, this first step will send an XHR GET request to postanywhere[.]net with a fraction of the inserted data sent as payload. In the second step, users will see some details on shipping costs and must click a “continue” button. In the last step, users are asked to insert their credit card number, name, expiration date, and CVV. There, a "Pay now" button fires a JavaScript alert message saying, “Please verify your billing information and try again”. After clicking OK, the skimmer triggers the exfiltration process and redirects users to the legitimate “/checkout” page, asking them to fill in the exact details again. This is known in the PCI DSS v4 world as a double-entry skimming attack.

3-step process of the skimmer payment flow

Error displayed to the user after entering the details on the fake form

One funny bit, though, is that if users click “buy now” instead of “add to basket”, the fake form is not injected, as it does not match the flow that the skimming code expects. This is a sign that web skimming threat actors do not spend much time perfecting their skimming flows. 

In the exfiltration process, the skimmer encrypts the captured data using AES-256-CBC. The encryption process generates a random IV and Key for each request. The encrypted data, Key, and IV are exfiltrated on the same XHR request to app[.]imagechat[.]net/n/.

The payload contains several sensitive data, including:

• Billing Address

• Credit Card Name

• Credit Card Number

• Credit Card Expiration Date

• Credit Card CVV Code

• Phone Number

• Email Address

  
  

Semi-deobfuscated code that gathers the collected data

POST request information exfiltrated

We used CyberChef to successfully decrypt the payload, using key (d), IV (t), and encrypted data (w) stored within the request.

Using CyberChef to decrypt a sample exfiltrated payload

It is also worth mentioning that the script exhibited a sophisticated evasion technique that caused it to not be returned by the skimming server in certain situations, which is in line with what the Jscrambler Research team has been observing in the last couple of years. 

Also potentially related to evasion, as mentioned before, the skimmer was not manifesting on the checkout section, which is the exact opposite of what we usually see in skimmers. Perhaps the threat actor thinks the checkout area is more likely to be scrutinized by monitoring tools than the rest of the website.

The Casio.co.uk Security Controls

Casio UK had a Content Security Policy (CSP) in place, but it was set to report-only mode (Content-Security-Policy-Report-Only) and was not configured to report back any violations (no report-uri or report-to directives). As a result, CSP violations were only logged in the browser console rather than actively preventing the attack.

Console CSP error report

Casio.co.uk’s CSP Header

Broader Skimming Campaign Insights

All the victims were loading a skimmer script from the same hosting provider in Russia. It was also observed that even though the skimming domains could differ between victims, the skimmer code itself (the generic part) was, on various occasions, pretty similar, suggesting that they could’ve been created by the same web skimming generation tool whether that means that the activity is coming from a single web skimming threat actor or not, that can not be concluded yet. 

Another interesting fact we noticed was that some of the domains used to host the campaign skimmers were recently registered, but we can see historical records going back many years. For example, the domain imagechat[.]net has records from 16 years ago, confirming that threat actors have been leveraging the reputation of old defunct domains. To check your site for Defunct Domains, you can use this free tool built by Jscrambler’s research team.

Conclusion

The casio.co.uk skimming incident attests that although Content Security Policy (CSP) is a relatively simple standard, it’s often considered hard to manage. It is easy to make mistakes, which often leads to companies opting for a report only over blocking, which also takes away a significant portion of the benefit. Companies are also burdened with the need to build internal tools around CSP and CSP reporting, which takes time and effort, so many do not. The other option is to use a solution that fully automates script security and management, such as Jscrambler’s Webpage Integrity.

In the case of the casio.co.uk infection, the threat actor altered the payment flow in a very visible way. The UI changes, especially the error that was being displayed and the fact that the user is asked to input the payment details twice should really be a good indicator for most people to suspect that something might be wrong. However, the fact that threat actors continue to do it in a seemingly sloppy way is a good indicator that most end users are not able to tell that they are being attacked and, therefore, are not sounding the alarm.

In the last couple of years, these Magecart infections became really common, with smaller merchants being the main targets. Counting on end users to sound the alarm is not only bad for several reasons, but it’s also ineffective. Half-baked homegrown solutions like CSP have also been ineffective. Hence, deploying easy-to-use, quickly deployable website monitoring solutions to detect and remove infections is paramount. It keeps payment data safe, users’ personal data secure, and the organization's reputation preserved.

Indicators of Compromise (IOCs): Malicious Domains