ESET researchers uncovered a crimeware campaign that targeted clients of three Czech banks. The malware used, which we have named NGate, has the unique ability to relay data from victims’ payment cards, via a malicious app installed on their Android devices, to the attacker’s rooted Android phone.

Key points of this blogpost:

• Attackers combined standard malicious techniques – social engineering, phishing, and Android malware – into a novel attack scenario; we suspect that lure messages were sent to random phone numbers and caught customers of three banks.
• According to ESET Brand Intelligence Service data, the group has operated since November 2023 in Czechia, using malicious progressive web apps (PWAs) and WebAPKs. In March 2024 the group’s technique improved by deploying the NGate Android malware.
• Attackers were able to clone NFC data from victims’ physical payment cards using NGate and relay this data to an attacker device that was then able to emulate the original card and withdraw money from an ATM.
• This is the first time we have seen Android malware with this capability being used in the wild.
• Victims didn’t have to root their devices.

The primary goal of this campaign is to facilitate unauthorized ATM withdrawals from the victims’ bank accounts. This was achieved by relaying the near field communication (NFC) data from the victims’ physical payment cards, via their compromised Android smartphones by using the NGate Android malware, to the attacker’s device. The attacker then used this data to perform ATM transactions. If this method failed, the attacker had a fallback plan to transfer funds from the victims’ accounts to other bank accounts.

We haven’t seen this novel NFC relay technique in any previously discovered Android malware. The technique is based on a tool called NFCGate, designed by students at the Technical University of Darmstadt, Germany, to capture, analyze, or alter NFC traffic; therefore, we named this new malware family NGate.

Overview

Victims downloaded and installed the malware after being deceived into thinking they were communicating with their bank and that their device was compromised. In reality, the victims had unknowingly compromised their own Android devices by previously downloading and installing an app from a link in a deceptive SMS message about a potential tax return. A short description of this attack is available in the video below.

It’s important to note that NGate was never available on the official Google Play store.

NGate Android malware is related to the phishing activities of a threat actor that operated in Czechia since November 2023. However, we believe these activities were put on hold following the arrest of a suspect in March 2024.

We first noticed the threat actor targeting clients of prominent Czech banks starting at the end of November 2023. The malware was delivered via short-lived domains impersonating legitimate banking websites or official mobile banking apps available on the Google Play store, as illustrated in Figure 1. These fraudulent domains were identified through the ESET Brand Intelligence Service, which provides monitoring of threats targeting a client’s brand. During the same month, we reported our findings to our clients.

Victimology

During our investigation, we identified six different NGate apps specifically targeting clients of three banks in Czechia between November 2023 and March 2024.

In a substantial breakthrough, the Czech police apprehended a 22-year-old, who had been stealing money from ATMs in Prague. Upon arrest, the suspect had 160,000 Czech korunas in his possession, an amount equivalent to over 6,000 euros (approximately US$6,500). The nationality of the arrested individual has not been disclosed. According to the Czech police, the money recovered from the suspect was stolen from just the last three victims, so it is likely that the total amount stolen by the threat actor behind this scheme is considerably higher.

Evolution of attack scenarios

The attackers leveraged the potential of progressive web apps (PWAs), only to later refine their strategies by employing a more sophisticated version of PWAs known as WebAPKs. Eventually, the operation culminated in the deployment of NGate malware.

It is important to note that in all of the attack scenarios described here, the victim’s device doesn’t need to be rooted, only the attacker’s device that emulates the received NFC traffic.

Progressive web apps

Initially, these fraudulent websites misused PWA technology. This technology allows a user to install an app from a website via a supported browser; the installation can be triggered either automatically through a pop-up notification or manually by selecting the Install app option from the browser’s menu. On Android, supported browsers include Chrome, Firefox, Edge, and Opera. Once installed, a new icon featuring a small browser logo in the bottom right corner is added to the smartphone’s home screen, basically serving as a website link. An example is shown in Figure 2, where we compare the icon of a PWA on the left side with an icon of a standard app on the right side.

PWAs are essentially a type of app, but unlike traditional apps that are downloaded and installed from an app store, PWAs are accessed and used directly within a web browser. They are built using common web programming languages such as HTML (for structure), CSS (for design), and JavaScript (for interactivity), which are the same technologies used to create websites. PWAs are known for their compatibility and flexibility, as they are designed to work on any device that has a standards-compliant web browser. This means that a user, whether on a desktop computer, laptop, tablet, or smartphone, can access the same PWA without needing to download a separate app for each device.

If a PWA is installed from a phishing website, its icon is likely to mimic that of a legitimate banking application, with the slight addition of a small browser icon. Upon launching this malicious PWA, a full-screen phishing website is displayed that requests the user’s banking credentials.

WebAPKs

Subsequently, the threat actor improved on this attack scenario, continuing to target clients of the same banks as before but employing a more advanced type of PWA known as a WebAPK. WebAPKs are Android apps that are automatically generated by the Chrome browser when users add a PWA to their Android device’s home screen. To distinguish between these two, PWAs are apps built using web technologies, while WebAPKs use a technology to integrate PWAs as native Android apps. What’s different about WebAPKs is that they appear more like native Android apps than typical PWAs, because their icons do not have the small browser logo that PWA icons have. This absence of a browser logo can lead a user to mistakenly believe that a malicious WebAPK is a legitimate app, as illustrated in Figure 3.

The distribution scheme stayed the same – users were able to download and install a standalone app from phishing websites, instead of merely a PWA web shortcut. The WebAPK requires manual installation; however, the user is not requested to grant explicit permission to install apps from unknown sources or to allow the browser to install unknown apps, as this is not a regular app. Because of that, users might not be aware that they are installing an app from an untrusted source. Figure 4 shows an example of what it looks like when users visit a phishing website that asks them to update and install a malicious WebAPK.

Once it is installed and opened, the malicious app requests banking credentials. More details about phishing campaigns that use PWAs and WebAPKs were discussed in our previous blogpost.

NGate malware

On March 6th, 2024 we discovered that NGate Android malware became available on the same distribution domains that were previously used to facilitate phishing campaigns delivering malicious PWAs and WebAPKs.

After being installed and opened, NGate displays a fake website that asks for the user’s banking information, which is then sent to the attacker’s server. In addition to its phishing capabilities, NGate malware also comes with a tool called NFCGate, which is misused to relay NFC data between two devices – the device of a victim and the device of a perpetrator. The NFCGate tool was developed by students from the Secure Mobile Networking Lab at the Technical University of Darmstadt in Germany and is available on GitHub. NFCGate’s main function is to transmit an NFC signal from one Android device through a server to another Android device that can mimic or emulate it, as depicted in Figure 5.

NFCGate is a tool that can interact with NFC traffic on a device. On the device where NFCGate is installed, it can:

1. Capture NFC traffic from apps that use NFC.

2. Pass along or relay this NFC data from one device to another.

3. Mimic or replay data it has previously intercepted, on the other device.

Some of these features work only on rooted devices; however, relaying NFC traffic is possible from non-rooted devices as well. The NGate malware misuses only one of NFCGate’s features. It doesn’t interfere with other data that is available on the compromised device, and doesn’t try to mimic it. It abuses NFCGate only to pass along NFC data from one device to another.

However, NGate also prompts its victims to enter sensitive information like their banking client ID, date of birth, and the PIN code for their banking card. It also asks them to turn on the NFC feature on their smartphone. Then, victims are instructed to place their payment card at the back of their smartphone until the malicious app recognizes the card.

What’s happening behind the scenes is that the NFC data from the victim’s bank card is being sent through a server to the attacker’s Android device. Essentially, this allows the attacker to mimic the victim’s bank card on their own device. This means the attacker can now use this copied card data on their Android device to make payments and withdraw money from an ATMs that use NFC.

Full attack scenario with a backup solution

The announcement by the Czech police revealed the attack scenario started with the attackers sending SMS messages to potential victims about a tax return, including a link to a phishing website impersonating banks. These links most likely led to malicious PWAs. Once the victim installed the app and inserted their credentials, the attacker gained access to the victim’s account. Then the attacker called the victim, pretending to be a bank employee. The victim was informed that their account had been compromised, likely due to the earlier text message. The attacker was actually telling the truth – the victim’s account was compromised, but this truth then led to another lie.

To “protect” their funds, the victim was requested to change their PIN and verify their banking card using a mobile app – NGate malware. A link to download NGate was sent via SMS. We suspect that within the NGate app, the victims would enter their old PIN to create a new one and place their card at the back of their smartphone to verify or apply the change.

Since the attacker already had access to the compromised account, they could change the withdrawal limits. If the NFC relay method didn’t work, they could simply transfer the funds to another account. However, using NGate makes it easier for the attacker to access the victim’s funds without leaving traces back to the attacker’s own bank account. A diagram of the attack sequence is shown in Figure 6.

Other possible attack scenarios

The utilization of NGate malware or a customized version of NFCGate opens up the possibility for more attack scenarios, particularly in situations where the threat actor has physical access and could potentially clone NFC tags or payment cards. To perform and emulate the following possible attacks, the attacker requires a rooted and customized Android device.

Gaining access via NFC tags

An NFC tag or token is a compact, contactless device that has the ability to store and transfer data. These tags can serve a variety of purposes, including identification and data transfer. NFC tags can be used as cards for public transportation, employee ID cards for access control in buildings, wearable health/patient monitoring devices, and so on.

Every NFC tag has a unique ID (UID) and a data section where keys are stored. When these tags are placed near a card reader, a handshake occurs, verifying that the tag has the correct keys for authorization. However, some readers only verify the UID of the token for authorization, bypassing the need for the keys. The UID is typically four bytes long.

Any non-rooted Android device can read NFC tags that comply with ISO/IEC 14443. However, only certain rooted Androids can emulate the UID of an NFC tag. Therefore, if a reader verifies only the token UID, it is possible to use NFCGate to relay and emulate the tag. If a reader requires also the keys (stored in the data section) for authentication, NFCGate is unable to copy them, making it impossible to clone an NFC tag in such a case.

This means that an attacker, either with physical access to a supported NFC tag or by tricking a user to position the tag at the back of the smartphone where this malicious app is installed, can duplicate the UID of the NFC access token. This can then be used to emulate the UID and gain access to restricted areas, buildings, workplaces, and similar areas.

During our testing, we successfully relayed the UID from a MIFARE Classic 1K tag, which is typically used for public transport tickets, ID badges, membership or student cards, and similar use cases. Using NFCGate, it’s possible to perform an NFC relay attack to read an NFC token in one location and, in real time, access premises in a different location by emulating its UID, as shown in Figure 7.

However, when we tried to emulate the UID, NFCGate sent different UIDs to the reader instead of the relayed UID. We discovered that our testing device (OnePlus 7 Pro) is on the list of devices that do not support UID cloning. As a result, we used the NFC Card Emulator Pro (Root) app and manually entered the UID to successfully clone it.

This attack scenario is highly targeted, meaning that the attacker needs to already know where the token can be used.

Small contactless payments via payment cards

In addition to the technique used by the NGate malware, an attacker with physical access to payment cards can potentially copy and emulate them. This technique could be employed by an attacker attempting to read cards through unattended purses, wallets, backpacks, or smartphone cases that hold cards, particularly in public and crowded places.

This scenario, however, is generally limited to making small contactless payments at terminal points, depending on the limit set by the bank that issued the card, not for ATM withdrawals, as the latter would require the attacker to have the card’s PIN.

Another theoretical scenario involves cloning a payment card stored in smartphone wallet apps. It is possible to relay the NFC signal from Android smartphones equipped with wallet apps, such as Google Wallet. However, as of April 2024, Google requires users to provide verification for every NFC payment. Therefore, even with an unlocked device, a user would still need to provide verification in the Google Wallet app before making a payment. Similarly, the Apple Wallet app also requests authorization before processing a payment. These security measures make it more challenging to relay and emulate payment cards from the Google and Apple wallet apps, using the NFCGate tool.

Technical analysis of NGate malware

Initial access

Initial access to the device is gained by deceiving the victim into installing a malicious app, often under the guise of a false assertion that there is an overpayment of income tax that the victim can reclaim. This request is typically delivered via SMS and we believe these messages were sent to random phone numbers. Unfortunately, we were not able to acquire samples of these SMS messages, and no screenshots were made publicly available by the Czech authorities.

Should victims download the app and enter their credentials, the attacker then initiates a phone call, posing as a bank employee. They inform the victims that their accounts have been compromised and advise them to change their PINs and verify their banking cards using a different app. This new app, provided via another SMS link, contains the NGate malware. None of the malicious apps we analyzed were available on Google Play.

We found two domains, mimicking the Czech Raiffeisenbank (as depicted in Figure 8) and the ČSOB bank, where NGate was available for download. At the time of writing, none of them were active:

• raiffeisen-cz[.]eu
• app.mobil-csob-cz[.]eu

Toolset

The NGate malware displays uniform characteristics across all six samples we analyzed. Each sample shares the same package name (rb.system.com) and utilizes the same hardcoded phishing URL that is distinctively identified with a unique ID (found in the key query parameter) to display specific web content. All samples were signed using the same developer certificate (SHA-1 fingerprint: 0C799950EC157BB775637FB3A033A502F211E62E). This consistent pattern across all six samples indicates a uniformity in their development and deployment.

All of the samples feature the same hardcoded phishing URL (https://client.nfcpay.workers[.]dev/?key=8e9a1c7b0d4e8f2c5d3f6b2); however, each app has a distinct key associated with it. This unique key corresponds to a specific banking phishing website that is displayed to the potential victim. The given link serves only as a redirection to the intended phishing website. From the samples analyzed, we were able to identify five distinct phishing websites, namely:

• rb.2f1c0b7d.tbc-app[.]life
• geo-4bfa49b2.tbc-app[.]life
• rb-62d3a.tbc-app[.]life
• csob-93ef49e7a.tbc-app[.]life
• george.tbc-app[.]life

The icon and name of each sample has been designed to mimic specific targeted banking apps, further enhancing their deceptive appearance.

Upon initiation, the NGate malware presents the victim with a phishing website within a WebView. A WebView is essentially a window or mini browser within the application itself. It’s used to display web content or web pages without having to leave the application or open a separate web browser. In this case, the website requests the user’s personal information, such as client ID and date of birth, as depicted in Figure 9.

The deceptive phishing website guides the victim to not only input the PIN code for their banking card, but also to enable the NFC feature on their device. The victim is then instructed to position their card on the backside of their smartphone, setting the stage for an NFC relay attack.

Unlike conventional malware, NGate doesn’t receive specific instructions from a Command and Control (C&C) server. Instead, the compromised device is controlled via the phishing website. This is achieved through the use of a JavaScript interface that triggers certain Android functions. These functions include retrieving information about the device such as the model and the NFC status, setting up a server to which the NFC traffic will be redirected, and initiating the NFC relay attack.

Figure 10 illustrates a code snippet of a function that is tasked with establishing an NFC relay server and enabling the device to read and then forward NFC traffic.

NGate uses two distinct servers to facilitate its operations. The first is a phishing website designed to lure victims into providing sensitive information and capable of initiating an NFC relay attack. The second is an NFCGate relay server tasked with redirecting NFC traffic from the victim’s device to the attacker’s. In our initial analysis of the NGate samples, we found that the NFC server could be set based on the response from the phishing website. However, in subsequent samples, these servers appeared to be hardcoded into the NGate malware.

If the victim follows all the instructions issued by NGate, it results in the attacker having the ability to relay the NFC traffic from the victim’s payment card. This enables the attacker to use the victim’s financial information to withdraw funds or make payments at contactless terminals.

Prevention

Ensuring safety from such complex attacks requires the use of certain protective steps against tactics like phishing, social engineering, and Android malware. These steps include:

• Checking the website’s authenticity. This can be done by looking at the URL to make sure the website isn’t a fake version of a genuine one.
• Only downloading apps from official sources, such as the Google Play store. This precaution significantly reduces the risk of unknowingly installing harmful software.
• Keeping payment card PIN codes secret. This important information should be kept safe at all times.
• Using security apps on mobile devices that can stop potentially unwanted software and malware, like NGate, from being downloaded and installed. These security apps add an extra layer of defense by continuously scanning and monitoring for threats.
• Turning off the NFC function on devices when it’s not needed. This step helps to prevent any unauthorized access or data transfer via NFC.
• Using protective cases or protectors for radio frequency identification (RFID) cards. By creating a barrier that blocks unwanted RFID scans, these can stop anyone from stealing NFC data from the card.
• Using digital versions of physical cards on smartphones. These virtual cards are stored securely on the device and can be protected by additional security measures, such as biometric authentication, making them a safer and more convenient alternative to traditional plastic cards.

Conclusion

ESET researchers have investigated a novel and unique attack scenario that combines well-known methods, such as phishing, with a new malware technique of relaying NFC traffic from victims’ physical payment cards to the attackers’ Android mobile device. Before transitioning to the new malware, which we named NGate, to relay NFC traffic, the attackers formerly used PWA, then WebAPKs, to steal the banking credentials of their victims. This evolution showcases the attackers’ determination and increased effort in executing their fraudulent operations.

While we have identified and thoroughly examined one specific attack scenario, it is crucial to note that theoretically there could be additional misuse cases. These could involve the cloning of physical cards or accessing NFC tokens, which could potentially amplify the threat and its impacts.

This crimeware campaign was focused on Czechia and is currently on hold, likely due to the arrest of a suspected perpetrator. However, the possibility of its expansion into other regions or countries cannot be ruled out. Additionally, the arrest of one participant with substantial cash on hand provides tangible evidence of the real-world consequences of these “virtual” crimes. Therefore, it is essential to remain aware of social engineering tactics, stay cautious online, and use robust mobile security apps.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

A comprehensive list of Indicators of Compromise (IoCs) and samples can be found in our GitHub repository.

Files

Network

MITRE ATT&CK techniques

This table was built using version 15 of the MITRE ATT&CK framework.