I’ve been examining an interesting digital skimmer/magecart script the past couple of days and figured I’d share some details. Perhaps the most puzzling aspect is the three Korean IPs hardcoded into it, although there are a number of other interesting details as well.
Malicious code will use a variety of methods to hamper attempts at reverse engineering them. Obfuscation is common, but other methods include purposefully crashing the application that you’re using to inspect the code.
One of the first things that is done when examining malicious code may be to prettify it in and IDE or using an online tool like prettifyjs.net. But if you do that with this code, and then run in in your browser’s devtools, it’ll crash the tab it’s in. But if you don’t clean it up, it’s a big mess. So what do you do?
Continue readingLoading malicious Javascript from a “benign” file isn’t a new thing, but using a Font file is. Spotted a WOFF file with a malicious payload in the wild. As we’ve seen before when using a PNG, the file is requested using a fetch and then the non-Javascript part of the file is sliced away. A link to the code below: https://gist.github.com/krautface/897f077ab5fd64af2ee1a280be5b91de
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.
Just a quick post on a digital skimmer loader that is somewhat unique. The threat actor used a script tag with a base64 encoded payload.
Digital skimmers will use a variety of infrastructure setups to help hide the real servers. This varies by the script that is being used, but in general you will see three different hosts involved:
Host 1 and 2 are sometimes the same, but the goal here is to hide the third host from prying eyes. The idea here is to hide the important stuff, the Panel behind a shroud that can’t easily be pierced. The code for these gates is rather simple, but let’s take a look at two examples.
Continue readingHunting for digital skimming/magecart infrastructure is interesting. We have an advantage that the bad guys can’t stop: unless they’ve breached the payment servers of some company, their actions are completely public. They’ll do their best to hide themselves, but every method they use leaves a fingerprint. So we get to exploit that. Let’s look at a common method for loading a digital skimmer. atob('Y2h…') is equal to ‘checkout’, so what this is doing is looking for checkout in the URL, and if it’s found, the rest of the code is executed.
A lot of skimmers have different levels of obfuscation and code protection built in to hide their actions and protect what they are actually doing. Here’s an example of one with some basic protections.
First, the prettified code. On line 3 there is an anonymous function b which does string deobfuscation. It goes beyond the basic XOR that we’ve seen elsewhere. It is used to decode the items in the c array on Line 37, and the actual digital skimmer code which is loaded on line 49.
In my last post, I highlighted a digital skimming loader that tried to pretend that it was Google Analytics. In this post, I’ll show a similar one, this time purporting to be Google Tag Manager. This is by the same group as the one shown in the previous post, and you can clearly see the similarities. The full prettified code:
Continue readingA quick examination of a Magecart/Digital Skimmer loader. A loader is just Javascript code that loads additional code. They’re designed to look innocuous, frequently mirroring common tools like Google Analytics. To start, here is the entire code:
If you look at the code, you’ll notice some weird variable names calling a function named addClass with two seemingly random arguments, the second one always being kpwajqjds1e.