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.
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.
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.
The skimmer domains registered with Porkbun all appear to be hosted on the same server at 22.214.171.124 (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: