A New Batch of Web Skimming Attacks

Research Authors | Pedro Fortuna, Pedro Marrucho, and David Alves

UPDATE | Since this blog post’s original publication, the research team has found 343 additional victims of this skimming attack.

In the last few years, Magecart, or Web Skimming Attacks, have become common. They operate in campaigns, trying to hit as many targets as possible. We’ve seen the modus operandi evolve as cybercriminal groups search for inventive ways to compromise targets. Over the past week, we observed a new modus operandi across three threat groups. We will discuss the findings in detail.

Our discovery of this web skimming attack underscores the importance of practicing good client-side security hygiene. Most web applications are complex mashups of elements that leverage code from the web supply chain.

Most security teams don’t have visibility into the third-party code running on their website; they don’t know whether it’s behaving as expected or misbehaving, accidentally or maliciously. This security blind spot can create a false sense of confidence in your risk assessment.

It’s hard to measure what you can’t see.

Web Skimmer Operation number 1: Group X

Modus Operandi

This first Web skimmer operation we discovered uses a method we haven’t seen before. The cybercriminals exploited a third-party JavaScript library called Cockpit, a free web marketing and analytics service that was discontinued in December 2014 (See Figure A).

They acquired the domain name that hosted the library and used it to serve a skimming script via the same URL. By re-registering the defunct domain and configuring it to distribute malicious code, the attackers compromised over 40 e-commerce websites.

The attackers encoded and encrypted data collected from the sites, then sent it to an exfiltration server based in Russia.

The impacted websites had not removed the script from their pages, even though Cockpit issued an end-of-service notice years ago. This is not uncommon. Many sites don’t remove deprecated libraries, which can lead to dead links that are easy to compromise because of limited visibility or poor security practices.

The graphic below shows how this third-party library is usually included on a website. It’s a script that loads the main Cockpit script.

The contents of the loaded script depend on the referrer header value, i.e., the webpage from which it is fetched.

We observed that different scripts are returned depending on the referrer. This is common behavior for web skimmers, which try to load malicious code only when necessary, making it harder to detect.

Third-party integration on the homepage

The Skimmer

Different scripts are loaded depending on the referrer. If the script is requested without a referrer header, it returns no script (empty response). For unknown referrers, a default skimmer is served. For a specific referrer, the attacker loads a specific skimmer. It can be summarized as follows:

No referrer: no script
Unknown referrer: default skimmer
Specific referrer: specific skimmer

Although the domain “tracker.web-cockpit.jp” currently returns an empty page, we can see that the file “favicon.ico” contains a copy of one of the skimmers.

The default skimmer

The default skimmer, which is loaded for unknown referrers, looks like a typical Web skimmer with a few distinct aspects.

When the page finishes loading, the skimmer will only run on two specific web pages: the order and register web pages. This is done by checking the page location through document.location.href, as shown in the snippet below (Figure B):

Page location checks for the order and register pages
Figure B: Page location checks for the order and register pages

If the page location checks are successful, then the skimming code is executed following the typical data exfiltration flow. The skimmer grabs any input, select, and textarea elements on the page that are not hidden or empty.

This data is then encoded and encrypted and sent to an exfiltration server based in Russia (see Figure C).

Figure C: Sample of input collection and data exfiltration methods

However, the skimmer doesn’t end here. After exfiltrating the web page’s original elements, it injects its own fake elements by mimicking a credit card submission form (Figure D).

Any data the user enters will continue to be gathered and leaked every time the user clicks on the page.

Injected fake credit card submission form

Figure D: Injected fake credit card submission form

The skimmer uses two cookies to control its operations. The first cookie, named “lastva1ue”, stores the last chunk of data that was exfiltrated and is checked to prevent sending the same data repeatedly to the exfiltration server. The second cookie, named “ga_csrf” is set when the fake elements are added to the page and is checked not to add duplicate elements.

The specific skimmer

We confirmed that some websites did not receive the default skimmer we described earlier, but rather a custom version of a fake Google Analytics (GA) integration (Figure E). This custom version is very similar to the legitimate script. However, the use of Base64-encoded strings caught our attention because the legitimate GA script doesn’t use them. Additionally, the legitimate GA URL we can see in the malicious version is never used and only serves as a disguise.

Sample of the specific skimmer

Figure E: A Sample of the specific skimmer

In this case, requesting the skimmer with a valid referrer is not enough. The referrer must match the associated infected site for the correct skimmer to be served; otherwise, you get a script that looks benign (Figure F).

Sample of the benign version of the skimmer

Figure F: A Sample of the benign version of the skimmer

If the referrer header actually matches the correct infected website, the skimmer is served. Not all victims received the same script.

We found at least three different versions, but the differences between them are simple. Some targeted only the checkout page; others sought additional targets.

Encryption for the exfiltration process was a distinctive factor, since not all scripts implemented it. Although the exfiltration server used a different domain, it was hosted on the same IP address we saw before.

The skimmer stored the unciphered data in a cookie named “phpssidcache”, with simple Base64 encoding (Figure G). This way, it can check what data was sent and prevent duplicates.

Sample of the stored cookie

Figure G: A Sample of the stored cookie

Once again, this cookie is encoded using Base64. If we decode it we can see all the pieces of information that the skimmer has been gathering and storing. In the table below (Figure H), we present a few of them:

Sample of the Type B skimmer data stored/exfiltrated

Figure H: Sample of the Type B skimmer data stored/exfiltrated

One e-commerce site knew the third-party script was compromised. Instead of removing it, they added a small notice to the payment page (Figure I):

Tampering warning from the vendor and fake form below

Figure I: Tampering warning from the vendor and fake form below

It is obvious that this skimmer is not designed specifically for this page, but rather a generic version that makes it more flexible. But in some cases, it may alert users that something is wrong because it injects the fake credit card form on pages that shouldn’t have one, such as pages where the user chose “Bank transfer” or “PayPal”.

Some sites may also use a website generator service or a Content Management System (CMS) that injects the third-party script into their pages. In that case, they might be unable to remove the library from their websites due to restricted permissions or a lack of knowledge.