P4nD3m1CB0Y0xD

P4nD3m1CB0Y0xD

Just a nerd that loves to learn about malware

PhantomCard? Why NFC rhymes with USB?

6 minute read

Executive Summary

PhantomCard is an NFC relay-style Android threat that now integrates USB smart‑card reader support, indicating an evolution from purely proximity attacks to physical skimming. The app uses a WebView to socially engineer card taps and capture PINs, then relays EMV APDU traffic in real time over WebSocket to attacker-controlled infrastructure. While attribution to the original PhantomCard family is not yet confirmed, code behavior and relay mechanics suggest shared tooling or lineage with broader “fraud engine” ecosystems.

Business impact:

  • Increases risk of real‑time card data and PIN compromise, enabling higher‑value fraudulent transactions.
  • Expands attacker operational models to include compromised or gang-aligned merchant devices, or fraudster-owned phones with USB readers.

image00.jpg

Introduction

In August 2025, Threat Fabric documented a new NFC-based Android malware dubbed PhantomCard. This Android malware was observed targeting Brazilian users. For more information about that, you can find it here.

Recently, one of my hunting rules triggered what seems to be a new variant of this malware family. So far, I can’t ensure that this variant is related to the primary PhantomCard. But I attribute it with HIGH confidence. Based on the similarities.

Another point to highlight is that, based on what I have been following about this type of threat, there exist different “fraud engine toolkits” that implement this NFC relay attack functionality. Some other examples can be found in the blog post made by Resecurity showing how the growing search for this type of engine is growing in the underground.

This new variant calls my attention because it implements the capability to read a physical card using a USB device such as Gemalto. This is a possible indication that threat actors are evolving their modus operandi to perform physical fraud or even more elaborate skimming.

Sample Information:

SHA256: d79c24c70a0806514ed9b228afe795723ec88a212c2042eb0dd764dd403c4ba9

Package ID: com.billy.cardemv

Application Name: Proteção cartão

Technical Analysis

AndroirManifest.xml

The permissions required by this sample are forward. It just requires, Internet connection and access to the NFC hardware.

<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.NFC"/>

It also requires that the infected device have the NFC hardware interface. Otherwise, it pops up a toast with an error message, seeing that the device does not support NFC.

<uses-feature android:name="android.hardware.nfc" android:required="true"/>

This application has three activities:

  • com.billy.cardemv.CardBankActivity - Web phishing and PIN exfiltration
  • com.billy.cardemv.MainActivity - Relay setup and connection
  • com.billy.cardemv.Tela2Activity - Local test of card communication
<activity
  android:theme="@style/Theme.CardEMV"
  android:name="com.billy.cardemv.CardBankActivity"
  android:exported="true">
  <intent-filter>
      <action android:name="android.intent.action.MAIN"/>
      <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
  <intent-filter>
      <action android:name="android.nfc.action.TECH_DISCOVERED"/>
  </intent-filter>
  <meta-data
      android:name="android.nfc.action.TECH_DISCOVERED"
      android:resource="@xml/nfc_tech_filter"/>
</activity>
<activity
  android:theme="@style/Theme.CardEMV"
  android:name="com.billy.cardemv.MainActivity"
  android:exported="false"
  android:launchMode="singleTop">
  <intent-filter>
      <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"/>
  </intent-filter>
  <meta-data
      android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"
      android:resource="@xml/device_filter"/>
</activity>
<activity
	android:theme="@style/Theme.CardEMV" 
	android:name="com.billy.cardemv.Tela2Activity"
	android:exported="false"
/>

Let’s start our analysis in the CardBankActivity activity.

CardBankActivity

InitComunication Method

After the main activity starts and sets up some configurations, it calls the InitCommunication method.

image1.png

In the blue box, as mentioned before, it checks to see if the device supports NFC. In the yellow box, it checks if the NFC is enabled. Otherwise asks the user to enable it. The green box sets up the ISO-DEP configuration and initializes the RelayClientIsoDep class with the command and control URL, using WebSocket with the IP address and port 181.41.200[.]116:1285 and the session ID. Then it calls the checkCardPresenceOnStart method, which is used to check the card proximity.

And the interesting aspect of this variant is shown in the red box. The malware checks if a USB device with the vendor ID 2278 and the product ID 13367 is connected to the device. Those IDs is related to Gemalto USB smart card readers. Normally used by fraudsters. Below is an example of such a device:

image2.png

This makes me wonder: why do they implement this feature?

Other interesting characteristics present at this class are:

WebView endpoint:

  • At port 3000, the WebView is present, used to deceive the victim into putting the card near the device.
  • Below is an example of the WebView with the message “Waiting for card - Bring your cell phone closer to the card”:

image3.png

PIN harvesting:

  • The JSBridge class monitors the WebView and extracts the pin parameter from URLs (if (currentUrl.contains("pin="))). The value is sent to relayClient.sendPin(pin).

Hardware interaction:

  • Interacts with NFC (IsoDep) and USB smart card readers (Gemalto devices) to intercept APDU (Application Protocol Data Unit) commands, the same data format used in EMV chip communication.

Session tracking:

  • Uses sessionId = "Santa_" + android_id, which uniquely identifies the victim device.

C2 relay:

  • At port 1285 is used to exfiltrate the card data over the relay.
  • The RelayClientIsoDep object manages communication with the remote server, relaying card commands/responses.
  • Captured APDU commands, card ATRs, and PIN codes are transmitted over WebSocket to the attacker’s server.

MainActivity

When a USB smart card reader (Gemalto device) is plugged in, the system detects the device and triggers the intent android.hardware.usb.action.USB_DEVICE_ATTACHED. Android checks all declared intent filters for this action. It finds this activity (MainActivity) and launches it automatically.

MainActivity.onCreate() runs automatically upon USB reader connection. It:

  • Requests permission for the device.
  • Creates a WebSocket connection to C2 (ws://181.41.200[.]116:1285).
  • Initializes the RelayClientIsoDep channel.
  • Starts CardBankActivity programmatically via goToScreen2().

Tela2Activity

This class provides direct, low-level USB communication with a smart card reader.

This activity has no intent filters, meaning it cannot be launched by the system or external apps. It’s invoked manually (most likely for debugging or internal testing by the developer). It directly interacts with the Gemalto card reader via USB endpoints, sending the standard EMV SELECT 2PAY.SYS.DDF01 APDU command.

Why?

As I said before, this new feature makes me wonder why and how this can be used to perform fraud. Here are just some of my assumptions about how this changes the modus operandi for NFC-based frauds.

Based on my analysis of the code, each seems that the “malware” was developed to run on the fraudster’s device or some enticed merchant. Of course, it can also run on the victim’s device by jumping straight to the WebView phishing and performing only the NFC Relay.

This indicating an evolution from purely proximity attacks to physical skimming.

Here are some reasons for USB priority:

  • Higher Reliability: Physical contact ensure successful reads
  • Complete Data Access: All chip data available via contact
  • Professional Operations: USB readers indicate organized fraud
  • POS Scenarios: Better suited for fixed installations attacks

Again, these are some of my assumptions on how this can be leveraged by threat actors. So far, it hasn’t observed any scenery of that.

Hunting for more

First, I want to thank the @500mk500 for spotting 3 other infrastructure-related to this threat.

image4.jpg

Another interesting observation from interacting with the malicious infrastructure is that, at port 3001, we can observe a live dashboard.

image5.png

Conclusion

The observed PhantomCard variant blends classic NFC relay with direct USB smart card reader support (Gemalto VID 2278, PID 13367), indicating an evolution from purely proximity-based attacks to scenarios that enable physical skimming and lab-style testing. The app funnels victims through a WebView to capture PINs, relays APDU exchanges over WebSocket to a remote C2, and uniquely tags sessions, creating an end‑to‑end pipeline for real-time EMV data theft. While attribution to the original PhantomCard family is not yet confirmed, functional overlap and relay mechanics suggest a close lineage or shared “fraud engine” components. Defenders should monitor for USB reader intents, NFC IsoDep activity tied to web relays, and outbound websocket traffic to suspicious endpoints, and raise user awareness around PIN prompts in embedded web views.

IoCs:

You may also enjoy