DevilNFC Targets European Banks as Chinese NFC Relay Monopoly Falls

For most of 2024 and into 2025, the business of NFC relay fraud ran through Chinese-controlled infrastructure. Malware-as-a-Service (MaaS, a subscription model that packages attack tooling for affiliates who lack the technical skill to build it) platforms like SuperCard X supplied pre-built relay engines to regional operators, keeping the dangerous engineering tightly concentrated. That concentration ended in 2026. Cleafy’s Threat Intelligence and Response (TIR) team has identified two new Android malware families, DevilNFC and NFCMultiPay, built from scratch by independent Spanish-speaking and Brazilian Portuguese-speaking groups respectively, and both are conducting live attacks against banking customers across Europe and Latin America.

Neither family shares code or infrastructure with the Chinese ecosystem they effectively displaced, and neither required a MaaS subscription to deploy. Local criminal crews now possess the full build capability, and generative AI helped them get there faster than any previous generation of mobile malware.

How a Chinese Monopoly on NFC Malware Ended

The architectural foundation for almost every NFC relay attack documented through 2025 traces back to NFCGate, the open-source NFC research framework developed by researchers at the Technical University of Darmstadt. Built to study NFC vulnerabilities in controlled environments, NFCGate found a second life in criminal tooling as groups discovered it could just as easily underpin a live attack chain. The ecosystem of families derived from it grew steadily: NGate, KingNFC, X-NFC, and related variants each repackaged the same relay core under new branding and distribution channels, but none reinvented the underlying mechanics.

SuperCard X, documented by Cleafy in April 2025 in a full analysis of the Chinese-speaking MaaS NFC relay operation, became the industrialized form of this approach. The platform promoted itself through Telegram channels, sold a two-application Reader/Tapper architecture to paying affiliates, and confirmed at least one active campaign in Italy. Chinese-speaking developers held the tooling layer and were not distributing source code. Paying a subscription and following an operational playbook was all an affiliate needed; the relay infrastructure was ready to deploy without touching the underlying build.

What changed in 2026 was not a new attack technique but a new economic reality. Open-source repositories hosting leaked malware code, combined with uncensored generative AI models that could help non-expert developers patch, extend, and localize that code, compressed a capability gap that had previously kept NFC relay development inside a small circle of technically sophisticated actors. Two independent regional groups reached build capability at roughly the same time, against the same target class, from opposite sides of the Atlantic.

DevilNFC’s Dual-Role Architecture

Victim Side: A Passive NFC Reader

On an unrooted victim device, DevilNFC behaves unremarkably. The application presents itself as a mandatory banking security update, requests minimal permissions, and passes basic automated security scans without triggering alerts. Its reader component uses standard Android NFC APIs to capture contactless payment card data when the victim taps their physical card against the device, staying below the detection threshold of most mobile security tooling.

Distribution begins with a phishing message, typically delivered via SMS or WhatsApp, that frames the download as an urgent requirement from the victim’s bank. The social engineering template is not embedded in the APK but fetched from the attacker’s command-and-control (C2) server at runtime, meaning the fraudulent banking interface can be swapped for a different institution’s branding without redeploying the application. Cleafy identified two C2 domains linked to DevilNFC operations: nfcrackatm.com and spicynagets.shop, both serving as relay server endpoints.

Attacker Side: A System-Level Card Emulator

The same APK transforms into something categorically more powerful when installed on a rooted attacker device. Using the Xposed Framework to inject hooks directly into Android’s NFC daemon, DevilNFC intercepts NFC traffic at the system level, well below the standard Android API layer where conventional detection operates. A derivative of the NFCGate relay core then converts the attacker’s hardware into a live host card emulator: the attacker’s phone presents the victim’s card data to any contactless point-of-sale (POS) terminal or ATM as though the physical card were present.

This asymmetric architecture sets DevilNFC apart within the threat class. A single APK carries both roles. Installed on different hardware configurations, it performs entirely different functions in the same attack. Security teams scanning the APK on a standard unrooted test device observe only the passive reader behavior; the emulation capability surfaces exclusively in the attacker’s rooted environment, making lab-based static analysis an unreliable detection method.

Kiosk Mode locks the victim’s screen from the moment the application launches, hiding the system UI and overriding the hardware back button with an empty handler. There is no way to exit the fraudulent banking interface while the relay session runs. A fake verification pop-up, rendered from a C2 template, prompts the victim to enter their PIN after the first card tap. That PIN is exfiltrated in plaintext to two simultaneous destinations: a dedicated C2 endpoint and the attacker’s private Telegram channel, transmitted alongside the bank name and the victim’s public IP address.

NFCMultiPay Takes a Simpler Path

Where DevilNFC deploys system-level hooking and requires a rooted attacker device, NFCMultiPay reaches the same outcome with considerably less infrastructure. Written entirely in pure Java with no native libraries and no root requirement on either device, it routes the NFC relay exchange through a cloud broker using event-driven MQTT (Message Queuing Telemetry Transport, a lightweight publish/subscribe protocol common in IoT applications) over TCP port 1883. This replaces the REST polling approach of earlier build versions and eliminates the latency gap that could interrupt a live relay transaction mid-authorization.

Its Brazilian developer fingerprint emerged through code archaeology rather than any direct attribution. Early NFCMultiPay builds contained Chinese log strings consistent with leaked codebases circulating in underground repositories, suggesting the group started by adapting an existing foundation. Later variants replaced every Chinese string with functional English and Portuguese equivalents, a build-over-build progression Cleafy analysts read as deliberate sanitization of operational origins. Two active C2 addresses were documented: 185.203.116.18 and 47.253.167.219.

NFCMultiPay does not employ device locking. Without the hard-stop that traps victims inside DevilNFC’s interface, it relies on continuous social engineering through a branded UI impersonating the target institution. The trade-off works in the operators’ favor: removing the root requirement on both devices dramatically broadens the pool of potential affiliates who can deploy it, and the absence of screen locking generates fewer behavioral anomaly alerts on devices running active security software.

AI Tools Lower the Build Barrier

Both families carry fingerprints of AI-assisted development, and those indicators are not subtle. Cleafy’s researchers flagged characteristics consistent with code generated or substantially modified by large language models (LLMs) running uncensored local variants that do not refuse requests to produce functional malware components. The result is first-generation malware that arrives technically over-engineered relative to what human developers typically ship on an initial build.

In April 2026, ESET independently confirmed the pattern when it identified a new NGate variant targeting Brazilian users whose injected code carried the same AI development indicators and Brazilian Portuguese strings observed in NFCMultiPay. Two research teams, working separately on different malware families in the same quarter, reached the same conclusion. That convergence removes most of the ambiguity about what is driving the capability shift.

Specific AI indicators identified across both families include:

• Over-engineered phishing templates in DevilNFC with complex conditional branching logic well beyond what a manual first-version build typically contains
• Emoji-formatted logging structures in NFCMultiPay, a stylistic pattern strongly associated with LLM output rather than human developer conventions
• Comprehensive edge-case error handling implemented consistently across both code bases, going well beyond functional minimums for initial malware releases
• In NFCMultiPay, systematic replacement of Chinese log strings with Portuguese equivalents across multiple consecutive builds, consistent with a prompted rewriting workflow rather than manual line-by-line editing

The Attack Chain, Step by Step

Both families follow the same general attack sequence, though DevilNFC applies more coercive mechanics at each stage. The full chain, as documented in Cleafy’s full research on DevilNFC and NFCMultiPay, runs as follows for the more advanced of the two families:

1. A phishing SMS or WhatsApp message prompts the victim to install a fake banking security update, framed as a mandatory requirement from the target institution.
2. On first launch, DevilNFC activates Kiosk Mode, collapsing the system UI and disabling the hardware back button. The victim is trapped inside the fraudulent banking interface with no standard exit path.
3. A fake card verification screen, fetched live from the C2 server, instructs the victim to hold their physical payment card against the phone. The NFC reader captures contactless card data silently.
4. A follow-up verification prompt requests the victim’s four-digit card PIN, exfiltrated in plaintext to both a dedicated C2 endpoint and a private Telegram channel, alongside the bank name and victim’s IP address.
5. A deliberately displayed error message instructs the victim to hold the card for an additional 10 seconds, extending the relay window and ensuring the fraudulent transaction has time to complete at the attacker’s terminal.
6. With relayed card data and a captured PIN, the attacker’s emulator device authorizes a transaction at a contactless POS terminal or ATM. The PIN capture removes any tap-limit ceiling on the fraud amount.

What Banks and Security Teams Face Now

The PIN capture detail sits at the center of why this threat class is more dangerous than standard NFC relay. Contactless payment limits in Europe typically sit near 50 euros, capping what an attacker holding only intercepted card data can achieve at a POS terminal. With a PIN acquired through the phishing interface, those limits dissolve entirely. Both families treat PIN collection as a baseline operational requirement, not an optional enhancement. Banks assessing NFC relay exposure purely against contactless transaction ceilings are measuring the wrong risk boundary.

Detection presents compounding challenges on multiple fronts. On victim devices, DevilNFC requests only standard NFC permissions and remains behaviorally passive until a card tap occurs, staying below the alert threshold of most mobile security tools. On attacker devices, the Xposed-based hooking approach operates at the system level rather than the application layer, complicating runtime detection without dedicated kernel-level monitoring. NFCMultiPay’s rootless design removes even the rooted-device requirement, narrowing the behavioral signals available to defenders and expanding the potential affiliate pool simultaneously.

The indicators documented by Cleafy, including the C2 domains and IP addresses, give security operations teams and banking fraud platforms a concrete starting point. But DevilNFC fetches its phishing templates from the C2 at runtime, meaning the fraudulent branding rotates independently of the APK. If the next regional crew, emboldened by the same open-source tools and the same AI assistance, ships a third independent family with entirely new infrastructure and zero shared indicators before defenders finish updating signatures for this one, the detection clock resets to zero.