For the past month or two I’ve been seeing this digital skimmer that I’ve started to call “checkcheck”, based on a function name in the code. It has a number of interesting features.
The most interesting feature may be how it handles form injection. Not how it injects the actual HTML, but how it tries to convince the victim to reenter their payment information into the actual payment form after entering it into the malicious form.
The code, in various forms:
- Obfuscated: https://gist.github.com/krautface/9fa31c12b083864ed6413a16c6c56e74
- Prettified: https://gist.github.com/krautface/13ab5a866c17621a7729e0b41b53a2a9
- Partially Deobfuscated: https://gist.github.com/krautface/13b07dd45d4676d024b4e9f65db434ea
- Mostly Deobfuscated: https://gist.github.com/krautface/4ffef78eda7d907587e67f08ef31112c
For the fully deobfuscated version, please note that most of those function names are mine, other than the checkRsrch function (I think). Most of the screenshots are from one of the deobfuscated versions. Some of the commonly seen digital skimmer features that “checkcheck” also exhibits:
Mobile Browser Detection
Payment form injection
Configurable
Devtools Detection
Now some of the more interesting features. First, the functionality I mentioned earlier: checkcheck’s attempt to get the victim to reenter their payment information into the real payment form. Now, why is this functionality important? If the skimmer completely breaks the checkout flow, or does something that has a significant impact on the number of orders going through, that may lead to it being detected.
What this skimmer does is after it exfils the data, it highlights the CVV field in red, sets a cookie that disables the skimmer, and then reloads the page. The next time the user attempts to checkout, the skimmer will not inject its form, and the payment will be successful.
Seeing a form field with a red background is a very common experience for online shoppers, so it is likely that they would not be too bothered by this chain of events, and most will try to pay for the item again.
Another unique thing this skimmer does is how it encodes its data before exfils. It base64 encodes it, as is very common, but then it swaps a bunch of different characters for other characters. By doing so, it makes it no longer decodable.
Specifically, it swaps a,h,e,0,7,d,T,o,Y, and w for -,_,:,/,^,#,@,%,*, and +. Now, amusingly, there could be a case where doing these swaps could make their data unrecoverable. Both / and + are legitimate base64 values, but they do not commonly show up in encoded values.
One last sort of unique thing is the use of more modern Javascript. This may have been created by someone with a little more skill than some of the digital skimmers we see, although this skimmer has a bug in it with mobile browser detection that newer versions do not have.
Here are the domains used by the threat actor:
apayments[.]top
livechatlnc[.]com
paypalobjacts[.]com
tagmanaqer[.]com
exfil URL:
livechatlnc[.]com/checkouts.js
A modified version of this was originally posted on Twitter:
https://twitter.com/AffableKraut/status/1411229367569719296