Threat actors are notorious for trying to hide their code in various ways, from binary packers to obfuscators. On their own, these tools are not always malicious as they can also be be used by companies or individuals who wish to keep their work safe from piracy, but overall they tend to be largely abused.
In the case of credit card skimmers in client-side attacks, obfuscators are a common occurrence as they can make code identification more difficult. Defenders typically have the choice to either rely on the browser’s debugger and step through the code, or can statically try to reverse it. The latter tends to be quite time consuming, but the former can often problematic if the malware author adds anti-debugging routines.
Today, we look at a Magecart skimmer that uses Hunter, a PHP Javascript obfuscator. During our investigation, we were able to discover a number of domains all part of the same infrastructure with custom skimmers for several Magento stores.
Initial injection on e-commerce sites
The attack relies on 2 steps: the first one is code injected inside the website’s source that calls out a remote URL. That URL in turn, loads the skimmer within the payment checkout process.
We notice a large blurb of code that contains some static elements and others that are uniquely generated. The ‘eval‘ portion of the code is a clear giveaway that the random looking string is being processed dynamically to return some instructions.
The function (h,u,n,t,e,r) helps us to identify that this obfuscator is called Hunter and available on GitHub. To decode the obfuscated string, we can simply write out the content of eval and we obtain a single line of JavaScript pointing to a URL.
This URL contains code that has been obfuscated with Hunter once again. This time, once we deobfuscate it, we see what appears to be HTML code with forms referring to credit card fields. This is the actual skimmer.
Skimmer at checkout page
When a victim who’s shopping at a compromised online store goes to check out, there will be additional fields injected in the contact form that aren’t normally there. Below is the legitimate checkout page of a store without the skimmer being loaded:
We can see that the payment process is on the bottom right hand side. In contrast, this is what the same page looks like when the skimmer is loaded:
Additional fields were inserted between the shopper’s email address and name. In this case, the threat actor didn’t do a very good job because the fields are in English while the rest is in Spanish.
The credit card data to be stolen is encoded, then stored inside a cookie and subsequently exfiltrated via a POST request.
Infrastructure
The skimmer domains registered with Porkbun all appear to be hosted on the same server at 193.201.9.116 (ASN49505):
We can get any of the currently still resolving domains to show their own version of the skimmer code by crafting a GET request with the proper referer:
The Hunter obfuscator is handy but quite easy to reverse and as such provides minimal stealth capabilities. Based on the skimmer code, this is not a very sophisticated attack probably limited to less than a hundred stores. However, this was the first time we encountered a Magecart skimmer using this kind of obfuscation and most endpoint security products are not detecting the client-side JavaScript.
Malwarebytes customers are shielded against this campaign via our web protection in End Protection (EP), Endpoint Detection and Response (EDR) and Malwarebytes Premium.
