At RiskIQ, we track many different Magecart groups. We continually observe evolutions in the techniques they employ to skim card data and obfuscate the code that they use for that purpose. These skimmers are becoming increasingly capable, fulfilling a variety of functions to optimize the work of the operators that deploy them. 

On January 24th, we first became aware of a new Magecart skimmer, which we dubbed MakeFrame after its ability to make iframes for skimming payment data. We initially flagged it with our machine learning model for detecting obfuscated code. 

Since then, we have captured several different versions of the skimmer, each sporting various levels of obfuscation, from dev versions in clear code to finalized versions using encrypted obfuscation. So far, RiskIQ has observed MakeFrame on 19 different victim sites. 

In some cases, we’ve seen MakeFrame using compromised sites for all three of its functions—hosting the skimming code itself, loading the skimmer on other compromised websites, and exfiltrating the stolen data. There are several elements of the MakeFrame skimmer that are familiar to us, but it’s this technique in particular that reminds us of Magecart Group 7.

The following is our analysis of this unique skimmer and the process we followed to attribute this skimmer to Magecart Group 7.

The Skimmer

This version of the skimmer is the classic Magecart blob of hex-encoded terms and obfuscated code. It is nestled in amongst benign code to blend in and avoid detection.

The original code starts as many obfuscated scripts do, with an array of strings. Here, the strings are hex-encoded. In less complex flavors of obfuscation, the array is referenced later on in the code, and the deobfuscated script can be seen by merely substituting the appropriate terms. However, this particular skimmer adds a couple more layers of sophistication, i.e., annoyance for researchers like us. 

When the function immediately following the array executes, it employs a simple anti-analysis technique. With this technique, a regular expression checks the function _0x5cc230[‘removeCookie’] to see if it has been altered. This check detects the usage of beautifiers that add new lines and white space not present in the original code. Code beautifiers are useful for making condensed or obfuscated code more readable for threat analysts. Instead of a blob of code, they get a nicely formatted version, which makes their analysis much easier.

However, this code, in particular, will not execute properly if it has been beautified (due to the check referenced here), making it impossible to deobfuscate it. This check means that a researcher has to deal with the blob of code if they want to deobfuscate it. For analysts experienced with deobfuscation, it just costs more time; for ones who are not, it could prevent them from figuring out what the code is doing.

So, when the .toString method of the function is called, the beautified version, seen here, would not pass the check:

However, the unmodified function, shown here, does:

Once this check passes, the array rotates several times with a series of push and shift calls. This process arranges terms in the correct order to (re)construct the skimmer code.

The skimmer also has many calls to the function _0x1f9e, with hex strings as input:

This function returns the appropriate values from our initial array of strings_0x4f66. In this case, the return value is simply the array element with the index provided by the octal number, so_0x1f93(‘0x0’) returns the value from the array _0x4f66[0].

We have also seen that this function can reshuffle arrays or further decode obfuscated strings with a given key. Replacing these function calls with their corresponding return strings starts to reveal the skimmer underneath. Here, we see the script define ‘RR’ as an alias for Object[‘create’](null), which will be used throughout the script to create several JavaScript objects:

One of the more distinctive of these objects is RR[“naem”] = ‘wellnessCC’;. This “naem” refers to the compromised site and appends to the skimmed and encoded data, which is sent to an exfil file, defined as RR[“relay”] = “/tools/geoip/geoip.php”;, via a XMLHttpRequest (an API in the form of an object whose methods transfer data between a web browser and a web server). The RR[“radio”] = “#id_payment_method”; object refers to a payment method their skimmer, which creates its own payment forms, is attempting to emulate. Other versions refer to Litecheckout, Braintree, eWay Rapid, and others (they include 1337 in there as well, so you know they think highly of themselves).

The final line of the script calls three functions: check_referrer, detect, and r0.

The first of these, check_referrer, checks if the referrer is the compromised website via the location.host property and creates a cookie indicating whether this is the case or not. If this is true, the next function, detect, is executed.

The detect function calls the sl1 function, which looks for data entered into the payment form and the pressing of the “submit” button by the victim once they have entered their data. This check occurs once a second.

Again, we named this skimmer MakeFrame after its creation of iframes for skimming payment data. Objects such as RR[“ccn_frameq”] = “#card-number iframe”; and RR[“cvv_frameq”] = “#cvv iframe”; refer to this directly. The r0 function creates these iframes into which the victim enters their payment data. Another function called make_input formats the fake payment form while btq creates the “submit” button. If a victim fills out this form and presses the submit button, the card data is skimmed.

The Mage-nificent 7

RiskIQ has identified three distinct versions of this skimmer with varying levels of obfuscation, from clear JS code to encrypted obfuscation. Some of these appear to be dev versions running debug processes, one of which even includes a version number.

Magecart Group 7 also used victim sites for skimmer development, as we observed when they compromised OXO in 2017 and (twice) in 2018. The target pool for this new skimmer is similar to Group 7 as well. Each of the sites belongs to a small or medium-sized business, and none are particularly well known, with OXO being a bit of an outlier in their history.

The skimmer has been observed on 19 victim domains so far.

In all of these cases, the skimmer is hosted on the victim domain. The stolen data is posted back to the same server or sent to another compromised domain. Here we see the skimmer on a victim site sending data to another compromised site, piscinasecologicas[.]com in a .php file:

We have reached out to piscinasecologicas[.]com to communicate the compromise of their server.

This method of exfiltration is the same as that used by Magecart Group 7, sending stolen data as .php files to other compromised sites for exfiltration. Each compromised site used for data exfil has also been injected with a skimmer and has been used to host skimming code loaded on other victim sites as well.

Looking back on our prior breakdown of Group 7’s skimming code from our report Inside Magecart, the method of encoding stolen data as one long string of base64 is strikingly similar between older Group 7 skimmers and these newer samples. Each even includes the term  p1

Old:

New:

Additionally, In the construction of both old and new skimmers, we see the use of a double letter defined as an alias for the creation of objects by the script.

Old:

New:

Based on these similarities in technique and code construction, we believe this new skimmer is a product of Magecart Group 7.

The Backend

While we were working on this, we caught some open-source intel from a fellow researcher:

From the screenshot of the code, we can tell that this is the MakeFrame skimmer and that it was likely loaded on a victim site we have previously observed, based on “naem” definition:

However, there is an interesting new tidbit here—the exfil URL is a bare IP that does not belong to a victim site. This IP, 163.172.136.230, also has a notable cert on it:

This hex-havana-pw cert appears on one other IP, 163.172.138.32, since March of 2019:

According to our web components, these IPs are running Debian, Apache, and OpenSSH. They are owned by Online SAS, a French cloud computing, and web hosting company. Unfortunately, the trail ends there, for us anyway. 

IOCs:

https://community.riskiq.com/projects/69572de6-8b6c-479e-a707-aa741e22c394

Conclusion

This latest skimmer from Group 7 is an illustration of their continued evolution, honing tried and true techniques and developing new ones all the time. They are not alone in their endeavors to improve, persist, and expand their reach. RiskIQ data shows Magecart attacks have grown 20% amid the COVID-19 pandemic. With many homebound people forced to purchase what they need online, the digital skimming threat to e-commerce is as pronounced as ever. 

As we saw in the attacks on NutriBullet and other victims, there are a variety of ways to attack the functionality of a website. Operatives with the right know-how and enough time will find them. Make sure you’re staying up to date by reading all our findings on Magecart and stay tuned as we continue to shine a light on new developments. Also, find out how RiskIQ protects customers by reading up on our JavaScript Threats Module here.