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.
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.
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.
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
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.
Thanks to @unmaskparasites for sharing additional insight on the affected websites.
Indicators of Compromise
Regex to find ASP.NET skimmer injections
Refer Here for Original Post and Source https://blog.malwarebytes.com/threat-analysis/2020/07/credit-card-skimmer-targets-asp-net-sites/