Is Magecart Checking Out Your Secure Online Transactions?

November 21, 2018 | Anomali Labs

With Online Holiday Sales Projected at $123B: How Secure are Your Transactions?

There is a projected $123B 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 actions, 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 217.23.4.11); 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 adding 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, Anomali Labs have detected at least 31 websites that have been compromised and served the malicious JavaScript as far as back as the 23rd of June, 2018. The sites were compromised to load JavaScript hosted on the domain “g-analytics[.]com”. The code injected looks very similar to legitimate Google Analytics code that is used to evade detection if a developer audits the code. Figure 1 shows the legitimate Google Analytics code on a compromised host and Figure 2 shows the injected malicious code.

g-analytics.com

The domain “g-analytics[.]com” was registered at NameCheap on the 31st of 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:

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.

Version

Last Modified Timestamp

1.0.1

Sat, 23 Jun 2018 02:47:00 GMT

1.0.3

Wed, 27 Jun 2018 04:25:33 GMT

1.0.4

Wed, 27 Jun 2018 11:06:48 GMT

1.0.5

Thu, 28 Jun 2018 17:25:25 GMT

1.0.6

Thu, 28 Jun 2018 15:11:47 GMT

1.0.7

Thu, 28 Jun 2018 16:03:46 GMT

1.0.8

Tue, 02 Oct 2018 13:59:59 GMT

1.0.9

Mon, 02 Jul 2018 06:51:07 GMT

1.0.10

Thu, 05 Jul 2018 05:29:44 GMT

1.0.11

Wed, 04 Jul 2018 15:41:58 GMT

1.0.12

Thu, 05 Jul 2018 07:43:21 GMT

1.0.13

Sat, 07 Jul 2018 12:27:40 GMT

1.0.14

Sat, 07 Jul 2018 03:58:37 GMT

1.0.15

Tue, 10 Jul 2018 09:44:23 GMT

1.0.16

Sat, 03 Nov 2018 16:00:19 GMT

1.0.17

Mon, 05 Nov 2018 11:02:11 GMT

1.0.18

Tue, 06 Nov 2018 14:30:54 GMT

1.0.19

Wed, 07 Nov 2018 13:02:37 GMT

1.0.20

Thu, 08 Nov 2018 04:23:06 GMT

1.0.21

Tue, 13 Nov 2018 14:14:21 GMT

1.0.22

Tue, 13 Nov 2018 14:05:59 GMT

1.0.23

Tue, 13 Nov 2018 14:04:30 GMT

1.0.24

Tue, 13 Nov 2018 13:35:32 GM

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

analytics.js

“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 3.

Figure 3: String array deobfuscation.

A number of helper functions are initialized 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 4 shows the check in the code.

Figure 4: 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 5.

Figure 5: Storing the value of all completed 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 6.

Figure 6: 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:
[0-9]{13,16}

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 7.

Figure 7: Exfiltration of collected data to the C2.

An example of scraped data before encryption is shown in Figure 8.

Figure 8: 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 9. Also shown is the legitimate Google Analytics request. Note the difference in the method used and the protocol.

jquery-js.com

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

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 the 7th of January, 2017.

jquery-min.js

“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 10.

Figure 10: 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 11.

Figure 11: 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 12 & 13.

Figure 12: Malicious skimming script.

Figure 13: 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.

Recommendations

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 potentially 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.