The Mongolian Skimmer: different clothes, equally dangerous

with Pedro Marrucho and David Alves

A few weeks ago, while consulting skimming threat intel sources Jscrambler researchers stumbled across a new skimming campaign that, at first glance, stood out because of the JavaScript obfuscation it exhibits. Some people raised the question if this was a new obfuscation technique, probably because the code is using weird accented characters.

As part of a company that makes a JavaScript obfuscation tool, the team could tell immediately that it is not. The obfuscation author just used unusual Unicode characters for variables and function names. But that has been done before and it’s hardly an obstacle.

The Jscrambler researchers went over the obfuscation, retrieved the details of the attack, and affected victims and we even saw a strange interaction between different skimming actors chatting through comments in the code. Read everything below.

Mongolian Skimmer

Obfuscation

Jscrambler researchers learned about this skimming campaign from Sansec threat intel. No details were available on it, but the team did a full analysis. At first glance, the thing that stood out was the script’s obfuscation, which seemed a bit bizarre because of all the accented characters. Some people online were saying it could be a new obfuscation technique. The heavy use of Unicode characters, many of them invisible, does make the code very hard to read for humans.
 

But the minute Jscrambler researchers started looking at the obfuscation, they realized immediately that it wasn’t a new fancy technique — it was simply leveraging a well-known JavaScript language capability: the ability to use any Unicode character in identifiers (e.g. variable names), as per the ECMAScript Standard.

The added obfuscation does introduce confusion (we call this obfuscation potency) but it does not add any resiliency (how hard it is to reverse engineer, using manual or automated methods). A simple method to remove these characters is to pass the code through a JS transformer that renames all identifiers to simple names (e.g. ‘a’, ‘b’, ‘c’, …). But that’s only useful if a human needs to look at it. A fully automated JS obfuscation reverse engineering engine will not mind what unicode characters are being used. The tooling has been available and fully automated at Jscrambler for years. It’s one of the things Jscrambler researchers use to find skimmers in our products and research.

Using Jscrambler's own Code Integrity product, the team quickly renamed all the identifiers to much shorter and more readable ones.After renaming the variables the code resulted in a bunch of string concatenations, including a few String.fromCharCode(...) statements, which contain a hidden skimmer, to be passed to an eval function call.

The eval-ed string reveals a script that was also obfuscated using a common obfuscation tool. Once the eval runs, it loads a skimmer designed to steal sensitive information.

Once Jscrambler researchers reversed the JS, they quickly confirmed that this was a pretty standard skimmer.

Naming the Skimmer

When they analyzed the first variable assigned in the script, its initial character was represented by the hex value “E1A0A5”, which corresponds to a Unicode character named "Mongolian Letter OE". Such an unusual character being used by an identifier inspired the team to name the skimmer the Mongolian Skimmer.

Skimmer Analysis

The skimmer follows a typical skimming structure Jscrambler researchers have seen countless times in the past:

• DOM Monitoring for Changes
  The script continuously monitors changes in specific DOM elements like <input>, <select>, and <textarea> fields. These are prime targets for stealing user data, such as personal information or payment details. It extracts the name or ID attributes and fetches the value of these elements when users interact with them.

• Data Exfiltration
  The skimmer checks the page URL for keywords such as "checkout" or "admin" to identify pages handling sensitive data. Once identified, it encodes the data using window.btoa() for base64 encoding and sends it to a remote server via a tracking pixel (constructed with new Image()) - a classic skimming technique.

• Developer Tools Detection
  The script actively detects whether the browser developer tools (DevTools) are open. If detected, the skimmer disables certain functions—likely an attempt to evade detection during debugging or dynamic analysis phases.

• Data Collection Before Page Unload
  The skimmer ensures no data is lost by capturing any last-minute data entries before the page is closed or refreshed using the beforeunload event.

• Cross-Browser Compatibility
  The skimmer uses well-known techniques to ensure compatibility across different browsers by employing both modern and legacy event-handling techniques. This guarantees it can target a wide range of users, regardless of their browser version.

• Anti-Debugging
  The skimmer employs an interesting anti-debugging technique by checking its formatting through string conversion and regex tests to detect tampering. This is a standard trick used by skimmers to prevent debugging by detecting code beautification or any other type of formatting changes.

Loader Analysis

Most of the Mongolian skimmer instances the team found used an inline script on the homepage, which asynchronously fetched the skimmer script from an external source. However, they did encounter one peculiar instance where a different loader was being used that is worth highlighting.

Unusual Loader Variant

This loader script appears to have been added to the loader of a Magento plugin named “Magento 2 Google Tag Manager” built by MageFan. It dynamically loads Google Tag Manager and the skimmer script, but only if it detects user interactions, such as:

• Scroll

• Mouse movement

• Touchstart

This approach may not only serve as an effective anti-bot measure but also as a way to make extra sure that the script loading is not visibly impacting page load performance.

Cyber Chit-Chat Using the Victims' Code

In one compromised Magento site, Jscrambler researchers found not just one, but two skimmer instances: the familiar "’Google’+’Analytics’+’Object’" loader which we talked about some time ago here, and the Mongolian skimmer. 

It’s not uncommon for compromised sites to be targeted by multiple malicious actors exploiting the same vulnerabilities. What made this case special was that Jscrambler researchers found the two threat actors casually chatting by leaving code comments in the source code to each other. This developed into an active conversation where the two threat actors agreed to split the profits of the skimming activity.

Take a look at their exchange:

We can’t say that cybercriminals don’t follow a code 🙂.

Conclusion

The obfuscation techniques found on this skimmer may have looked to the untrained eye as a new obfuscation method, but that was not the case. It was just another Tuesday in cyberspace. It used old techniques to appear more obfuscated, but they are just as easy to reverse. A simple code transformer can remove all the weird characters automatically for you. Underneath the skin, it was just a very common type of skimmer code, commonly found in misconfigured or vulnerable Magento installations in the wild.

Indicators of Compromise (IOCs): Malicious Domains