Defcon Skimming: A new batch of Web Skimming attacks

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

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

In the last few years, we’ve seen Magecart or Web Skimming Attacks become common. They operate in campaigns, trying to hit as many targets as possible. We’ve seen the modus operandi change or evolve as cybercriminal groups search for inventive ways of compromising targets. In the past week, we observed a new modus operandi evident in 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 this third-party code running on their website; they don’t know if it’s behaving as it should or misbehaving, whether accidentally or maliciously. This security blind spot can create a false sense of confidence in your assessment of risk.

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

Web Skimmer Operation number 1: Group X

Modus Operandi

This first Web skimmer operation that we discovered uses a method that we have not 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 were able to compromise over 40 e-commerce websites.

Data collected from the sites was encoded, encrypted, and then sent 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 may lead to dead links that can be easily compromised due to a lack of visibility or poor security practices.

The below graphic contains a snippet of 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 a common behavior of web skimmers in an attempt to only load the malicious code strictly when necessary, thus making it harder to detect.

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

Even though the domain “tracker.web-cockpit.jp” returns an empty page at the moment, 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 page. This is done by checking the page location through document.location.href, as shown in the snippet below (Figure B):

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. Upon exfiltrating the data of the web page’s original elements, it then injects its own fake elements by mimicking a credit card submission form (Figure D).

Any data inserted by the user will continue to be gathered and leaked every time there is a click on the page.

Figure D: Injected fake credit card submission form

The skimmer uses two cookies to control the status of 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 usage of Base64 encoded strings caught our attention because this doesn’t occur in the legitimate GA script. Additionally, the legitimate GA URL we can see in the malicious version is never used and only serves as a disguise.

Figure E: A Sample of the specific skimmer

In this case, if you want to request the skimmer, having a valid referrer is not enough. The referrer needs to match the associated infected site for the correct skimmer to be served, or else you will be given a script that looks benign (Figure F).

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 were provided with the same script.

We found at least three different versions, but the differences between them are simple. Some were just targeting the checkout page; others were seeking additional targets.

The use of encryption for the exfiltration process was a distinctive factor since not all scripts had it implemented. The exfiltration server, although under a different domain, was hosted by the same IP address as the one we saw before.

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

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:

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

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

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 the users that something is wrong since it will inject the fake credit card form in pages that should not have one, such as pages where the user chose the methods “Bank transfer” or “PayPal”.

There is also the possibility that some sites were using a website generator service or a Content Management System (CMS) that was injecting 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.

Web Skimmer Operation number 2: Group Y

Modus Operandi

The second skimmer we found, identified as Group Y, is very similar to Group X, although the distribution method is quite different.

Instead of attacking a third-party service, it attacks each victim individually, injecting the Google Analytics lookalike script into their home pages. This time, the location check is made from within the loader script rather than the skimmer itself, meaning that the skimmer code is only loaded if its loader is running on the checkout page.

The snippet below illustrates the content of the loader script (Figure J). Note that the legit Google Analytics script contains a string named 'GoogleAnalyticsObject' and not 'GoogleAnalyticsObjects', which is easily overlooked.

Figure J: Sample of the injected script

We can speculate that this less scalable version could have appeared first and that Group X evolved from it since they share a few similarities.

The Skimmer

The first malicious script is almost identical to the “specific skimmer” we described before, but instead of being in a third-party script, it appears injected into each victim’s web pages.

It’s another custom version of a fake Google Analytics integration. We immediately spot the similarities with the other version we discussed before:

• Also contains Base64-encoded strings and uses atob()

• Also shows off the legitimate Google Analytics URL but does not use it

• Also injects a new script when the user reaches the checkout page
  

As major differences, we see that the anonymous function can now receive up to 8 arguments, and regular expressions were introduced, which change the way the current page URL is checked.

When it loads on the checkout page, it will fetch the next stage, the skimmer itself, which is set to steal all accessible information and inject a malicious iframe for the payment details (figure K). Exfiltration occurs to a different endpoint under the same domain.

Figure K: Sample of the injected iframe

Web Skimmer Operation number 3: Group Z

Modus Operandi

The third group, called Z, appears to take advantage of the same methodology used by Group Y and Group X in terms of the skimmer, but we can see some modifications in how the script structure and server structure operate.

The modifications to the script structures can be seen in the 1st and 2nd stage phases.

The first stage refers to the injection of a malicious Javascript initiator that is disguised as Google Tag Manager in the pages, a similar approach to the methodology of Group Y and Group X. The deviation here is the implementation of string concatenation in an attempt to avoid detection.

Stage 2 also has some modifications in the server structure, where the Skimmer URLs follow a different pattern from the other two groups. Here they identify the service used to disguise, and the script file contains the name of the target website. Another difference is how the script is constructed; it’s not in cleartext, and it uses a layer of obfuscation to hamper the readability of the script.

The Skimmer

In these campaigns, the group targets websites directly and injects a similar initiator malicious script as the one used by Group Y (Figure L).

Figure L: Sample of the initiator script

The sample image shows a malicious payload disguised as Google Analytics. It is similar to the versions exposed by Groups X and Y with the exception of the implementation of a string concatenation layer, [‘Google’+’Analytics’+’Objects’].

The main difference between them is apparent when we analyze the next stages.

We can see that the skimmer code has undergone some serious changes. Some modifications were made to the server structure, where the Skimmer URLs follow a different pattern from the other two groups.

Here they identify the service used to disguise it, and the script file contains the name of the target website (Figure M).

• https://{{STAGE2_DOMAIN}}/www.google-analytics.com/{{TARGETED_WEBSITE}}
  
  

Figure M: Sample of the obfuscated, beautified, and redacted skimmer

As we can see, the script makes use of obfuscation techniques to hamper its readability (Figure M).

Figure N: Sample of the deobfuscated skimmer

After reversing the obfuscation, we can identify the behaviors of the skimmer, one of those behaviors is the injection of a new form (Figure O) into the page to steal customers' information. The form style can vary according to the page where it’s injected. It was also possible to identify the presence of the legitimate form on the page.

Figure O: Example of the form injected into the page

The deobfuscated code also informs us of the use of two exfiltration domains that are used simultaneously to collect the information (Figure P):

• gxmod[.]pics/g.php

• gymorning[.]cyou/g.php
  
  

Figure P: Example of the Exfiltration Data

The exfiltrated data contains information like:

• The domain where the skimmer was collecting information - {{TARGETED_DOMAIN}}

• Payment Card Industry (PCI) data - {{CC_NUMBER}},{{CVV}}, {{EXPIRE_DATE}}

• Personally identifiable information (PII) - {{NAME}},{{CVV}}, {{ADDRESS}},

The image below shows how the collected information is structured (Figure Q).

Figure Q: Exfiltration JSON Skeleton

Conclusion

The Jscrambler research team uncovered a new technique that attackers are using to get more targets: getting control of defunct domains that formerly hosted popular JavaScript libraries. In the observed campaign, attackers managed to get control of a library and target e-commerce websites.

We don’t know if the attackers had a special interest in these websites. Magecart cybercriminal groups mostly care about getting more payment data leaked.

The victim websites had years to remove the dead link that was leveraged by attackers but didn’t, likely due to a lack of visibility about third-party scripts running on their websites and poor security hygiene.

Magecart groups will keep finding new and creative ways to get malicious code running on e-commerce websites. Merchants need a proactive defense to protect their customers. This includes real-time, automated monitoring of scripts and setting risk policies to greatly limit what scripts can do. Jscrambler’s Webpage Integrity allows website owners to do that in an easy and scalable way.

Indicators of Compromise (IOCs): Malicious Domains

• tracker.web-cockpit[.]jp  193.3.19.36 - SELECTEL-MSK (Russia)

• passenger210[.]bar  193.3.19.36 - SELECTEL-MSK (Russia)

• bus527[.]cfd  193.3.19.36 - SELECTEL-MSK (Russia)

• follow707[.]cloud  193.3.19.36 - SELECTEL-MSK (Russia)

• war740[.]engineer  193.3.19.36 - SELECTEL-MSK (Russia)

• block714[.]mobi  193.3.19.36 - SELECTEL-MSK (Russia)

• bind853[.]me  193.3.19.36 - SELECTEL-MSK (Russia)

• temple321[.]bar  193.3.19.36 - SELECTEL-MSK (Russia)

• earn454[.]live  193.3.19.36 - SELECTEL-MSK (Russia)

• heavy689[.]immo  193.3.19.36 - SELECTEL-MSK (Russia)

• door111[.]network  193.3.19.36 - SELECTEL-MSK (Russia)

• blind227[.]boutique  193.3.19.36 - SELECTEL-MSK (Russia)

• salt204[.]me  193.3.19.36 - SELECTEL-MSK (Russia)

• dig159[.]digital  193.3.19.36 - SELECTEL-MSK (Russia)

• gymorning[.]cyou  5.188.62.10 - PINDC-AS (Russia)

• hovr[.]monster  5.188.62.10 - PINDC-AS (Russia)

• strimmr[.]buzz  5.188.62.10 - PINDC-AS (Russia)

• lynxer[.]monster  5.188.62.10 - PINDC-AS (Russia)

• 7raven[.]uno  5.188.62.10 - PINDC-AS (Russia)

• 2blu[.]cloud  5.188.62.10 - PINDC-AS (Russia)

• depth305[.]digital  5.188.62.10 - PINDC-AS (Russia)

• slavery588[.]biz  5.188.62.10 - PINDC-AS (Russia)

• reduction925[.]cc  5.188.62.10 - PINDC-AS (Russia)

• supper728[.]gifts  5.188.62.10 - PINDC-AS (Russia)

• mn-vps[.]art  194.169.218.49 - CENTRALNIC LTD (United Kingdom)

• literature539[.]space  194.169.218.51 - CENTRALNIC LTD (United Kingdom)

• gxmod[.]pics  141.98.82.244 - FLYSERVERS-ASN (Panama)