I'm going to highlight parts of the skimmer, partially out of order. Also, most of these screenshots are from my deob version.
First, it allows the attacker to easily customize it to attack various stores.
4/30
These settings are used to tell the skimmer what fields to look for. It also allows an attacker to target form fields by either name or id. The addressFields also tell the skimmer whether it should look for a select field (dropdown) with the last variable.
5/30
Those settings are used by the processFields function. This function loops through all the form fields passed into it and checks to see if any of them matches one of the 8 paymentFields, or one of the 7 addressFields.
6/30
It does this using 8 nearly identical IF statements for the payment info, and a FOR loop for the address fields, along with more IF statements. Each IF statement attempts to match the details of the field it's examining with the custom settings of the skimmer.
7/30
processFields is called multiple times by the "gatherFields" function. It, surprisingly enough, gathers all the fields up to be examined. It will then call "savePayload" to store the payload as a cookie (if a variable is set.)
8/30
A lot of skimmers have anti-RE techniques in them, and ManyQ has some as well, albeit approaching things from a different way. Instead of trying to detect Chrome Devtools, it's trying to detect if it's being executed outside of a browser.
9/30
The "start" function is the first thing called. It runs the anti-reverse engineering check and then starts a loop that checks the payment form every 500ms by calling the "gatherAndExfil" function.
10/30
"gatherAndExfil" does two things: calls "gatherFields" (described above) and calls "prepareAndExfil". This function is always watching the page to see if four values have been filled: CC #, CVV, Card Holder, Expiration Date.
11/30
If those four values are present, it exfils the data. To prevent itself from exfiltrating the same data multiple times, it creates a simple hash of the value it exfilled and saves that to an array.
12/30
Now, amusingly, this can result in a bunch of exfil attempts if you first fill in your payment info, and then fill out the rest of your billing information. It also stores some of this information as a cookie.
13/30
And that's the major parts of the code. There were some things that were basically no-ops, and other parts that weren't used. This skimmer also supports payment overlays, which this version utilized:
I've identified 23 domains so far that either have loaded this code onto a victim website, or been used to exfiltrate the data from a victim's website.
Inter does a lot of the same things that ManyQ does. In fact, it does all the things that ManyQ does. It watches the page and once the payment information is collected, it exfils immediately. It used to use an md5 to prevent dupes.
18/30
But that changed recently. Previously, it had a function called "calcMD5", but if you look at that copy of Inter I linked above, it is missing, but at the top there is a new "hashCode" function.
19/30
That hashCode function was added to Inter after it appeared in ManyQ. Here is the ManyQ version. It looks a little different, but it computes the same values.
20/30
Next, lets compare the ManyQ "gatherFields" function to the Inter "SaveAllFields" function. Slight difference in that "gatherFields" passes the arrays it captures, where as SaveAllFields loops through them, but very close.
21/30
ManyQ's "processFields" is an improed version of Inter's "SaveParam". The main difference being that the settings for ManyQ are held outside the function and it can handle arrays of fields.
22/30
Before exfil, both skimmers check for four values, in this order and with these names: Number, Holder, Date, CVV:
23/30
And, while there's more, one last example: If you look at "processFields" in ManyQ and "GetCCInfo" in Inter, you'll see that the 8 IF statements in both gather the same 8 bits of data in almost the same exact way.
24/30
So I'd say that leaves three options: 1. ManyQ is a new product of Sochi's, and possibly a new skimming kit. 2. ManyQ is actually just a new version of Inter. 3. Someone ripped of Sochi's code.
25/30
Option 3 is probably the least likely, in my opinion, simply because there has been attackers who have moved from Inter to ManyQ, and reputationally that would be... awkward.
So, that's a lot of tweets. There's more to this skimmer for sure, and if anyone else has already named this thing, please let me know. I'd rather adopt an existing name. "ManyQ" just meant I had "Many Quesitons" about it.
28/30
Also, just figured I'd point out that the variable names in the deobfuscated version of ManyQ are my creation. If you want a pretty clean version of ManyQ that doesn't have any of my names, this is a pretty good one:
Thanks to data from @sansecio I think we've found the first digital skimmer/#magecart script to exfil using Telegram. In this thread, I'll go through the code, the drawbacks of this approach, and how to stop it dead (hint: CSP).
1/11
This of course isn't the first digital skimmer to abuse unrelated services to exfil its data. For example, back in June we saw the public disclosure of digital skimmers abusing Google Analytics: sansec.io/research/skimm…
2/x
Saw this new digital skimmer/#magecart JS for the first time last week. Haven't had time to dig really deep into it, but here's the basic overview. Calling it the Callback skimmer for now. Above average JS for a digital skimmer.
1/9
New digital skimmer/#magecart technique: steganography
A colleague found this a couple of days ago while searching through our SIEM. The skimmer group uploads or modifies an existing image and appends the JS code.
1/5
Here's an example of a live image. You can load this image and prepend view-source: The next tweet has the code that loads and runs the code in this image. The full skimmer code is in a gist on the last tweet.
I think I stumbled upon a novel digital skimmer/#magecart script still in development and figured I'd share all the code and (limited) infrastructure I've found so far. And I'll share the simple method to stop this technique dead (tweet 16 😉)
First, what makes it unique?
1/17
- Malicious payload is loaded over websockets
- Exfil over websockets
- A rather clever skimmer loader that I think may fool a lot of people
- CSS classes(!) being used to construct the URL
Intrigued? Great. Let's go
2/x
Let's look at the skimmer loader. Look like anything you're used to seeing? querySelector, className, Canvas ondraw? What in the world? Where's the script tag created?
Let’s do a quick dive into quickly pulling out the interesting bits from an obfuscated #magecart script. And by that I mostly mean the exfil URL. This will only cover one of the most common obfuscator types, as featured at javascriptobfuscator.com and obfuscator.io.
There’s lots of other types as well, but this is a good place to start. First, the simplest type, one with hex encoded strings. You can play with that one here: gist.github.com/krautface/aed4…
This is really easy to deobfuscate completely, using beautifier.io, but if you just want to know what’s in that array of strings, just copy the [ … ] into your devtools and hit enter and presto, your work is done.
Want to learn to hunt for some #magecart infrastructure? Then you've come to the right place. Going to walk you through how to do it, from the very start to the end. /thread (probably 30-35 tweets, so hope you're interested)
Just found a couple of domains that I haven't seen elsewhere, so if you stick through to the end you'll get to see newly discovered infrastructure. If you somehow knew of it already, let's talk, I'd be curious how you came upon them.
2/x
First, a disclaimer/ask: when you're doing this, you're going to find affected websites. There's lots and lots of them. Maybe don't name and shame the little guys? Takes about the same amount of time to send them a quick note as it does to highlight that they're affected.
3/x