Curated Intel Threat Report: Multi Platforms Credit Card Information Harvesting Campaign

Introduction

Tas (@tas_kmanager), in collaboration with Curated Intelligence, shared his research on the newly observed method of phishing utilizing chat functionality in multiple web/mobile applications. Furthermore, he is able to link this campaign to other similar campaigns based on the shared TTPs and IoCs.

Background

We have recently tracked a connection in global credit card information harvesting campaign targeting user in different postal and e-commerce services. This latest wave of phishing introduced a novel TTP of utilizing the postal, reservation and e-commerce services chat functionality.

Earlier in this month, Tas personally received a suspicious message via chat from a hotel merchant in the travel reservation application Booking.

Figure 1- The Chat Message

The message itself came from the official account of the hotel merchant, Tas has contacted them before via this method to inquiry information about the hotel room. The message was letting the guests know that they are required to enter their information in an online form, with the premise of combating stolen credit card fraud (the irony!)

As per usual phishing TTP, the threat actor was using urgent and threatening language, such as “THE PROCEDURE IS MANDATORY” and “it will remain active for 12 hours until your booking is confirmed” Another interesting thing to mention is that the threat actor does know the hotel where the guests are staying, the time of their stays, the reservation ID (being used in the phishing link). Thanks to all the information above and the fact that the message was coming from the hotel merchant account, this phishing message almost fooled Tas. The biggest red flag that saved him is the unusual phishing URL, and a major typo in the phishing domain. 

Initial Analysis

We continued the investigation in the sandbox. Once the unsuspected guest clicks the link, it leads the guest to fake Booking website, specifically “Your Selection” page. See the screenshot below.

Figure 2 - “Your Selection” Page

The fake Booking website is resembling the legitimate Booking website while also containing the right information related to the guests’ booking, such as:

• Hotel name
• Hotel address
• Hotel image (sometimes it’s a screenshot of the hotel page in the Booking app, not the hotel itself)
• Check-in date
• Check-out date
• Price (sometimes in the wrong currency)
• First and last name (came prepopulated and can’t be changed)

To proceed to the next page, the guest must add a phone number. There is a phone number checking mechanism applied in this page. Once added, we will be taken to the “Your Details” page. See the screenshot below. Interestingly, the fake Booking website has a support chat functionality (blue chat icon on the bottom right), which does not exist in the legitimate website.

Figure 3 - “Your Details” Page

Similarly, to the previous page, there are also multiple checking mechanisms in “Your Details” page. Primarily to verify credit card information, such as card number, expiry date and CVC number. Once the guest entered an acceptable credit card information, we will be redirected to this loading page and the guest data will be forwarded to their controlled server.

Figure 4 - Processing Page

This page will either display a successful transaction message or additional error messages, that we will look deeper in the next section.

Code Analysis

To gain better understanding of the web application, we will look deeper into the code. So far, we have 3 different pages with some unique functionality that verify the inputted information.

The Copycat

The initial observation and a key factor that lends an air of legitimacy to this phishing attempt is the striking similarity between the counterfeit Booking page and the genuine one. A closer examination of the code reveals that the threat actor is employing identical HTML themes, IDs, and classes in all three pages we've examined. Please refer to the comparison below, where both pages exhibit these similarities.

Figure 5 - Legitimate Booking Website Code

 Figure 6 - Phishing Website Code

Custom Script in the HTML codes

To collect the necessary information, the threat actor needs to insert their own code to redirect the data to their server for collection and validation. Below, you can observe different classes employed in the legitimate Booking website code compared to those used in the phishing page.

Figure 7 - Legitimate Booking Website Phone Section Code

Figure 8 - Phishing Page Phone Section Code

More to that, on the “Your Details” page where the victims are asked to provide credit card information, there are script snippets added to the end of the HTML Code that function as credit card information submission function. It can be observed that the Threat Actor cannot keep certain comment to themselves.

Figure 9 - Credit Card Submission Function

Even more interesting, the Threat Actor are considering numerous scenarios that could happen with the Credit Card transaction and have created multiple functions to catch these scenarios, here are some of the scenarios they have planned:

• The user is utilizing multi factor authentication (SMS Code, Application Code, etc.).
• The user is hitting transaction limit.
• The user is not having the minimum amount of money on their account.
• The user is not using 3D-Secure authentication.
• The user online payment is disabled.
• The user transaction is blocked by Geolocation blocking.
• The user is using other banks that the Threat Actor is not aware of.

Figure 10 - User Scenarios Function

The Threat Actor then will display different messages for each scenario, instructing the victims on how to make sure the transaction will go through successfully.

Figure 11 - User Scenarios Response

One function is also able to request SMS code from the victim and submit the code automatically to the Threat Actor server where it will perform the MFA bypass. Note that there is a comment containing “pluxurydarklord”, likely the alias of the creator of the function or the script. The SMS code is passed utilizing the Axios post request.

Figure 12 - SMS Code Handling Function

Custom JavaScript Files

There are several interesting JavaScript files that are stored in unusual path, in the example below the custom JavaScript codes, submit.js and blur_input.js, are stored in “/css/booking1” path.

Figure 13 - HTTP transactions information from urlscan.io

Digging deeper into the submit.js code, we are seeing lot of capture and verification functions to support data collection of the victim.  Below are the functions to verify email address and phone number.

Figure 14 - Email Address and Phone Verification Function

The threat actor took precautions to ensure that the victim entered valid credit card details, including the credit card number, expiration date, and CVV number. Below is the function that employs custom regex patterns to validate various recognized credit card formats.

Figure 15 - Credit Card Verification Function

Finally, within the submit.js code, there are intriguing comment lines at the beginning of the code within the phone-inputs-wrapper. Upon closer examination, it was revealed that these comments appeared unusual due to encoding issues when transitioning between the Russian Cyrillic and English language systems.

Figure 16 - Interesting Comment Lines

After fixing the encoding, the comments are indeed written in Cyrillic:

// Получаем текущее значение в поле ввода

var inputValue = input.value;

// Используем регулярное выражение для удаления всех символов, кроме цифр

var numericValue = inputValue.replace(/[^0-9]/g, "");

// Обновляем значение в поле ввода только цифрами

input.value = numericValue;

 

The comments are translated to:

// Get the current value in the input field

var inputValue = input.value;

 // Use a regular expression to remove all characters except for digits

var numericValue = inputValue.replace(/[^0-9]/g, "");

 // Update the value in the input field with digits only

input.value = numericValue;

 

The code is likely written in the systems with Cyrillic encoding system.

The Missing Part

After the deep analysis on the phishing components against the victims, we are left with one important question unanswered. How did the attacker gain access to the Hotels chat systems in the Booking website? Fortunately for us, Perception Point researchers already did the investigation to answer the question.

What's absent from this campaign's narrative is that hotels became targets of InfoStealer malware, delivered through phishing URLs in emails disguised as messages from hotel customers. As a result of successfully harvesting official Booking account credentials, the threat actor gains the capability to access valuable customer information. This includes full names, booking dates, specific hotel information, and partial payment details that were employed to secure reservations on the platform.

Perception Point's assessment indicates that numerous hotels and resorts have become victims of InfoStealer attacks, resulting in thousands of individuals having their credit card information compromised on a global scale.

Pivot Time

In the role of a threat researcher, Tas consistently raises questions and maintains curiosity about whether Booking is the sole platform used for delivering phishing attacks via the chat function. Tas leverages urlscan.io to explore different aspects of the phishing tool. Through the shared elements of the phishing websites, it becomes evident that a more extensive operation is in progress, involving various other platforms, predominantly within the realms of e-commerce and package delivery services.

The earliest documented instance dates back to October 2021 when the threat actor impersonated the Romanian OLX e-commerce website. The approach here diverges somewhat; instead of targeting the product or service buyer, the attacker focuses on the seller. The attacker claims that the sender must verify their credit card to accept payment from the buyer. In this scenario, it's the buyer's OLX account that becomes compromised.

Figure 17 - OLX Phishing Page

We also observed that the threat actor is utilizing Domain Fronting to prevent detection based on IP addresses, but this time they are using different service providers, DDOS-Guard based in Russia.

Figure 18 - Domain Fronting Technique using DDOS-Guard

Another instance occurred in November 2021, where the threat actor replicated the website of the Polish InPost package delivery service, with their focus on the product seller.

Figure 19 - InPost Phishing Page

The threat actor employs identical information to persuade both the victim, while continuing to employ domain fronting techniques, specifically utilizing the Cloudflare service. Furthermore, we note the existence of chat functionality on both pages. Notably, in this instance, there is an evident use of URL shortening to circumvent potential detection related to the URL, likely aimed at evading email spam/phishing filters.

Figure 20 - URL Shortener as Evasion Method

In summary, approximately 1,300 URLs exhibiting campaign-related characteristics have been submitted to urlscan.io since the initial entry in October 2021. When randomly sampling data from various time intervals (today, 3 months ago, 6 months ago, 1 year ago, and 2 years ago), the following features are observed.

Time	Domain	Company Impersonated	TLS Certificate Issuer	Domain Fronting	Target
Today	confirmation-booking[.]id59212[.]top	Booking	R3	Cloudflare	Buyer
3 Months Ago	Blablacar[.]pay-id332[.]ru	BlaBlaCar	GTS CA 1P5	Cloudflare	Buyer
6 Months Ago	Foxpost[.]reservation08009[.]cloud	FoxPost Hungary	GTS CA 1P5	Cloudflare	Seller
1 Year Ago	posta-ch[.]order-id87397[.]cloud	SwissPost	GTS CA 1P5	Cloudflare	Seller
2 Years Ago	allegro-fxyd[.]secur-umowa[.]space	Allegro Polish	Cloudflare Inc ECC CA-3	Cloudflare	Seller

Over the last two years, the threat actor has frequently impersonated e-commerce and parcel delivery platforms listed in the urlscan.io database. See below table for the commonly impersonated platforms.

Organization	Domain Count (urlscan.io)
SwissPost	105
Carousell	100
Privat24	25
OLX	68
InPost	22
FoxPost	29
SberBank	14
DHL	28
Vinted	41
Booking	26
NZPost	21
Wallapop	20

Summary

• With high confidence, the two credit card harvesting campaigns observed can be linked in to one campaign, with these shared TTPs and IoCs.
• Phishing delivery methods, including chat functionality and email with shortened URLs.
• Implementation of Domain Fronting, such as through Cloudflare and DDOS-Guard services.
• The attacker gained control over seller or buyer accounts (likely through InfoStealer) and provided all purchase-related information to enhance the phishing's authenticity.
• Crafting a convincing phishing page that replicates the legitimate site using its underlying code.
• Developing custom functions to address issues related to failed credit card transactions and input submission and verification.
• Incorporating a Chat Support feature to bolster the phishing page's authenticity.
• Common TLS certificate issuers are typically R3 and GTS CA 1P5.

Ensuring Your E-Commerce Safety

For user, both as sender and seller, make sure to follow these recommendations to ensure the safety of your account.

·         Beware of Phishing Attempts: Be cautious of emails, chat messages, text, or pop-up ads that request personal or financial information. Legitimate companies will never ask for sensitive information via email or messages. If in doubt, contact the company directly using their official contact information.

·         Use Online Tools for Verification: consider using online tools like urlscan.io or VirusTotal to scan suspicious URLs or files. These tools can help you identify potentially harmful websites or downloads.

·         Report Suspicious Activity: If you suspect that a seller or a buyer is engaging in fraudulent behavior, report it to the platform's support center. They can investigate and take appropriate action.

·         Use Strong Passwords: Create strong, unique passwords for your online shopping accounts. Avoid using easily guessable information, like your name or birthdate. Consider using a password manager to generate and store complex passwords securely. Never reuse the same password.

·         Implement Multi-Factor Authentication (MFA): Enable MFA on your accounts whenever it's an option. MFA adds an extra layer of security by requiring you to provide a second piece of information (e.g., a one-time code sent to your phone) in addition to your password.