Executive Summary

The D3Lab team analyzed an Android application distributed through a Deutsche Bank phishing campaign. Victims are prompted to enter their phone number, then instructed to “update” their banking app by downloading a malicious APK named deutsche.apk. The APK presents itself as “Support Nexi” and guides the user through a fake “card verification” flow: bring the card near the phone, keep it close while “authenticating,” and enter the card PIN. Under the hood, the app reads NFC card data (ISO‑DEP) and exfiltrates it to a remote WebSocket endpoint.

Based on consistent internal artifacts (package naming, classes, messages, and UI flow), we assign this new cluster the family name NFCShare.

Distribution: Deutsche Bank phishing flow

The infection chain starts with a bank‑themed phishing site mimicking Italian Deutsche Bank. The victim is asked for a mobile number and then told to update the bank app. The “update” is delivered as an APK (deutsche.apk). After installation, the app claims to be “Support Nexi” and drives the user through a fake security verification designed to harvest NFC card data and the card PIN.

What the app does (user flow)

The UI is implemented as a local HTML/JS page loaded into a WebView:

• Step 1: “Bring your card close”
• Step 2: “Keep the card near the phone while authentication completes”
• Step 3: PIN collection (4 or 6 digits)

This matches a typical NFC‑relay/harvesting workflow: capture card data via NFC and request the PIN to enable fraudulent transactions.

Technical analysis highlights

1) NFC reading and card data extraction

The app uses android.nfc.tech.IsoDep (ISO‑DEP/ISO 14443‑4) to communicate with payment cards and builds a CardInfoitmanteis object containing:

• Card number
• Card type
• Label
• Expiration date

The data is serialized into a string format:

number & type & label & MM/yy

2) Network exfiltration via WebSocket

The app connects to a WebSocket endpoint and sends JSON messages containing NFC data. The connection string is obfuscated and resolved at runtime.

ws://38[.]47[.]213[.]197:7068/

3) String obfuscation (NPStringFog)

Strings are XOR‑encoded and decoded using a hardcoded key:

Sample decoding (from smali):

const-string v0, "1E07544A584359495D43405746434F565043545247465948"
invoke-static {v0}, Lobfuse/NPStringFog;->decode(Ljava/lang/String;)Ljava/lang/String;

=> "ws://38[.]47[.]213[.]197:7068/"

Why we call it NFCShare (family attribution)

We chose the family name NFCShare because of consistent internal naming and behavior:

• Namespace/strings: nfc.share.* appears in internal package paths and resources.
• Function: the malware’s core purpose is to “share” (exfiltrate) NFC card data to a remote server.

Supporting internal artifacts:

• Package/namespace: nfc.share.itnamteis.*
• Strings: nfc.share and other NFC‑related UI text
• Channels: CARD_INFO_CHANNEL, CARD_REMOVED, SEND_CHANNEL in internal enums

This naming is stable across the codebase and better reflects the malware’s core behavior than the external branding (“Support Nexi”).

Links to known Chinese‑linked tooling and related families

We observed several indicators suggesting a Chinese‑linked operator or tooling lineage:

• The app embeds Chinese text such as 发送端 (“sender”).
• String obfuscation and naming patterns are consistent with Chinese Android malware tooling.

We also note the following contextual overlap reported by defenders:

• The C2 IP was associated with SuperCardX activity in November 2025.
• The flow is conceptually similar to RelayNFC as analyzed by Cyble (Brazil‑targeting NFC relay malware).

IOCs

Hashes

• SHA‑256: afbe6751d339fbc5b7bddd29429a11740e82fef935a61acaf2fe5487444dbed4

Package / App

• com.modol.nap
• App label: Support Nexi

Network

• ws://38[.]47[.]213[.]197:7068/
• portale-deut[.]com