NFC Relay and Ghost Tap: The New Payment Fraud Chain
Most mobile fraud techniques are variations on stealing a credential and using it elsewhere. NFC relay is different, and the difference is why it has moved so quickly from research curiosity to an identified fraud category.
It does not steal a card number to be used later. It borrows a real card, in real time, on a victim’s own phone, and spends it somewhere else at the same moment.
How the Chain Works
The attack is a chain rather than a single technique, and every link is ordinary. That is what makes it effective.
1A call that sounds legitimate. The victim is contacted by someone presenting as their bank, often with the bank’s own number displayed and with details about the victim already in hand.
2An app installed outside the store. The victim is guided to install something carrying the bank’s name and branding, delivered by link rather than through an official store.
3Accessibility permission granted. The victim is talked through granting it. From this point the attacker can read the screen and act on the device.
4A second app installed silently. Using that permission, a relay tool is installed with no further interaction and nothing visible to the victim.
5The card is relayed. The victim is asked to hold their physical card against the phone and enter its PIN. The contactless data is relayed live to a device held by the attacker, at a terminal or ATM elsewhere.
In one documented case the sequence completed in about thirteen minutes, and included the attacker remotely operating the victim’s genuine banking app to arrange a loan in their name before relaying the card.
Why This Is Being Tracked as a Category
The European Payments Council’s payment threats and fraud trends reporting identifies NFC relay and the related Ghost Tap technique as a rising fraud category, frequently overlapping with remote access scams.
Two developments turned it from a technique into an industry. Relay capability is now packaged and resold as a subscription service, so an operator needs no technical ability. And the same criminal infrastructure that distributes banking trojans distributes this, which means it reaches victims through channels that already work.
Why the Usual Controls Do Not See It
| Control | Why it misses this |
| Card fraud analytics | The card is genuine, present and PIN-verified. The transaction is contactless and correct |
| Device fingerprinting | The banking session runs on the victim’s own registered device |
| Multi-factor authentication | The victim completes it themselves, prompted by the caller |
| App store review | Neither malicious app was distributed through a store |
| Customer education | The caller knew the victim’s details, and the app carried the bank’s branding |
Every signal your systems read during this attack is genuine. The only thing wrong is who is directing the phone.
What Can Actually Detect It
The chain has one property worth exploiting: it requires conditions on the device that your app can observe while they are happening.
An accessibility service reading your app. This is the hinge of the whole attack. An app that detects an accessibility service interacting with sensitive screens sees step three, before the relay tool exists.
A sideloaded app carrying your identity. The first app is a copy or an impersonation of yours. Integrity and signature verification means a repackaged build refuses to run at all.
Remote operation of a genuine session. When the attacker drives your real app, the input is synthetic. Overlay detection, screen capture blocking and detection of automated interaction are what surface it.
Environment conditions. Hooking frameworks, injected libraries and instrumentation frequently accompany the relay component.
Where SecIron Fits
Detection at the hinge of the chain
IronWall detects malicious accessibility services, overlay attacks, screen capture, hooking and injection, and repackaged builds carrying your brand. Because these are the conditions the chain depends on rather than a named malware family, detection does not require having seen this particular tool before.
Response is configured per condition by you, so an accessibility service on a payment screen can block that screen while other activity continues. Explore IronWall
Seeing the campaign, not the case
Relay fraud arrives in campaigns targeting one institution at a time. IronSky logs every detection in real time with attack source tracing and device fingerprinting, so a cluster is visible while it is running rather than in next quarter’s loss analysis.
Conclusion
NFC relay is worth understanding not because it is exotic but because it is the clearest example of a broader shift. The attacker no longer tries to defeat the bank’s controls. They recruit the customer, operate inside a legitimate session, and let every control report that everything is fine.
Against that pattern, the app is not one more layer of defence. It is the only witness.
Ready to meet your banking standards?
Talk to us about what your app can currently detect while a session is being driven by someone else. We will assess your current release and show you what changes.
Recent Posts
Guide: Protecting Mobile Apps Against Malware
October 29, 2026
Use Cases: Three Real Attack Scenarios from SecIron Deployments
October 29, 2026
Solutions
Resource
About Us