Someone’s Going to Have a Good Christmas


$124.4B is projected in online purchases this holiday season, according to commerce site shopify[.]com. Millions of online transactions will occur between now and December 25th. How secure do you feel entering your credit or debit cards into the payment portals. We all get a sense of security with the HTTPS and the “secure transaction” wording in the check out carts, but does that offer 100% protection to the consumer. Anomali Labs researchers have discovered web stores that have been compromised by an unknown threat actor, possibly Magecart, where the website has been modified to include JavaScript code that steals credit card information. The JavaScript code shows up in two forms, one that beacons out to g-analytics[.]com and the other to jquery-js[.]com. The threat actor is using a form of typosquatting to camouflage the command and control (C2) domains by using domains similar to well-known domains such as google-analytics[.]com and jquery[.]com. The code has been present on the sites for approximately five months and has silently been siphoning off stolen credit card details. At the time of this writing, this campaign is currently ongoing. The compromised sites are small but high-end stores offering goods at a premium price.

The Magecart threat groups have been highly active in 2018, and they have been attributed to multiple data breaches and information-theft incidents. Some of these breaches affected large and well-known companies. In late June 2018, the ticket sales company Ticketmaster stated publicly that it had been compromised by threat actors. The threat actors turned out to be Magecart, according to RiskIQ researchers. Magecart targeted a Ticketmaster subdomain (hosted by third-party supplier Inbenta) and injected it with a JavaScript module, among other activity, to conduct payment skimming activity.[1] On September 6, 2018, British Airways confirmed that it had suffered a data breach in which a threat group (Magecart) stole payment information from the company’s main website and mobile application by using a modified “Modernizr JavaScript” library (version 2.6.2).[2] Another company attacked by Magecart was Newegg, who had its website compromised with a skimmer, similar to the one found in the British Airways incident, and sent the stolen data to an actor-registered domain (neweggstats[.]com, later changed to; the skimmer was located on Newegg’s payment processing page.[3] These campaigns offer some insight as to how Magecart operates, and it is with these tactics in mind that Anomali Labs researchers believe with medium confidence that this campaign is being conducted by a Magecart group.

Threat actors are consistently looking for ways to steal valuable information that can be sold for a profit, or used illicitly to steal funds. One way an actor can accomplish this kind of malicious activity is via an SQL injection attack to gain unauthorized access to information stored in a database, however, this approach has some limitations. Foremost, it is only possible to steal the data from customers that have selected the option to store their payment information. Secondly, as per the Payment Card Industry Data Security Standard (PCI DSS) standard CVV values are not allowed to be stored. This standard makes it difficult for a threat actor to use the stolen credit card data because some merchants require the CVV to make a purchase. A way for a threat actor to get card data with an associated CVV number is by compromising the webstore and add code to the checkout page to steal the information and send it off to the threat actor just before it is submitted to the server. For example, the threat actor can inject some HTML code to the page that loads malicious JavaScript from another server. The JavaScript waits for a particular request to occur, and once the correct event has fired, the code grabs the data that is about to be submitted to the store and sends it off to a server controlled by the threat actor. This type of compromise can be challenging to detect because it all occurs in the customer’s browser and not on computers controlled by the compromised company. Therefore, it is possible that the site stays compromised for months without detection.

Compromised websites
According to an internet-wide survey, websites have been compromised and served the malicious JavaScript as far as back as 23 June, 2018. Additional information regarding the compromised websites can be viewed by ThreatStream users here.

The domain “g-analytics[.]com” was registered at NameCheap on 31 May, 2018. The domain tries to impersonate the domain used by Google for serving Google Analytics (google-analytics[.]com). If a visitor navigates to the g-analytics[.]com site, he/she is redirected to the real Google Analytics site, making the domain appear more legitimate. The response header from the server is shown below:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.6.2
Date: Mon, 19 Nov 2018 10:55:59 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Location: https[:]//analytics[.]google[.]com/

The server is used to host JavaScript, “analytics.js”, that is served to visitors of the compromised sites. The threat actor has actively been updating the script file since June 2018 with new versions. The versions of the script and the last modified timestamp given by the server are shown in Table 1 below.

Table 1: Table of versions of analytic.js and their last modified timestamp given by the server.

“Analytics.js” is an obfuscated Javascript file that exfiltrates payment details from compromised websites with payment portals. The file pretends to be a “Google Analytics” file named “analytics.js”. Multiple different versions of this file have been observed.

Technical breakdown
The file is obfuscated by taking out all strings, and some function names and placing them inside an obfuscated string. The string is copied into a character array and subject to a number of decoding operations which dumps out a string array, as shown in Figure 1.

Figure 1: String array deobfuscation

A number of helper functions are initialised and returned in an associative array to a variable named “GoogleAnalytics”. Another round of decoding on a large string is performed, which creates another string array for the obfuscated code. The file uses the popular JavaScript library “jQuery” to wait for a user to click a button that is under the element, class, or ID of the following:

  • .button
  • .form-button
  • .onestepcheckout-button
  • .btn
  • #onestepcheckout-place-order
  • onestepcheckout-place-order
  • .onestepcheckout-place-order-wrapper

The script grabs the URL and uses a regular expression test to ensure the page is either a login page or purchase related page by matching the pattern below. Figure 2 shows the check in the code.


Figure 2: Regular Expression check

If this test returns true, it uses the function “document.querySelectorAll()” in a loop to grab all the elements that are under the following selectors: input, select, textarea, checkbox.

It checks to see if there is any value input into the field. If a value is there, it grabs the “name” HTML attribute of the element. If there is no name attribute, the script will retrieve the count number of the loop that it is currently in to use as the name. This name is used to append to the end of a string in the following format:

param_string += [element_name] + ‘=‘ + [element_value] + “&”

The script will also save the value using HTML5 local storage, as shown in Figure 3.

Figure 3: Storing the value of all filled in fields.

It checks the local storage to see if it was able to obtain a field named “gaudid”. This is a unique identifier for the client that is shopping on the compromised website. If there is no ID number it will generate a unique ID for the victim, as shown in Figure 4.

Figure 4 - Unique ID check and generation

The script then specifically looks for a local storage variable called “infoResult”. If found it will be prepended to the start of the exfiltrated data. The script begins to create its asynchronous HTTP POST request. It creates a regular expression with the following pattern to test for card numbers:


If the test returns true it sets a flag in the exfiltrated data. The data is then encrypted and encoded with Base64. It is placed in the post data after the field “track”, as shown in Figure 5.

Figure 5: Exfiltration of collected data to the C2

An example of the data before encryption is shown in Figure 6.

Figure 6: Fetched fields before encryption

The POST request attempts to mimic the style of legitimate Google Analytics’s URL query parameters and request path. The similar request path can be seen in Figure 7. Also shown is the legitimate Google Analytics request. Note the difference in the method used and the protocol.

Figure 7: Network requests showing both legitimate and fake Google Analytics requests

The domain “jquery-js[.]com” was registered on NameCheap on 2 January, 2017. It similar to g-analytics[.]com in the way that it is impersonating a legitimate site. Users browsing to the site is redirected to the legitimate site for jquery as can be seen below.

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.6.2
Date: Tue, 20 Nov 2018 09:57:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Location: https[:]//jquery[.]com/

The domain is used to host the JavaScript file “jquery.min.js”. According to data provided by the web server, the file was last modified on 7 January, 2017.

“jquery-min.js” is an obfuscated Javascript file that operates in a similar way to “analytics.js”. Skimming payment details from compromised websites with payment portals. The file pretends to be a “jQuery” file.

Technical breakdown
The file is heavily obfuscated JavaScript that pretends to be a minified jQuery file. The script has a large comment block at the start of the file that is code from the legitimate version of jQuery. This is intended to hide the malicious code appended below it, as shown in Figure 8.

Figure 8 - Malicious file with comment block mimicking jQuery

The script decodes and evaluates a large string that contains more JavaScript code. After the first round of decoding the following script is evaluated, Figure 9.

Figure 9 - Second decoding script

This script decodes and evaluates another string, which is the final malicious script, that performs skimming of shopper details. The malicious script and its deobfuscated version are shown in Figures 10 & 11.

Figure 10 - Malicious skimming script

Figure 11 - Deobfuscated version of the script

The script acts much in the same way as “analytics.js”. It will check that the user is on a payment page and scrape all values filled into input elements in the form. The data is sent to the C2 server over asynchronous HTTP POST in plaintext.

If you have bought something from these sites, consider canceling your credit or bank card and request a new issued from your credit card company and carefully monitor your transactions list for potential malicious activity. Paying via a trusted third-party application, such as Apple/Google Pay, PayPal, Visa Checkout, can reduce the likelihood of your banking and payment information being stolen with this malicious script. Making payments through a third-party portal reduces the likelihood of inputted card details being scraped from the form of the compromised site.