Credit card skimmer targets ASP.NET sites

Cybercriminals typically focus on targets that can get them the highest return with the least amount of effort. This is often determined by their ability to scale attacks, and therefore on how prevalent a vulnerability or target system is. Enter: the credit card skimmer.

In the world of digital skimming, we’ve seen the most activity on e-commerce content management systems (CMSes), such as Magento and plugins like WooCommerce.

However, it is important to remember that attackers can and will go after any victim when the opportunity is there. Case in point: The skimmer we describe today has been active in the wild since mid-April, and is targeting websites hosted on Microsoft IIS servers running the ASP.NET web application framework.

Unusual victims

As defenders, we tend to focus a lot of our attention on the same platforms, in large part because most of the compromised websites we flag are built on the LAMP (Linux, Apache, MySQL, and PHP) stack. It’s not because those technologies are less secure, but simply because they are so widely adopted.

And yet, in this campaign, the credit card skimmer is exclusively focused on websites hosted on Microsoft IIS servers and running ASP.NET, Microsoft’s web framework to develop web apps and services.

We found over a dozen websites that range from sports organizations, health, and community associations to (oddly enough) a credit union. They have been compromised with malicious code injected into one of their existing JavaScript libraries.

There doesn’t seem to be a specific JS library being targeted, and the code, which we will review later, sometimes takes different forms. However, all the sites we identified were running ASP.NET version 4.0.30319, which is no longer officially supported and contains multiple vulnerabilities.

While ASP.NET is not as popular as PHP, especially for smaller businesses and personal blogs, it still accounts for a sizable market share and, as one might expect, includes websites running shopping cart applications. All the compromised sites we identified had a shopping portal, and this is exactly what the attackers were after.

Different types of malicious injection

In a few instances, the skimmer was loaded remotely. For example, Figure 4 shows a legitimate library where malicious code was appended and obfuscated. It loaded the skimmer from the remote domain thxrq[.]com. The actual file may be named element_main.js, gmt.js, or some other variation.

However, in most cases, we saw the full skimming code being injected directly into the compromised JavaScript library of the affected site. There were several different styles that made identification a little challenging.

Skimmer triggers on credit card number or password

This skimmer (source code here) is designed to not only look for credit card numbers but also passwords, although the latter appears to be incorrectly implemented. We can see those checks with two different calls for the match method.

The data is encoded using an interesting logic.

• charcodeAt() method to return the Unicode of each character contained within the string of each specific field
• toString() method to convert that number to a string

There’s an additional twist in that it groups the resulting combined strings by sets of two characters.

Finally, the data is exfiltrated via the same domain in a GET request where the filename is a GIF image. When this skimmer is loaded by default, it will also issue a GET request for the file null.gif (no exfiltration data present).

In order to decode data sent in an exfiltration attempt, we need to reverse this logic.

• Take the blurb and create an array of elements with two strings each
• Use the parseInt() function to transform the two-character string into an integer
• Use the String fromCharCode() method to convert the Unicode number into a character

Here’s how we can take the URL path with encoded data (input) and run it through a piece of JavaScript to see the decoded version of it:

Campaign likely started mid April

This skimming campaign likely began sometime in April 2020 as the first domain (hivnd[.]net) part of its infrastructure (31.220.60[.]108) was registered on April 10 by a threat actor using a ProtonMail email address.

OSINT data from sources such as urlscan.io shows various sites and brands were affected during this time period. Some of those sites already remediated the compromise.

We started contacting the remaining affected parties in the hope that they would identify the breach and take appropriate actions to harden their infrastructure.

All platforms and frameworks welcome

Credit card skimming has become a popular activity for cybercriminals over the past few years, and the increase in online shopping during the pandemic means additional business for them, too.

Attackers do not need to limit themselves to the most popular e-commerce platforms. In fact, any website or technology is fair game, as long as it can be subverted without too much effort. In some cases, we notice “accidental” compromises, where some sites get hacked and injected even though they weren’t really the intended victims.

Malwarebytes customers are protected against this and other credit card skimming campaigns via web protection technology available in our desktop software and through our Browser Guard extension.

Thanks to @unmaskparasites for sharing additional insight on the affected websites.

Indicators of Compromise

Regex to find ASP.NET skimmer injections

(jqueryw+||undefined;jqueryw+={1,5}undefined&&)|(!window.jqvw+&&(jqvw+=function(a){return)

Skimmer infrastructure

idpcdn-cloud[.]com
joblly[.]com
hixrq[.]net
cdn-xhr[.]com
rackxhr[.]com
thxrq[.]com
hivnd[.]net

31.220.60[.]108

The post Credit card skimmer targets ASP.NET sites appeared first on Malwarebytes Labs.