Your fraud detection system just flagged a suspicious transaction. The customer's phone authenticated it, the PIN was correct, and the card's cryptographic data validated. But the purchase happened 200 miles from where the phone's GPS says it is.
You're likely facing an NFC relay attack and your next decision determines whether you catch it or miss it entirely.
The Decision You Are Facing
When your monitoring system identifies potential mobile-based card fraud, you need to determine which threat model you're defending against. NFC relay attacks and remote access trojans require different detection logic, response protocols, and customer communication strategies.
Group-IB documented a case where both attack types operated simultaneously: SpyNote provided device control while WindRelay relayed NFC Cardholder Data in real time. The entire fraud sequence completed in 13 minutes during a single phone call. Your detection window is narrow, and the wrong defensive posture leaves you blind.
Key Factors That Affect Your Choice
Three technical indicators separate these attack types:
Transaction velocity versus device behavior. NFC relay attacks generate card-present transactions that your authorization system sees as legitimate. The card's EMV cryptogram validates, and the PIN matches. But the phone's location, the merchant's location, and the cardholder's typical patterns don't align. Remote access trojans manipulate the banking app directly. You'll see loan applications, fund transfers, or account changes that don't require card-present authentication.
Permission requests in your mobile app telemetry. If your banking app collects permission-grant events, you can differentiate threats by what the malware requested. NFC relay malware needs NFC hardware access. Remote access tools need Accessibility Service permissions. SpyNote specifically requests camera, microphone, SMS, and overlay permissions. WindRelay requests NFC reader mode. The permission profile tells you which threat you're facing.
Time compression of fraud events. A single attacker using relay malware conducts transactions sequentially at physical terminals. You'll see purchases spaced minutes apart at different merchants. An attacker with remote device access executes multiple fraud types simultaneously: loan origination, P2P transfers, and card transactions all within the same minute. The parallelism is the signal.
Path A: Treat It as NFC Relay (When Card-Present Signals Validate)
Choose this path when:
- EMV cryptograms validate correctly
- PIN authentication succeeds
- Transaction occurs at a physical merchant terminal
- Device location and merchant location are geographically separated
- No unusual banking app activity precedes the transaction
Your response protocol:
Implement geographic radius checks between device GPS and merchant MCC. If your mobile app reports device location and the authorization request includes merchant location, calculate the distance. A card-present transaction where the device is 50+ miles from the merchant terminal warrants a step-up authentication challenge or outright decline.
Monitor for rapid merchant-category switching. NFC relay attackers often test the relayed Cardholder Data at multiple merchant types quickly. A sequence like gas station, electronics retailer, and grocery store within 20 minutes suggests an attacker moving between terminals with relayed data.
Trigger customer contact immediately, not after settlement. The 13-minute attack window Group-IB documented means your fraud analysts need real-time notification channels. SMS or push notifications asking "Did you just make a purchase at [merchant]?" must fire before the attacker completes additional transactions.
Don't rely solely on velocity rules. The attacker isn't generating unusual transaction volume; they're generating geographically impossible transaction locations with valid authentication data.
Path B: Treat It as Remote Access Trojan (When Banking App Shows Anomalous Behavior)
Choose this path when:
- Banking app session telemetry shows unusual permission grants
- Loan applications or credit line increases appear without prior customer inquiry
- Multiple transaction types occur simultaneously
- Device fingerprint changes (new OS version, rooted device indicators)
- SMS interception indicators appear (OTP codes read but not used by legitimate app)
Your response protocol:
Lock the account and force re-authentication through a separate channel. If SpyNote or similar RATs have Accessibility Service access, they control what the customer sees on screen. Your in-app alerts won't reach the customer. Call them directly using the phone number from account opening records, not the number currently registered in the app (the attacker may have changed it).
Review all account changes in the past 24 hours, not just transactions. Remote access trojans modify contact information, add external accounts for transfers, and change notification preferences. The financial loss might not appear in your transaction monitoring system; it might appear as a newly approved personal loan or a P2P transfer to a newly added payee.
Assume SMS-based MFA is compromised. SpyNote intercepts SMS messages. If your step-up authentication relies on SMS OTP codes, the attacker receives them in real time. Use app-based authentication (if you're certain the app itself isn't compromised) or voice call verification to a known-good phone number.
Check for sideloaded app indicators in your mobile SDK telemetry. If your banking app's SDK reports whether it was installed via Google Play or sideloaded, that's a critical signal. Group-IB noted the malware was distributed as a sideloaded APK with the victim's name in the app label to add false legitimacy.
Path C: Treat It as Combined Threat (When Both Indicators Appear)
Choose this path when:
- Card-present fraud and banking app manipulation occur within the same session
- Device shows both NFC access grants and Accessibility Service permissions to unknown apps
- Customer reports receiving a call from someone claiming to be from your bank
This is the WindRelay + SpyNote scenario. Your response must address both attack vectors simultaneously:
Immediately disable card-present transactions and freeze the account. You can't selectively block one fraud type while allowing the other. The attacker has both remote device control and the ability to relay Cardholder Data.
Document the social engineering vector in your Suspicious Activity Report. The attack Group-IB analyzed began with a phone call impersonating bank staff. If your customer reports receiving such a call, that's not just fraud; it's a coordinated attack that likely targeted multiple customers using the same script.
Coordinate with your mobile security team to identify the malicious app. If the customer still has the sideloaded APK installed, your incident response team needs the package name and hash. Group-IB identified almost two dozen WindRelay samples submitted to VirusTotal between November 2025 and July 2026. Your sample might be a variant.
Summary Matrix
| Indicator | NFC Relay | Remote Access Trojan | Combined Threat |
|---|---|---|---|
| EMV cryptogram validates | Yes | No | Yes |
| Geographic impossibility | Yes | No | Yes |
| Banking app manipulation | No | Yes | Yes |
| Accessibility Service granted to unknown app | No | Yes | Yes |
| NFC permission granted to unknown app | Yes | No | Yes |
| Social engineering call reported | Possible | Possible | Likely |
| Primary fraud type | Card-present purchases | Account takeover, loans | Both |
| Detection window | Minutes to hours | Hours to days | Minutes (13-minute case documented) |
| Effective MFA | App-based, biometric | Voice call to known number | Voice call only |
| Customer communication channel | In-app, SMS | Phone call to verified number | Phone call to verified number |
The decision tree isn't about choosing the most sophisticated response. It's about matching your defensive actions to the attacker's actual capabilities. Treat an NFC relay attack like a remote access trojan, and you'll waste time investigating app permissions while the attacker drains the card at merchant terminals. Treat a trojan like a relay attack, and you'll block card transactions while the attacker originates loans in the customer's name.
Your fraud rules engine needs logic for both. The 13-minute attack window means you don't have time to guess.
