NFCShare: The Campaign Turning GitHub Into a Distribution…

NFCShare steals payment-card data via NFC and captures PINs through spoofed banking apps hosted on GitHub. The European campaign produced more than 50 unique APKs in a single month.

{"main_topic":"malware","topics":["malware","cybersecurity","phishing","nfc","android"]}

NFCShare is an Android malware active since January 2026 that radically scaled up starting May 14, 2026, expanding from Deutsche Bank alone to an archipelago of Italian and Spanish institutions. The qualitative shift isn't just in targeting — it's in the choice to host payloads on GitHub through a repository disguised as a school project, with 57 commits and 56 unique APKs documented by early June 2026.

Key Takeaways

NFCShare extracts payment-card data via EMV commands over NFC and captures the PIN through a socially engineered WebView interface.
The GitHub repository 'app-scuola', created April 10, 2026 according to BleepingComputer, functioned as an automated pipeline with scripted commits and APK names mirroring legitimate banking apps.
Impersonated brands include Intesa Sanpaolo, Banca Sella, Fideuram, Nexi, Mooney, BCC Roma, and CaixaBank, per data collected by d3Lab.
Recent builds introduce malformed ZIP paths to block automated extraction, moving from 8 to 10 DEX files compared to earlier versions.

The GitHub Pipeline: A School Project Hiding Banking APKs

The 'app-scuola' repository represents an evolution in mobile malware distribution. This isn't simple static hosting: d3Lab researchers documented a structure with 57 commits and an update flow resembling CI/CD pipeline automation. The recurring commit message, 'Updated everything,' suggests systematic scripting rather than sporadic manual uploads. The README presented the app as a school assignment, lowering perceptual defenses against automated checks or community reports.

APK filenames precisely mirror legitimate apps: IntesaCarte.apk, SellaCarte.apk, CaixaBank.apk. This isn't aesthetic — it's functional, reducing the victim's cognitive dissonance at the moment of sideload installation. The repository was created April 10, 2026, preceding the campaign expansion documented from May 14, 2026 by a month.

Once installed, the app presents a WebView interface simulating a card verification procedure. The victim is induced to place their payment card near the smartphone. At that point, the malware invokes the native Android android.nfc.tech.IsoDep APIs to establish an ISO-DEP session with the card's EMV chip.

The APDU (Application Protocol Data Unit) commands included PPSE (Proximity Payment System Environment) selection, a standard EMV protocol step to identify payment applications present on the card. From technical findings published by GBHackers based on d3Lab research, parsing of response data extracts the PAN (Primary Account Number), expiration date, card type, and issuer label. The PIN, not retrievable via NFC, is captured separately through the same WebView interface under the pretext of a security check.

"The fundamental attack method hasn't changed much, but the operation behind it has become more refined and evasive" — d3Lab report via CyberSecurityNews

Evasion and Anti-Analysis: When Packaging Becomes a Weapon

Recent NFCShare builds introduce a technique rarely seen in consumer Android malware: intentionally malformed ZIP paths. Archive entries are rooted under directories named /AndroidManifest.xml/ and /classes.dex/ — names that violate APK structural conventions. This doesn't prevent manual analysis — as researchers note — but increases friction against automated extraction tools and lowers family-matching scores in more fragile analysis systems. The DEX file count has risen from 8 to 10 in the latest versions, indicating a growing codebase that may reflect added functionality or further obfuscation layers.

Comparison With the NFC Malware Ecosystem: Kinship Without Identity

d3Lab researcher Andrea Draghetti explicitly compared NFCShare with known families such as NGate, SuperCard X, and RelayNFC. His assessment, reported by BleepingComputer, is technical and cautious: "NFCShare uses distinct code, libraries, architecture, and implementation details... it could still represent an evolution of the same ecosystem, driven by the same threat actors." At present, no infrastructure overlaps — C2 servers, domain names, staging patterns — conclusively link NFCShare to these families.

The documented exfiltration address is ws://nfck[.]loseyourip[.]com:8001/, a WebSocket endpoint receiving data assembled in strings separated by & characters. The package namespace, nfc.share.itnamteis, and the internal model CardInfoitmanteis serve as consistent family attribution markers across analyzed samples.

What to Do Now

Review detection filters for automated commit patterns on public GitHub repositories hosting APKs with institutional names, especially combined with educational-context READMEs.
Update APK analysis sandboxes to handle malformed ZIP paths with entries rooted under manifest and DEX filenames, avoiding extraction failures that would hide the threat.
Monitor WebSocket traffic to non-HTTPS endpoints on non-standard ports, particularly connection patterns from applications with the nfc.share.* namespace or anomalous background NFC behavior.
Strengthen customer awareness campaigns on sideloading risks even when the apparent source is a recognized development platform like GitHub, and on requests for physical card placement for "security checks."

Frequently Asked Questions

Does NFCShare exploit an Android zero-day vulnerability?

No. The malware does not use security exploits but relies on social engineering and sideloading. The victim voluntarily installs the APK, often after receiving a phishing link or a phone walkthrough from a supposed bank operator, as documented by sources.

Why was GitHub chosen as the distribution platform?

GitHub offers infrastructure reliability, free hosting, and a reputation that reduces automatic suspicion. The school-project disguise adds a layer of social plausibility that purpose-registered domains wouldn't guarantee.

Can the stolen data be used for contactless transactions?

The dossier does not specify whether extracted data has actually been used in NFC relay attacks or physical cloning. Full EMV data combined with the PIN theorizes this possibility, but no source documents confirmed fraudulent transactions.

Information has been verified against cited sources and is current as of publication.

Sources

Sources and references

Get DeafLetter