Dai trojan che automatizzano i bonifici dentro la sessione autenticata, overlay e abuso dell’accessibilità, secondo il modello Malware-as-a-Service di DroidBot, emerge il limite di un dibattito incentrato sull’OTP e sulla colpa dell’utente. Le difese di piattaforma (Google Play Protect) e le nuove regole europee (Verifica del Beneficiario, DORA) alzano l’asticella ma non coprono il livello decisivo: la sicurezza dell’app finanziaria.
La tesi del contributo è che l’hardening lato-client, a cominciare dal blocco degli overlay da parte di altre app, sia parte integrante della «misura idonea» che il prestatore di servizi di pagamento deve dimostrare ai sensi del D.Lgs. 11/2010, con effetti diretti sull’onere della prova e sulla valutazione della colpa grave.
Indice degli argomenti
Dallo smishing all’automazione on-device
La narrazione dominante delle frodi bancarie su mobile è ancora quella del phishing: un SMS che imita la banca, una pagina civetta, una telefonata che induce la vittima a comunicare la one-time password. In quello schema la discussione giuridica ruota attorno alla condotta dell’utente e alla soglia della colpa grave, perché è l’utente a “consegnare” la credenziale.
Le cifre confermano la centralità di questo schema. Secondo il «Rapporto sugli esposti dei clienti delle banche e delle finanziarie» della Banca d’Italia (giugno 2026), nel 2025 gli esposti per truffa sono stati 750, in aumento del 2% sull’anno precedente; poco meno della metà riguarda il furto delle credenziali di accesso, dei codici di autenticazione delle operazioni o dei dati identificativi della vittima, e in questo ambito il 57% dei casi ha fatto leva su tecniche di ingegneria sociale, smishing, vishing e phishing. È la fotografia di un fenomeno ancora dominato dall’inganno dell’utente.
Una parte rilevante della minaccia, però, si è spostata altrove. Nei trojan bancari più evoluti l’OTP non viene consegnato: viene intercettato, mentre l’operazione è pilotata direttamente sul dispositivo. Il vettore tipico è l’abuso dell’AccessibilityService di Android. Si tratta di una funzione nata per l’accessibilità che consente al malware di leggere il contenuto delle schermate e di eseguire tocchi e gesti in automatico, compilando e confermando un bonifico all’interno della sessione già autenticata dall’utente. È la tecnica nota come ATS (Automated Transfer System), spesso combinata con finestre di overlay per catturare le credenziali e con l’intercettazione di SMS e notifiche per sottrarre i codici monouso.
Un campione reale analizzato di recente in un contesto peritale illustra bene il modello. Si presentava con nome e icona di un’applicazione legittima di largo uso, ma con un nome di pacchetto generato in modo casuale e una firma di debug, non una firma di distribuzione. Il solo elenco dei permessi costituiva la catena della frode: servizio di accessibilità, disegno di finestre in sovrimpressione, lettura, ricezione e invio di SMS con richiesta di diventare l’app di messaggistica predefinita, amministrazione del dispositivo per la persistenza, e un canale di comando e controllo basato su protocollo MQTT. Nel codice comparivano i riferimenti tipici dell’automazione via accessibilità, lettura dei nodi a schermo e generazione programmatica di gesti. L’archivio, infine, era confezionato con un flag anomalo che induce molti strumenti di analisi a rifiutarne la lettura, pur restando perfettamente installabile ed eseguibile dal sistema: un accorgimento anti-analisi. Questi permessi, accessibilità, lettura SMS, accesso alle notifiche, sono gli stessi che le piattaforme oggi considerano ad alto rischio proprio perché consentono di intercettare gli OTP e osservare lo schermo.
Un campione con queste caratteristiche è riconducibile alla categoria dei RAT bancari distribuiti come Malware-as-a-Service (MaaS). Il riferimento più attuale è DroidBot, documentato da Cleafy nel dicembre 2024: un trojan di accesso remoto venduto in abbonamento a circa 3.000 dollari al mese a diversi gruppi affiliati, dotati di un builder per generare build su misura ed eludere il rilevamento. DroidBot combina overlay, keylogging, intercettazione degli SMS e automazione delle interazioni (ATS), e presenta una caratteristica distintiva: la comunicazione a doppio canale, con esfiltrazione dei dati via MQTT e ricezione dei comandi via HTTPS. È un inquadramento utile, ma va tenuta ferma la distinzione tra compatibilità e attribuzione: la sola sovrapposizione di tecniche non dimostra la famiglia, lo stesso canale MQTT, per esempio, è stato osservato anche nei trojan Copybara e BRATA, e l’attribuzione richiede il riscontro della configurazione (broker e topic), dei canali di comando e delle firme note. È il tipo di rigore probatorio che distingue una classificazione difendibile da un’etichetta affrettata.
La minaccia, peraltro, non è monolitica. Accanto ai trojan “pesanti” con overlay e accessibilità, la ricerca di Cleafy ha documentato nel 2025 una campagna attiva in Italia denominata SuperCard X: una piattaforma malware-as-a-service che, sfruttando la tecnologia NFC in modalità relay, consente di autorizzare pagamenti e prelievi fraudolenti facendo “avvicinare” la carta al telefono infetto. È il rovescio della medaglia: un malware volutamente minimale, privo di permessi rischiosi e di overlay, disegnato per restare sotto la soglia dei controlli euristici. Due traiettorie opposte che convergono su un punto: una parte della frode bypassa del tutto i presidi lato-server.
Cosa fa già il sistema operativo (e perché non basta)
La piattaforma ha reagito. Secondo quanto riferito da Google, la protezione anti-frode di Play Protect analizza in tempo reale le app installate da fonti di sideloading, browser, file manager, messaggistica, e ne blocca l’installazione quando dichiarano permessi sensibili come ricezione e lettura degli SMS, accesso alle notifiche e accessibilità, tipicamente abusati per sottrarre codici e spiare lo schermo. La funzione è stata estesa da un pilota iniziale a 185 mercati, arrivando a coprire oltre 2,8 miliardi di dispositivi; con Android 16 si aggiungono protezioni durante l’installazione e l’attivazione dell’accessibilità nel corso di una telefonata, oltre all’invito automatico a interrompere la condivisione dello schermo al termine della chiamata.
Sono misure significative, ma restano a livello di sistema operativo: dipendono dalla versione di Android, dalla configurazione, dal fatto che l’utente non forzi manualmente l’installazione. Non sostituiscono ciò che l’applicazione finanziaria può e, si può sostenere, dovrebbe fare per proteggere le proprie schermate sensibili. Il presidio di piattaforma riduce la superficie, non la azzera.
Cosa dovrebbe fare l’app finanziaria
Qui il tema diventa concreto e verificabile, perché esistono contromisure standardizzate. Il progetto OWASP Mobile Application Security, nella sua guida al testing (MASTG), elenca una gerarchia esplicita di difese contro overlay e tapjacking. La più robusta è la dichiarazione del permesso HIDE_OVERLAY_WINDOWS e la chiamata a setHideOverlayWindows(true), disponibile da Android 12 (API 31), che nasconde tutte le finestre di sovrapposizione non di sistema mentre l’app è in primo piano; in subordine, e per retrocompatibilità, il filtraggio dei tocchi quando la vista è oscurata (filterTouchesWhenObscured) e il flag FLAG_SECURE sulle schermate sensibili. Va ricordato che da Android 12 il sistema già blocca per impostazione predefinita gli attacchi a piena occlusione, con l’avvertenza che per le finestre di allerta di sistema il blocco opera solo oltre una certa soglia di opacità.
C’è però una sfumatura che va detta con onestà tecnica, ed è ciò che distingue un’analisi seria da uno slogan: bloccare gli overlay è necessario ma non sufficiente. L’abuso dell’accessibilità non “disegna” necessariamente una finestra sopra l’app: legge l’albero delle viste e inietta azioni, aggirando i normali flag anti-overlay. Per questo un’app che gestisce denaro dovrebbe anche monitorare in modo continuo i servizi di accessibilità attivi sul dispositivo, adottare il binding al dispositivo per impedire il riuso altrove delle credenziali sottratte, e ricorrere a meccanismi di attestazione dell’integrità e di auto-protezione a runtime. In altre parole, impedire le sovrapposizioni è la soglia minima, non l’intera difesa.
La cornice regolatoria: verifica del beneficiario e resilienza operativa
Sul piano europeo, il Regolamento (UE) 2024/886 sui pagamenti istantanei ha introdotto — inserendo l’art. 5-quater nel Regolamento (UE) 260/2012 — la Verifica del Beneficiario (Verification of Payee), obbligatoria nell’area euro dal 9 ottobre 2025 per i bonifici in euro, istantanei e ordinari. Il sistema confronta l’IBAN indicato con il nome del beneficiario e restituisce un esito (corrispondenza, corrispondenza parziale, mancata corrispondenza, verifica non possibile). È un presidio utile, ma per esplicita scelta del legislatore ha natura informativa e non blocca l’operazione: la decisione finale resta al cliente. Soprattutto, la verifica contrasta l’IBAN spoofing “a monte”, quando è l’utente a digitare il beneficiario; contro un attacco ATS che opera all’interno della sessione autenticata, manipolando l’operazione sul dispositivo, la sua efficacia è molto più limitata. È un altro argomento a favore di un presidio lato-client.
Sul piano della resilienza, il Regolamento (UE) 2022/2554 (DORA), applicabile dal 17 gennaio 2025, impone alle entità finanziarie un quadro di gestione del rischio ICT che valorizza la sicurezza sin dalla progettazione. È una cornice entro cui l’irrobustimento dell’applicazione mobile può essere letto non come un optional, ma come componente di un obbligo più generale di solidità operativa (l’esatta portata applicativa va verificata caso per caso).
Il nodo giuridico: “misura idonea” e onere della prova
Nel sistema delineato dal D.Lgs. 11/2010, in caso di operazione di pagamento disconosciuta, sul prestatore di servizi di pagamento grava anzitutto l’onere di provare che l’operazione sia stata autenticata, correttamente registrata e contabilizzata e che non abbia subito le conseguenze di malfunzionamenti o altri inconvenienti. La mera registrazione dell’utilizzo dello strumento di pagamento non è tuttavia, di per sé, sufficiente a dimostrare che l’operazione sia stata autorizzata dal pagatore, né che questi abbia agito con dolo o colpa grave. L’orientamento dell’Arbitro Bancario Finanziario ha inoltre chiarito che la prova dell’autenticazione forte costituisce un prius logico rispetto alla valutazione della colpa grave: la sua mancanza, anche solo parziale, è dirimente e conduce al rimborso; ove invece l’intermediario intenda opporre al cliente il dolo o la colpa grave, deve fornire elementi di fatto specifici dai quali tale condotta possa essere desunta, anche in via presuntiva (Collegio di Coordinamento ABF n. 22745/2019). Anche la giurisprudenza di legittimità, dopo una prima fase in cui aveva accostato la posizione della banca a una forma di responsabilità quasi oggettiva, ha adottato un approccio più equilibrato, escludendo la responsabilità dell’intermediario in presenza di colpa grave del cliente (tra le altre, Cass. n. 7214/2023 e n. 3780/2024), fermo restando che tale colpa richiede un’imprudenza inescusabile e può essere provata mediante presunzioni gravi, precise e concordanti. Su questa linea si colloca un orientamento di particolare rilievo per gli scenari qui descritti: la mera riconducibilità tecnica dell’operazione al dispositivo dell’utente non basta a qualificarla come autorizzata. Quando è il frodatore a predisporre l’operazione e la vittima si limita a confermarla — con una notifica push, la biometria o un codice — credendo di validare un’azione legittima, manca il consenso libero e consapevole richiesto dall’art. 5 del D.Lgs. 11/2010, e l’operazione non può dirsi autorizzata (in tal senso, tra le decisioni recenti, Collegio ABF di Milano n. 3501/2025). È un principio che incide in modo diretto sugli attacchi ATS via malware, nei quali l’autenticazione risulta formalmente regolare sul dispositivo del cliente ma non esprime alcuna sua reale volontà dispositiva.
La chiave interpretativa che qui proponiamo è duplice. Primo: l’adeguatezza delle misure di sicurezza non dovrebbe essere valutata soltanto sul versante dell’autenticazione, ma anche alla luce della capacità dell’applicazione di resistere a modalità di attacco note, tecnicamente documentate e contrastabili mediante presidi disponibili secondo standard riconosciuti. In questa prospettiva, l’hardening dell’applicazione, comprese le contromisure anti-overlay e anti-abuso dell’accessibilità codificate da OWASP come buone pratiche, può concorrere alla valutazione dell’idoneità complessiva delle misure adottate dal prestatore. Secondo: nell’attacco ATS la condotta dell’utente va riqualificata. Se l’OTP non è consegnato ma intercettato, e l’operazione è automatizzata da un servizio di accessibilità abusato, la valutazione della colpa grave non può appiattirsi sullo schema del phishing classico. È un profilo che la stessa giurisprudenza arbitrale sta declinando: nelle frodi da social engineering l’ABF tende a escludere la colpa grave in assenza di indici concreti di anomalia percepibili dall’utente, orientamento che, nello scenario dell’ATS via malware, in cui nulla viene “consegnato” e nessuna anomalia è visibile, risulta ancor più stringente per l’intermediario (tra le decisioni recenti, Collegio di Roma nn. 8658/2025 e 10894/2025).
Una responsabilità condivisa
La sicurezza dei pagamenti mobili è un sistema a più livelli: l’utente, la piattaforma, la banca. Concentrare il giudizio sul solo anello umano, o affidarsi al solo sistema operativo, lascia scoperto proprio il livello che dispone del denaro. La domanda giusta, tecnica prima ancora che giuridica, non è unicamente “cosa doveva fare l’utente”, ma “quale baseline di sicurezza è ragionevole attendersi da un’applicazione che muove fondi”. Rispondere a questa domanda, con standard verificabili e non con formule generiche è, oggi, parte integrante della misura idonea.
Fonti
Banca d’Italia, Rapporto sugli esposti dei clienti delle banche e delle finanziarie (giugno 2026) — dati 2025 su segnalazioni di truffa e tecniche di furto delle credenziali; ripreso da Il Sole 24 Ore, 25 giugno 2026
Google, Keeping Google Play & Android app ecosystems safe in 2025 — security.googleblog.com / blog.google
Google, What’s new in Android security and privacy in 2025 — blog.google (protezioni Android 16 su sideloading, accessibilità in chiamata, condivisione schermo)
OWASP Mobile Application Security, MASTG-BEST-0040: Preventing Overlay Attacks e MASTG-KNOW-0022 — mas.owasp.org
Android Developers, Tapjacking (security/risks) — developer.android.com
Cleafy Labs, DroidBot: insights from a new Turkish MaaS fraud operation (dicembre 2024) — cleafy.com
Cleafy Labs, SuperCard X: exposing a Chinese-speaker MaaS for NFC Relay fraud operation (2025) — cleafy.com
Regolamento (UE) 2024/886 (pagamenti istantanei; art. 5-quater Reg. (UE) 260/2012); Banca d’Italia, scheda sulla Verifica del Beneficiario (VoP)
Regolamento (UE) 2022/2554 (DORA)
D.Lgs. 27 gennaio 2010, n. 11 (recepimento PSD2); Direttiva (UE) 2015/2366 (PSD2) — artt. 10-11-12 su onere della prova e responsabilità per operazioni non autorizzate
Arbitro Bancario Finanziario — Collegio di Coordinamento n. 22745/2019 (onere della prova/colpa grave); Collegio di Roma nn. 8658/2025 e 10894/2025 (frodi da social engineering) — banca dati arbitrobancariofinanziario.it
Corte di Cassazione, ordinanza n. 7214/2023 e sentenza n. 3780/2024 (esclusione della responsabilità della banca in caso di colpa grave del cliente); per l’orientamento anteriore, nn. 10638/2016, 2950/2017, 9158/2018
Banca d’Italia, Rapporto sulle operazioni di pagamento fraudolente in Italia nel 2° semestre 2024 (agosto 2025)
G. (Diritto Bancario), Le frodi informatiche negli ultimi orientamenti dell’ABF — dirittobancario.it (rassegna degli orientamenti; estremi delle singole decisioni da riscontrare)
Partecipa alla community