Negli ultimi anni il phishing rivolto ai cittadini italiani ha iniziato a cambiare forma. Non ci troviamo quasi più davanti alla classica email con un link palesemente sospetto o al messaggio sgrammaticato che promette un’eredità improvvisa.

Il modello sta diventando sempre più articolato e segue una sequenza a tappe.

pagina falsa → portale → procedura → acquisizione dell'identità → raccolta di dati e credenziali.

Da questa evoluzione nasce l'esperimento “La PA fantasma” condotto da MC Project Lab. L'obiettivo non era costruire un semplice elenco di siti già segnalati, ma rispondere a una domanda concreta.

È possibile riconoscere e collegare automaticamente i segnali tipici dei falsi servizi digitali della PA, anche quando il dominio non compare ancora nei registri di sicurezza?

Per rispondere abbiamo realizzato e collaudato MC Project Lab Site Trust Analyzer. Il risultato più interessante della ricerca non è stato un successo immediato, ma un fallimento controllato che ci ha spinto a riscrivere l'architettura di analisi.

Quando il phishing diventa un servizio digitale

Le campagne osservate contro cittadini e servizi pubblici mostrano una trasformazione evidente. Il falso sito non si limita a chiedere nome utente e password su una pagina statica, ma simula un vero percorso digitale a tappe.

  • identificazione simulata dell'utente;
  • inserimento guidato di dati personali e anagrafici;
  • caricamento di documenti di riconoscimento con controllo del formato;
  • richiesta di credenziali SPID o CIE;
  • inserimento di informazioni bancarie o dati della carta;
  • finti moduli di pagamento o finte schermate di rimborso;
  • download mirato di file o applicazioni in base al dispositivo;
  • reindirizzamento verso i veri portali istituzionali per nascondere il furto dei dati.

Il problema non riguarda soltanto la somiglianza grafica con un sito istituzionale. Occorre osservare il comportamento della pagina. Un dominio sospetto è un segnale; un dominio sospetto che imita un ente pubblico è un segnale più forte; se quella stessa pagina contiene un modulo interattivo che tenta di acquisire credenziali o informazioni finanziarie, il contesto cambia radicalmente. È sulla combinazione di questi elementi che abbiamo concentrato il lavoro.

I casi reali documentati e l'anatomia dei falsi portali

Prima di entrare nel dettaglio tecnico, è utile guardare i casi documentati nel 2026 dalla Polizia di Stato e dal CERT-AgID. Non parliamo di ipotesi teoriche, ma di attacchi concreti e operativi.

Panoramica dei casi documentati di impersonificazione digitale della PA italiana · Selezione verificata su fonti CERT-AgID 2026
Figura 1 · Selezione dei casi documentati di impersonificazione digitale della Pubblica Amministrazione italiana analizzati nel dossier (Fonti CERT-AgID, Polizia di Stato e perizie forensi 2026).
Nota sul metodo. I casi mostrati nell'infografica non indicano per forza un autore comune. Gli indicatori di compromissione, le somiglianze tecniche e l'attribuzione a un gruppo specifico sono livelli di analisi separati. Una correlazione tecnica non costituisce mai attribuzione.

Site Trust Analyzer

Site Trust Analyzer è nato come strumento di analisi passiva degli indirizzi web. La prima versione controllava le caratteristiche esterne senza toccare il server, esaminando dominio, TLD, parole chiave istituzionali, punycode, elenchi di domini ufficiali, indicatori noti, record DNS, certificati di sicurezza TLS e dati RDAP.

In un secondo momento abbiamo integrato l'analisi Page-Aware. All'interno di un ambiente isolato, senza inviare dati, senza accedere con account e senza eseguire file, il programma valuta diversi elementi.

  • la struttura del codice della pagina;
  • la presenza e la composizione di moduli interattivi;
  • i campi destinati all'inserimento di password, PIN o credenziali SPID;
  • le funzioni per caricare file e documenti;
  • gli script di tracciamento e i collegamenti a server esterni;
  • l'uso di marchi istituzionali abbinato a richieste di dati riservati.

Abbiamo infine affiancato un motore di raggruppamento (Campaign Cluster Engine). Il suo compito non è stabilire chi stia materialmente dietro lo schermo, ma chiarire se due siti sospetti presentino abbastanza elementi tecnici comuni da appartenere alla stessa campagna. Anche in questo ambito vale una regola fondamentale, ovvero che la vicinanza tecnica non dimostra la paternità dell'attacco.

Pilot 01 e il primo risultato

La prima versione del motore (v0.5.0) è stata provata su un gruppo di 27 casi. Con la soglia di allarme standard (punteggio pari o superiore a 25), i numeri apparivano molto positivi.

  • 8 True Positive, 0 False Positive, 15 True Negative, 3 False Negative;
  • Precision al 100%  |  Specificity al 100%  |  Accuracy all'88,5%.

C'era però un grosso limite di metodo. I sette casi reali di phishing usati nella prova erano già registrati tra gli indicatori noti del sistema, mentre i siti istituzionali erano già protetti dall'elenco ufficiale dei domini fidati. Il test confermava che il software riconosceva ciò che aveva già visto in precedenza, ma non garantiva la capacità di scoprire minacce nuove nel mondo reale.

Pilot 02 e la prova senza aiuti

Nel secondo esperimento abbiamo tolto ogni vantaggio. Nessun indicatore storico per le minacce di prova e nessuna lista di siti protetti per i controlli normali. Abbiamo preparato un gruppo cieco di 40 casi, formato da 15 minacce sconosciute, 15 controlli normali non protetti e 10 casi trappola (pagine legittime con parole come SPID, fisco o tributi, inserite apposta per verificare la comparsa di falsi allarmi).

La prova si è svolta alla cieca sulla versione congelata (v0.5.0rc1), e il motore ha mostrato subito i suoi limiti.

  • 10 True Positive, 2 False Positive, 23 True Negative, 5 False Negative;
  • Precision all'83,3%  |  Recall al 66,7%  |  Falsi positivi all'8,0%;
  • Punteggio massimo assegnato a una minaccia sconosciuta pari a 44 punti.

L'esito dei controlli del Defense Lab ha imposto lo stop della versione (PILOT 02 FAIL · CALIBRATION REQUIRED), bloccando il rilascio di v0.5.0rc1.

Perché il fallimento è stato utile

Il test alla cieca ha portato alla luce tre problemi pratici che le prove precedenti non avevano mostrato.

  1. Falsi allarmi causati dal testo. Un sito informativo accumulava punti di rischio solo perché conteneva parole come “SPID” o “password” negli articoli. Parlare di credenziali, però, non significa sottrarle.
  2. Punteggi troppo bassi per le minacce sconosciute. Senza l'aiuto degli elenchi di siti già noti (+55 punti), una minaccia nuova con moduli aggressivi non riusciva a superare quota 44. Poiché la fascia di pericolo alto partiva da 50, il programma non riusciva a segnalare le pagine nuove come ad alto rischio.
  3. Difficoltà nel collegare siti gemelli senza rete esterna. Senza connessioni remote, il motore di raggruppamento faticava a riconoscere modelli grafici identici con testi leggermente modificati, fermandosi al 37% di somiglianza invece di superare la soglia forte del 75%.

Dagli errori alla versione 0.6

Invece di rimediare aggiungendo a mano i 5 casi sfuggiti (scorciatoia che avrebbe reso il software poco affidabile davanti a nuove varianti), abbiamo mantenuto intatta la versione di base e ripensato il funzionamento interno di Site Trust Analyzer v0.6.0 con quattro interventi mirati.

1. Valutazione combinata dei segnali

Il motore osserva se diversi segnali compaiono insieme. Un richiamo a un ente pubblico da solo non basta, e nemmeno un modulo web qualsiasi. Quando però l'imitazione di un marchio istituzionale si unisce a campi per raccogliere credenziali fuori dai domini ufficiali, scatta una regola combinata (+20 punti) che porta subito il punteggio nella fascia di rischio alto (70–74 punti), anche se il dominio è del tutto sconosciuto.

2. Controllo reale dei moduli di inserimento

La presenza di parole delicate come SPID, password o IBAN nel testo editoriale non viene più considerata rischiosa se nella pagina manca un modulo interattivo per inviare dati. Descrivere una procedura non equivale a rubare informazioni. Il peso dei domini generici privi di form è stato inoltre ridotto da 6 a 4 punti.

3. Riconoscimento automatico delle trappole nei campi

L'analisi guarda da vicino le caratteristiche dei singoli campi di testo per individuare i meccanismi tipici di raccolta dati, senza dipendere dal nome del sito.

4. Raggruppamento più preciso e pulizia del codice

Nel confronto tra pagine abbiamo rimosso i tag generici comuni a ogni sito web, che facevano sembrare collegate pagine del tutto diverse. In questo modo il calcolo della somiglianza si concentra solo su elementi tecnici davvero rilevanti.

La prova decisiva su un gruppo di casi mai visti

Per verificare che i progressi fossero reali e non dipendessero da regole preparate su misura, abbiamo messo alla prova la versione v0.6.0 su 40 casi del tutto nuovi, mai utilizzati durante lo sviluppo né nella calibrazione (15 minacce sconosciute, 15 controlli normali e 10 casi trappola).

Risultati Comparativi Sperimentali (Site Trust Analyzer v0.6.0 GA)

Metrica v0.5.0rc1 Baseline (Pilot 02) v0.6.0 Pilot 02 Replay v0.6.0 Unseen Blind Holdout
Precision 83,3% 100,0% 90,0%
Specificity 92,0% 100,0% 96,0%
Falsi Positivi (FP) 2 su 25 0 su 25 (Azzera FP) 1 su 25 (FPR 4%)
Hard Negatives (Casi Trappola) 8/10 superati 10/10 superati 10/10 superati (100%)
Score Massimo Minaccia Ignota 44 (Tetto bloccato in Attention) 70 (Fascia HIGH) 74 (Fascia HIGH)
Detection a Soglia HIGH (≥ 50) 0,0% (0/15) 53,3% (8/15) 40,0% (6/15)
Benchmark Cluster Engine 5/10 superati 10/10 superati (100%) 10/10 superati

Verdetto RELEASE GATE APPROVED · MCPL Site Trust Analyzer v0.6.0 GA. Sviluppo completato e certificato con registro SHA-256 su 60 file tracciati, comprensivo di prove ed evidenze di collaudo.

Il 60% non è il 100% e i limiti reali della difesa

Questo è il punto centrale di tutta la ricerca. Site Trust Analyzer non rileva tutte le minacce sconosciute. Nel test finale ne ha individuate 9 su 15 (con un tasso di rilevamento del 60%). Le restanti 6 minacce ignote, prive di indizi espliciti o costruite come semplici pagine informative senza form attivo, non hanno raggiunto la soglia di allarme.

Per questo motivo non presentiamo il software come una protezione infallibile e non interpretiamo il 96% di specificità come un dato miracoloso. Quel valore descrive un fatto preciso. Nel gruppo di prova il sistema ha riconosciuto correttamente 24 siti normali su 25, riducendo sensibilmente i falsi allarmi e superando tutti i 10 casi trappola. I numeri fotografano quel banco di prova, quella configurazione offline e quei 40 casi, non l'intera rete internet.

Collegare senza attribuire

Assieme al rilevamento abbiamo perfezionato il motore di raggruppamento. I dieci controlli previsti sono stati superati tutti. Due pagine graficamente identiche con testi leggermente modificati, che nella versione precedente si fermavano al 37% di somiglianza, raggiungono ora il 78,4%. Allo stesso tempo, pagine che condividono solo il server o singole immagini comuni ma hanno un codice del tutto diverso restano ferme al 25%, evitando collegamenti errati.

L'approccio resta volutamente prudente. Lo strumento può evidenziare che due pagine mostrano forti somiglianze tecniche, ma non può e non deve sostenere che appartengano allo stesso autore. Dare un nome ai responsabili richiede indagini sul campo e riscontri giudiziari.

Un metodo di verifica rigoroso

Questo lavoro ha consolidato un percorso chiaro, che parte dall'analisi delle minacce, passa attraverso i test ciechi e si conclude con il rilascio finale. Nel secondo collaudo abbiamo introdotto verifiche pensate apposta per mettere in crisi il programma invece di confermarne le risposte. Quando il sistema ha sbagliato, non abbiamo ritoccato i punteggi né abbassato i requisiti. Abbiamo accettato l'errore, lo abbiamo usato come punto di partenza e ne abbiamo misurato la correzione su dati del tutto nuovi.

Cosa abbiamo imparato

La ricerca consegna una conclusione chiara. Non esiste un singolo indicatore capace di smascherare un falso servizio pubblico. Un indirizzo insolito non basta, un logo ufficiale non basta, il protocollo di sicurezza HTTPS non basta, la scritta SPID non basta e un modulo di contatto non basta. Conta soltanto la combinazione simultanea di più segnali tecnici indipendenti.

Continueremo a lavorare su questa impostazione. L'obiettivo non è creare algoritmi che pretendano di emettere giudizi assoluti o indiscutibili, ma costruire strumenti difensivi capaci di avvisare con trasparenza quando su una pagina compaiono abbastanza anomalie da meritare attenzione immediata.

Fonti primarie e documentazione ufficiale

← Torna agli articoli Contatta il Defense Lab