A victim in Central Europe spent 13 minutes on the phone with someone claiming to be from their bank. By the time the call ended, they'd installed two pieces of malware, taken out a loan they didn't request, and given fraudsters the ability to stream their payment Cardholder Data to a fake merchant terminal. Every transaction that followed was approved using the victim's own PIN.
This isn't a hypothetical scenario. It's a documented attack chain involving WindRelay, an Android malware that performs NFC relay attacks, and SpyNote, a remote access trojan. Group-IB researchers traced 23 WindRelay samples uploaded to VirusTotal between November 2025 and July 2026, targeting victims in Czechia, Slovakia, and Slovenia.
Here's what failed, which controls could have stopped it, and what your team needs to do now.
What Happened
The attack combined three distinct capabilities: social engineering, remote device access, and NFC relay fraud.
The fraudster initiated contact by phone, impersonating the victim's bank. They convinced the victim to install an app, which was SpyNote. The app's builder toolkit allowed the attacker to customize the label to show the victim's own name, making it appear legitimate.
Once SpyNote granted remote access, the fraudster installed WindRelay without further victim interaction. WindRelay uses NFC to communicate with the physical payment card while the victim still holds it. The malware relays that NFC exchange over the internet to a fake merchant terminal controlled by the attacker. The fraudster then initiated transactions using the victim's own PIN, which the victim had entered themselves during the guided "verification" process.
Group-IB identified four command-and-control IP addresses tied to the NFC relay activity. Multiple samples were customized with victim-specific names and interface text matching the target country's language.
Timeline
Minute 0-3: Initial phone contact. Fraudster establishes trust by claiming to represent the victim's bank and describing a fabricated security issue.
Minute 3-8: Victim downloads and installs SpyNote, following step-by-step instructions. The app's personalized label (showing the victim's own name) reduces suspicion.
Minute 8-10: SpyNote grants remote access. Fraudster installs WindRelay silently. WindRelay requests NFC access, contact list access, and system-inspection permissions.
Minute 10-13: Fraudster uses remote access to open the victim's mobile banking app and initiates a loan. Simultaneously, WindRelay begins streaming Cardholder Data to the attacker's fake terminal.
Post-call: Unauthorized card transactions appear on the victim's account.
Which Controls Failed or Were Missing
Mobile device security: The victim's device allowed installation of applications from unknown sources. No mobile device management (MDM) or mobile threat defense (MTD) solution was present to flag SpyNote's dangerous permission requests or WindRelay's NFC relay behavior.
User authentication controls: The bank's mobile app relied on device-based authentication without behavioral biometrics or anomaly detection. The app couldn't distinguish between the legitimate account holder and a fraudster with remote access.
Transaction monitoring: Real-time fraud detection systems didn't flag the sudden loan origination or the pattern of card-present transactions occurring while the victim was on a phone call with supposed bank staff.
NFC security: The payment card itself had no mechanism to detect or prevent relay attacks. Standard EMV contactless transactions don't include distance-bounding protocols that could identify the relay.
Caller verification: The victim had no secure channel to verify the caller's identity. The bank hadn't implemented callback procedures or provided customers with a dedicated fraud-verification number.
What the Standards Require
Payment Services Directive 2 (PSD2) mandates strong customer authentication for electronic payment transactions, requiring Multi-Factor Authentication that includes at least two independent elements. Remote access to a device compromises this requirement because the attacker controls the authentication environment.
PCI Mobile Payment Acceptance Security Guidelines require that mobile payment applications implement controls to detect jailbroken or rooted devices, verify app integrity, and protect against reverse engineering. These controls would have flagged SpyNote's modification of the device environment.
NIST SP 800-63B defines authenticator assurance levels. The mobile banking app in this incident appears to have relied on Level 1 authentication (single-factor), which NIST explicitly states is insufficient for high-value transactions. Level 2 requires proof of possession and control of two distinct authentication factors.
The FFIEC IT Examination Handbook states that financial institutions should implement layered security and anomaly detection. A loan origination immediately following a security-related customer service call should trigger manual review.
EMV Payment Tokenisation Framework recommends token-based transactions for mobile payments to limit exposure of Primary Account Number (PAN) data. If implemented, WindRelay would have relayed a single-use token rather than the actual card credentials.
Lessons and Action Items for Your Team
Implement behavioral biometrics in your mobile apps. Track typing patterns, swipe behavior, and device angle. Remote access tools can't replicate these patterns. When behavior deviates from the user's baseline during a high-risk action like loan origination, step up authentication or block the transaction.
Deploy mobile threat defense across your customer base. MTD solutions detect remote access trojans, monitor for malicious NFC activity, and flag apps requesting excessive permissions. Partner with your mobile banking vendor to integrate MTD into your app or recommend specific MTD apps to customers.
Add distance-bounding to your contactless acceptance. If you issue cards or operate terminals, implement relay-resistant protocols that measure the round-trip time of NFC communication. Relays introduce measurable latency that can be detected.
Create a verified callback process. Train customers to hang up and call your institution back using the number on their card or statement, never a number provided by the caller. Include this guidance in your account opening materials and fraud awareness communications.
Monitor for transaction-call correlation. If your fraud detection system can access call center logs, flag any transaction occurring within 30 minutes of a customer service interaction, especially if that interaction involved security topics. This pattern is a strong Indicator of Compromise.
Require step-up authentication for loan origination. Any credit extension should trigger out-of-band verification, such as a push notification to a separate device or an SMS to a pre-registered number. Don't rely solely on in-app authentication when the device may be compromised.
Educate customers on permission requests. Publish clear guidance on which permissions your legitimate apps will never request. System-inspection permissions and NFC access for a banking app should raise immediate red flags.
The WindRelay campaign shows that fraudsters don't need to steal your card anymore. They just need 13 minutes of your time and your willingness to follow instructions. Your controls need to assume the device is hostile and the user is being manipulated. Build your defenses accordingly.
