Tesi sulla "Realizzazione di un workflow integrato per la rilevazione di domini phishing" di Giulia Milan (UniTs student)

1. UNIVERSITÀ DEGLI STUDI DI
TRIESTE
Dipartimento di Ingegneria e Architettura
Laurea triennale in Ingegneria Elettronica e
Informatica
Realizzazione di un workflow integrato per
la rilevazione di domini di phishing
17 settembre 2018
Laureando Relatore
Giulia Milan Chiar.mo Prof. Alberto Bartoli
Correlatore
Ing. Marco D’Orlando
Anno Accademico 2017/2018

2. «Looking back, we were the luckiest people in the world. There was no
choice but to be pioneers; no time to be beginners.»
— Margaret H. Hamilton —

3. Sommario
Obiettivo di questa tesi è stato trovare una tecnica efficace per contrastare
la continua evoluzione degli attacchi di phishing, a partire dall’analisi di
processi, strumenti e piattaforme presenti in Emaze S.p.A., dove è stato
svolto il lavoro presentato in questo elaborato.
Tali strumenti, indipendenti tra loro, forniscono quotidianamente al re-
parto SOC1 di Emaze una lista di oltre 100000 nuovi potenziali domini di
phishing. Tra questi, pochi sono risultati essere domini effettivamente di phi-
shing. Il tempo necessario per verificare l’intera lista di domini è significativo
e può richiedere l’impegno quotidiano di più tecnici.
Lo scopo principale del lavoro qui presentato è stato quello di costruire
un’integrazione tra tali strumenti, con lo scopo di:
• ridurre i domini erroneamente considerati di phishing, i falsi positivi,
all’interno della lista di domini ottenuti inizialmente;
• ridurre il tempo impiegato per verificare i domini da analizzare;
• massimizzare il numero di domini di phishing individuati, ossia i veri
positivi.
Tale integrazione, che sarà denominata flow, è stata poi automatizzata
allo scopo di avere delle statistiche puntuali e continue nel tempo.
Possibili sviluppi futuri includono l’implementazione dell’integrazione sui
server, la miglioria e ottimizzazione degli algoritmi utilizzati e la realizzazione
di un container Docker per esporre il servizio al pubblico.
1
Security Operation Center
i

4. Indice
Sommario i
Introduzione iv
1 Phishing 1
1.1 Tipi di phishing . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Statistiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Stato dell’arte 4
2.1 Approcci possibili . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Monitoraggio . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Soluzioni esistenti . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Soluzione scelta . . . . . . . . . . . . . . . . . . . . . . 5
3 Analisi e progettazione 7
3.1 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Domain Monitor/Certspotter . . . . . . . . . . . . . . 8
3.1.2 Precog . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3 Script di analisi . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4 Phishsense . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 DM-Precog-Analisi . . . . . . . . . . . . . . . . . . . . 10
3.2.2 CS-Precog-Analisi lessicale . . . . . . . . . . . . . . . . 11
4 Realizzazione 14
4.1 Adattamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Condivisione . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Riassunto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Misure 20
5.1 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1 Esempio . . . . . . . . . . . . . . . . . . . . . . . . . . 22
ii

5. INDICE
5.2 Misure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1 Efficienza spaziale . . . . . . . . . . . . . . . . . . . . 26
5.2.2 Efficienza temporale . . . . . . . . . . . . . . . . . . . 26
5.3 Validità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Google . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6 Risultati sperimentali 29
6.1 Efficienza spaziale . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2 Efficienza temporale . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 Validità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3.1 Google . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7 Considerazioni 33
7.1 Efficienza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Validità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3 Segnalazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.4 Confronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Conclusioni 36
A Tecnologie utilizzate 38
iii

6. Introduzione
Gli attacchi di phishing sono minacce informatiche che sfruttano le vulne-
rabilità di un sistema causate dal fattore umano. Infatti, la maggior parte
degli attacchi informatici sono effettuati tramite meccanismi che sfruttano
le debolezze dell’utente finale[6].
La forma più frequente di attacco di phishing consiste nell’invio massic-
cio di email, contenenti un link ad un sito web sviluppato appositamente.
Quest’ultimo spesso rappresenta una copia del sito web del particolare ente
o organizzazione dalla quale si vogliono rubare informazioni. In questo modo
la vittima dell’attacco, considerando erroneamente il sito come legittimo, è
indotta ad inserire informazioni personali, tramite login o form sviluppati ad
hoc.
Come verrà descritto nel Capitolo 1, il fenomeno del phishing è esteso ed
in continua evoluzione. Al fine di attrezzarsi con adeguate misure di risposta
al crescente fenomeno del phishing, vengono avviate procedure per:
• migliorare la legislazione in merito;
• rendere gli utenti consapevoli dei rischi e capaci di riconoscere gli
attacchi;
• introdurre adeguate misure tecniche di sicurezza.
Al fine di contrastare questo fenomeno, l’azienda Emaze S.p.A.2 fornisce
ai suoi clienti e non solo un servizio di Domain Monitor3. Per realizzarlo
Emaze utilizza metodologie e algoritmi differenti. Ogni strumento realizza-
to, indipendentemente dagli altri, ha lo scopo di rilevare potenziali siti di
phishing. Tali strumenti, che saranno descritti nel Capitolo 3, producono
un quantitativo elevato di potenziali domini di phishing, che vengono ana-
lizzati manualmente dai tecnici del SOC. Tra questi, anche il numero di falsi
positivi è elevato.
Per rilevare i veri positivi tra tutti quelli ottenuti è necessario visitare
ciascun dominio ottenuto singolarmente ed effettuare determinate verifiche,
2
Per informazioni rivolgersi a precog-dev@emaze.net
3
https://www.emaze.net/precog-enhance-your-defences-against-phishing-attacks
iv

7. INTRODUZIONE
secondo criteri che saranno descritti nella sezione 5.1. Gli operatori del-
l’azienda, che si occupano di queste verifiche, impiegano più di un turno
lavorativo solo per analizzare i risultati ottenuti in un giorno da tutti gli
strumenti.
Lo scopo principale del lavoro di questa tesi è stato quello di costruire
un flusso continuo tra gli strumenti presenti in azienda, al fine di ridurre il
numero di falsi positivi e, di conseguenza, il tempo dedicato dagli operatori
all’individuazione degli effettivi domini di phishing. Conseguentemente è
stato possibile verificare il beneficio ottenuto dalla soluzione.
Alla fine del lavoro si è ottenuto uno strumento automatico, capace di
ottenere risultati utili a individuare domini di phishing e a portare dei gua-
dagni rispetto alle soluzioni precedentemente utilizzate in azienda, come sarà
illustrato nei capitoli finali. Ciò è stato realizzato tramite l’utilizzo di Py-
thon, in quanto la maggior parte degli strumenti già presenti è stata scritta
in tale linguaggio.
In questa tesi verrano trattati i seguenti macro argomenti:
1. Descrizione del fenomeno: i Capitoli 1 e 2 sono dedicati ad un’in-
troduzione al fenomeno del phishing, comprendente la descrizione dei
principali tipi di attacchi e una visione globale sull’impatto del phishing
ad oggi. Successivamente sono state presentate le principali tecniche
anti-phishing, tra le quali l’approccio di Emaze: il monitoraggio dei
domini;
2. Realizzazione dello strumento: in seguito ad un’analisi approfondi-
ta degli strumenti già presenti, si sono ipotizzate possibili realizzazioni
di un flusso comprendente questi ultimi e si sono valutate le varie pos-
sibilità. In seguito, a causa dei differenti risultati ottenuti, si è scelta
la realizzazione più efficace e la si è implementata;
3. Misure: in seguito alla realizzazione dell’integrazione si è svolta una
fase di acquisizione dati sui risultati ottenuti. I dati sono poi stati
analizzati secondo opportune misure. Le misure per la validazione
dell’integrazione realizzata sono descritte nel Capitolo 5;
4. Validazione: una volta ottenuti sufficienti dati sperimentali, si è va-
lutato il guadagno dell’implementazione e l’efficienza del flusso com-
pleto. Si è poi confrontato tale guadagno con i risultati ottenuti senza
l’integrazione del flusso.
v

8. Capitolo 1
Phishing
Il phishing è una tecnica di Social Engineering che permette di ingannare
utenti e sfruttare le informazioni ricavate da essi per attività illecite. Obietti-
vo del phishing è quello di ottenere dati sensibili dagli utenti a scopi malevoli,
attraverso l’impersonificazione di un’istituzione o un ente legittimo.
Tali dati possono riguardare:
• credenziali di accesso, ad esempio per siti di banche o di e-commerce;
• numeri e codici di carte prepagate, carte di credito e debito;
• altre informazioni personali.
Le informazioni così ottenute vengono poi usate per accedere agli account
dei siti legittimi e possono concludersi con furti di identità e/o di denaro.
Nella sua forma più comune il phishing consiste nell’invio massivo di e-
mail a numerosi destinatari, con un link diretto al sito di phishing, creato
appositamente per l’attacco.
1.1 Tipi di phishing
Ad oggi esistono molteplici tecniche differenti di phishing, di cui se ne elen-
cano le principali1:
• Email/Spam: la stessa mail viene inviata a una moltitudine di utenti,
con la richiesta di inserire dati personali. La maggior parte dei messaggi
contiene un link e un avviso riguardo la necessità urgente di inserire le
credenziali dell’utente al fine di aggiornare le infomazioni dell’account,
modificare informazioni o verificare l’account stesso. Solitamente il
link punta a un sito clone del sito originale, in cui l’utente possiede
l’account.
1
http://www.phishing.org/phishing-techniques
1

9. CAPITOLO 1. PHISHING
• Spear Phishing: lo spear phishing è un particolare tipo di phishing,
con specifici target. In questo modo l’attaccante si informa su abitu-
dini e interessi della persona target, alla quale viene inviata una mail
personalizzata e costruita da team che comprendono anche psicologi
per aumentare la capacità di penetrazione dell’attacco. In questo mo-
do aumenta la probabilità che la vittima possa considerare legittima la
mail e ceda le proprie informazioni.
• Content Injection: questa è una tecnica che consiste nel modificare
una parte del contenuto di una pagina web, sfruttando le vulnerabilità
del sito. In questo modo quando l’utente inserirà le proprie credenziali
o le proprie informazioni, queste verranno catturate dal phisher.
• Vishing/Smishing: le vittime sono contattate tramite telefono e vie-
ne chiesto loro di rivelare informazioni personali (Voice Phishing, Vi-
shing); nel secondo caso le vittime sono convinte tramite SMS conte-
nente link a siti di phishing (Sms Phishing, Smishing) a introdurre le
proprie informazioni nel sito a cui punta il link, che solitamente è un
sito clone di quello legittimo.
• Cover Redirect: questa tecnica consiste di fornire alle vittime un
link apparentemente legittimo, che tramite una serie di rendirizzamenti
nascosti porta al sito dell’attaccante.
1.2 Statistiche
Gli attacchi di phishing possono prendere di mira molteplici settori indu-
striali. Si vogliono analizzare alcune tendenze degli attacchi di phishing,
riguardanti i settori maggiormente colpiti. In Figura 1.1 sono mostrate le
tendenze degli attacchi di phishing degli anni 2016 e 2017, secondo i dati
riportati in [10] e in [11].
È possibile notare un aumento degli attacchi di phishing verso aziende
che erogano servizi online, di e-mail e servizi per i pagamenti online. Inoltre
la percentuale di attacchi destinati al settore dei social network è in aumento.
Si può infine notare che la percentuale di attacchi che hanno come obbiettivo
il settore finanziario è in calo.
È il caso inoltre di porre particolare attenzione ad un settore diventato da
poco target degli attacchi di phishing: le criptovalute. Le prime criptovalute
sono nate e si sono sviluppate a partire dal 2009, ma il loro uso e la loro
popolarità sono cresciuti esponenzialmente solo negli ultimi anni. Per tale
motivo il phishing e, più in generale, gli attacchi informatici verso questo
settore si sono sviluppati solo negli anni più recenti[16][2][13].
Risulta quindi difficile avere delle statistiche sugli attacchi di phishing
verso siti di criptovalute in quanto il fenomeno risulta essere nuovo ed in
2

10. CAPITOLO 1. PHISHING
Figura 1.1: Attacchi di phishing suddivisi per settore industriale.
(a) 2016
20.6%23.0%
13.9%
22.6%
11.0%
1.5%
7.3%
Email e servizi online
Finanziario
Pagamento online
Cloud e hosting di file
E-commerce
Social network
Altro
(b) 2017
26.1%
20.5%
16.1%
13.8%
7.6%
4.5%
11.5%
Email e servizi online
Finanziario
Pagamento online
Cloud e hosting di file
E-commerce
Social network
Altro
continua ascesa. L’organizzazione Anti-Phishing Working Group, citata nella
sottosezione 2.2.1, nel 2018 ha creato un gruppo specializzato nella risposta
al phishing indirizzato a siti di criptovalute2.
2
https://www.antiphishing.org/cryptocurrency
3

11. Capitolo 2
Stato dell’arte
Per contrastare questo fenomeno esistono diversi approcci. Verrà analizzato
poi l’approccio scelto: il monitoraggio, seguito dalla tempestiva segnalazione
alle organizzazioni colpite. Verranno poi mostrate le soluzioni esistenti e
quelle sviluppate nel contesto aziendale.
2.1 Approcci possibili
Numerosi sono gli approcci atti a contrastare il fenomeno del phishing, che
possono riguardare il comportamento delle persone, risposte a livello tecnico
e di software e soluzioni legali:
• Educare le persone al riconoscimento del phishing e ad evitare abitudini
che possono mettere a rischio le informazioni personali;
• Mantenimento sui browser di una blacklist dei siti di phishing cono-
sciuti e verificare ogni sito confrontandolo con la blacklist;
• Aumentare i requisiti per ogni accesso, come l’autenticazione a due
fattori o l’uso di particolari espedienti per personalizzare l’accesso;
• Riconoscimento ed eliminazione delle e-mail di phishing, da parte dei
servizi di posta elettronica, mediante l’utilizzo di filtri anti-spam;
• Monitoraggio dei domini e, in caso di presenza di un dominio di phi-
shing, segnalazione all’organizzazione interessata al fine di avviare le
procedure di takedown e chiusura del sito;
• Verifiche aggiuntive di accesso e di transazioni mediante l’utilizzo di
un canale diverso, come ad esempio la conferma tramite numero di
telefono1;
1
http://safesigner.com/en
4

12. CAPITOLO 2. STATO DELL’ARTE
• Risposte legali, a seconda della legislazione del paese di interesse in cui
è hostato il sito illegittimo2.
Tali approcci, combinati assieme, costituiscono una risposta al continuo
aumentare di questo fenomeno, sebbene non siano sufficienti a contrastarlo
completamente.
2.2 Monitoraggio
L’azienda ha scelto di sviluppare un servizio di monitoraggio dei domini dei
propri clienti e non solo.
2.2.1 Soluzioni esistenti
In seguito, si presentano le principali soluzioni di monitoraggio di domi-
ni offerte dagli enti maggiormente impiegati nell’individuazione di URL di
phishing.
• Google Safe Browsing3 è un servizio Google che mantiene aggior-
nata una lista di URL di siti di phishing rilevati o contenenti malware;
• Phishtank4 è un sito in cui chiunque può segnalare e verificare poten-
ziali siti di phishing e riportare gli URL dei siti di phishig trovati;
• APWG5 è un’organizzazione che unifica la risposta globale ai crimi-
ni informatici da parte di vari settori, tra cui i settori istituzionali,
legislativi e delle comunità ONG;
• VirusTotal6 è un servizio web gratuito che analizza file e URL alla
ricerca di virus, phishing, malware e altri contenuti malevoli.
2.2.2 Soluzione scelta
Lo strumento che l’azienda utilizza al fine di monitorare e scoprire eventuali
siti di phishing è chiamato Precog. Questo strumento, partendo da una lista
di domini dei principali TLD (forniti da ICANN, Verisign, ecc), individua
quei domini il cui URL è compatibile con le parole chiave inserite per ciascun
cliente, per il quale si ricercano i siti di phishing. Su di essi vengono effettuate
delle analisi, che saranno dettagliate nel Capitolo 3, di diverso tipo, al fine
di eliminare quei siti sicuramente non di phishing.
2
Per l’Italia si vedano l’Articolo 615 quarter, Articolo 640 e Articolo 171 del Codice
Penale.
3
https://safebrowsing.google.com/
4
https://www.phishtank.com/
5
https://www.antiphishing.org/apwg
6
https://www.virustotal.com/it/
5

13. CAPITOLO 2. STATO DELL’ARTE
Precog ha come input una lista di domini. Questa lista è ottenuta
mediante due strumenti differenti:
• Domain monitor: questo strumento scarica 3 volte al giorno i nuovi
domini registrati/comprati su ICANN7, VeriSign8 e Neustar9;
• Certspotter: questo strumento scarica quei domini per cui è stato
rilasciato un nuovo certificato SSL, sfruttando le API messe a disposi-
zione dai Certificate Transparency Logs10.
Al fine di evitare ambiguità tra i risultati di Precog ottenuti dalla fonte
Domain monitor e la fonte Certspotter, i due strumenti verranno considerati
come a sé stanti, rispettivamente indicati con DM-Precog e CS-Precog.
Entrambi gli strumenti individuano molti più falsi positivi che veri po-
sitivi. Spesso i domini possono essere effettivamente scartati solo visitando
manualmente il sito web e ricercando in esso specifiche caratteristiche, che
saranno descritte nel Capitolo 5. Per questo motivo, è sconsigliabile dimi-
nuire il numeri di falsi positivi prodotti, con conseguente aumento dei falsi
negativi ottenuti. Scopo del monitoraggio, infatti, è quello di individuare
il maggior numero di siti illegittimi, i veri positivi, anche a discapito di un
aumento del numero di falsi positivi.
I risultati ottenuti dal primo strumento sono dell’ordine del migliaio di
domini al giorno, come si vedrà nel Capitolo 3. Tra questi risultano es-
sere domini realmente di phishing solo un paio dei domini trovati in una
settimana.
I risultati di CS-Precog invece sono dell’ordine delle centinaia di migliaia
di domini al giorno. A causa della mole di dati, non è possibile effettuare
delle analisi esaustive per verificare i siti di phishing effettivamente presenti
tra questi. Tali analisi potrebbero essere eseguite solo avendo a disposizione
degli strumenti che possano filtrare ed analizzare automaticamente i domini.
7
https://www.icann.org/
8
http://www.verisign.com/
9
https://www.home.neustar/
10
http://www.certificate-transparency.org/
6

14. Capitolo 3
Analisi e progettazione
Durante la prima fase del lavoro è stata svolta un’analisi per evidenziare qua-
li fossero gli strumenti presenti ed a quali risultati portassero. A partire da
questi sono state definite varie soluzioni, selezionando gli strumenti più ido-
nei, con l’obiettivo di creare uno strumento unico capace di rendere il lavoro
di monitoraggio e segnalazione dei siti di phishing un processo automatico e
robusto in modo da ridurre il tempo impiegato nelle analisi manuali.
3.1 Analisi
In seguito all’analisi e allo studio della situazione aziendale, sono stati indi-
viduati i principali strumenti dedicati al monitoraggio e all’individuazione di
siti di pishing. Tra questi strumenti, ognuno a sé stante, si presentano:
• Domain Monitor: uno strumento che fornisce una lista di nuovi
domini creati, ottenuta mediante la connessione ad ICANN, VeriSign
e Neutstar;
• Certspotter: uno strumento che fornisce una lista di certificati SSL
rilasciati, registrati nei CT logs (Certificate Transparency Logs);
• Precog: a partire dalle liste di domini dei punti precedenti, esso sele-
ziona solo i domini potenzialmente di phishing, ovvero che sono ritenuti
compatibili con i domini dei clienti. Lo strumento individua i domi-
ni sospetti utilizzando tecniche di typosquatting, bitsquatting, prefix,
ecc;
• Script di analisi: un insieme di strumenti atti a ridurre il numero dei
domini prodotti da Precog, sulla base di verifiche automatiche della
raggiungibilità del sito, della sua esistenza, ecc;
• Phishsense: uno strumento basato sulla classificazione dei domini
mediante tecniche di Machine Learning.
7

15. CAPITOLO 3. ANALISI E PROGETTAZIONE
Gli ultimi due strumenti illustrati fanno parte degli strumenti svilup-
pati e testati ma non ancora inseriti nel servizio di monitoraggio offerto
dall’azienda; per questo motivo il loro contributo non è mai stato misurato.
3.1.1 Domain Monitor/Certspotter
Il software Domain Monitor, connettendosi via FTP1 a ICANN, VeriSign
e Neustar con le relative credenziali, scarica la lista contenente i domani
contenuti nei file di zona di questi siti. Questi file contengono esclusivamente
l’URL di ogni dominio.
Al contrario, Certspotter ha come fonte i CT logs, messi a disposizio-
ne tramite opportune API, ottenendo una lista dei nuovi certificati SSL
rilasciati. Tali certificati contengono il dominio per cui è stato emesso il
certificato.
3.1.2 Precog
Precog è un servizio destinato all’uso da parte di enti o istituzioni, ma per
ora viene utilizzato solamente dai tecnici Emaze. Contiene una lista dei
clienti che usufruiscono del servizio. A ciascun cliente vengono assegnate
delle parole chiave. Queste parole chiave sono parole che si possono trovare
nell’URL legittimo del sito web del cliente.
Più specificatamente, Precog è un software che, a partire da un insieme di
parole chiave assegnate a ciascun cliente, esegue una selezione tra dei domini
sospetti, svolgendo numerosi test.
I test effettuati da questo strumento riguardano la ricerca della compa-
tibilità tra le parole chiave inserite per ciascun cliente e l’URL che ha in
input. Esso ricerca gli URL che contengono una parola che ha una deter-
minata distanza di Levenshtein[8], solitamente impostata a 1, da una delle
parole chiave del dato cliente.
La distanza di Levenshtein è una metrica per la misura della differenza tra
due stringhe. L’algoritmo calcola il numero minimo di modifiche elementari
- inserimenti, cancellazioni e sostituzioni di un carattere - che sarebbero
necessarie per trasformare una stringa in un’altra[12][5].
Esso fornisce in output quei domini nei quali è stata individuata la pre-
senza di una delle parole chiave, con distanza di Levenshtein minima. A
ciascun dominio risultante, Precog associa ulteriori informazioni, quali:
• Il cliente per cui il dominio è stato trovato;
• La parola chiave trovata in esso;
• Il tipo di compatibilità, stabilito in base alla distanza di Levenshtein;
1
File Transfer Protocol
8

16. CAPITOLO 3. ANALISI E PROGETTAZIONE
Tabella 3.1: Confronto tra il totale di domini rilevati settimanalmente da
DM-Precog e CS-Precog.
Data DM-Precog CS-Precog
6-06-2018 486 101132
7-06-2018 830 114663
8-06-2018 487 108197
9-06-2018 548 109352
10-06-2018 379 99918
11-06-2018 500 84112
12-06-2018 116 106015
Media 478 103341
• Una confidenza di valore compreso tra 0 (dominio legittimo) e 1 (do-
minio di phishing) che quantifica l’illegittimità del dominio.
Questo strumento può essere eseguito a partire da due fonti differenti: in
seguito al Domain Monitor oppure in seguito a Certspotter. Chiameremo le
due diverse esecuzioni del processo rispettivamente come DM-Precog e CS-
Precog. Le due modalità, avendo fonti diverse, differiscono per la quantità
di risultati prodotti, come illustrato nella Tabella 3.1.
Come si può notare, il numero di risultati di CS-Precog è maggiore di 3
ordini di grandezza rispetto al numero di risultati di DM-Precog. A causa del
fatto che, per valutare i domini ottenuti, è neccessario visitarli singolarmente,
la quantità di risultati di CS-Precog lo rende poco fruibile.
Conseguentemente, nonostante entrambi gli strumenti generino risultati
quotidianamente, solo i risultati di DM-Precog sono analizzati dagli operatori
del SOC.
3.1.3 Script di analisi
Questo insieme di script di analisi comprende tre parti principali, eseguite
originariamente sui risultati di DM-Precog:
1. Analisi lessicale: scarta domini sospetti svolgendo analisi lessicali sul
dominio considerato. Tali analisi possono riguardare un’errata compa-
tibilità rilevata da Precog, la presenza di parole chiave contenute in
altre parole che quindi rendono sbagliata la compatibilità trovata, ecc;
2. Analisi di domini parcheggiati: un dominio parcheggiato è un do-
minio registrato ma non ancora utilizzato, che visualizza nella home
page un messaggio di cortesia o altre informazioni. Questo script scarta
domini che risultano essere parcheggiati, eseguendo un’analisi del co-
dice HTML e del codice JavaScript delle rispettive pagine, ricercando
9

17. CAPITOLO 3. ANALISI E PROGETTAZIONE
queste caratteristiche. Se il sito è offline non ha senso svolgere le suc-
cessive analisi e quindi il dominio viene scartato. Per ciascun dominio
non scartato esegue uno screenshot della pagina web;
3. Analisi grafica: ricerca il logo dell’ente o organizzazione all’interno
dello screenshot della pagina web precedentemente realizzato. Questo
è possibile esclusivamente se sono stati già salvati tali loghi.
3.1.4 Phishsense
Phishsense è un sistema in grado di classificare URL. Tale processo si com-
pone di due fasi.
1. Nella prima fase di training vengono estratte specifiche caratteristi-
che, denominate features, da un numero fissato di domini legittimi e
non. Tali domini sono scaricati da fonti quali PhishTank, Google e
AlexaRanking. Con tali dati viene costruito un classificatore basato
sull’algoritmo Random Forest.
2. Nella seconda fase, che è quella operativa, tramite il classificatore ven-
gono classificati i domini di input, a cui viene assegnato un punteggio,
detto confidenza, che indica la probabilità che il sito sia di phishing o
meno.
3.2 Progettazione
Nel tentativo di integrare alcuni degli strumenti sopra descritti, sono state
ideate due possibili soluzioni. Tra queste, è stata infine scelta la seconda. La
proposta iniziale verrà indicata con DM-Precog-Analisi. La proposta finale
verrà indicata con CS-Precog-Analisi lessicale.
3.2.1 DM-Precog-Analisi
Partendo dagli strumenti descritti in sezione 3.1, si è dapprima pensato
di eseguire gli script di analisi successivamente alla rilevazione dei domini
eseguita da DM-Precog, come mostrato in Figura 3.1.
Questi script, eseguiti sui risultati ottenuti da DM-Precog, sono in grado
di individuare settimanalmente un paio di siti di phishing. Infatti, producen-
do come output circa 20 domini al giorno, sono risultati essere di phishing
solo 2 tra tutti i domini trovati in una settimana. Questo significa che meno
dello 0.1% dei risultati ottenuti da DM-Precog è un dominio di phishing.
Tra i domini scartati, il numero di falsi negativi è risultato trascurabile.
Si noti che l’utilizzo di questi strumenti riduce al minimo il lavoro di
verifica effettuato dagli operatori del Security Operations Center, che sarà
descritto nella sezione 5.1.
10

18. CAPITOLO 3. ANALISI E PROGETTAZIONE
L’uso di questi script di analisi quindi riduce il tempo dedicato da parte
degli operatori del SOC per la verifica dell’effettiva illegittimità dei domini
senza aumentare significativamente il numero di falsi negativi. In compenso,
eseguiti sui risultati di DM-Precog, producono un numero di veri positi-
vi estremamente basso confrontato con il tempo e le risorse dedicate agli
strumenti DM-Precog e agli script precedentemente descritti.
È opportuno inoltre citare alcuni dei principali problemi dell’uso di questi
script:
• Molti dei domini ottenuti come positivi sono in realtà siti di domini
parcheggiati, erroneamente mantenuti dall’Analisi dei domini parcheg-
giati;
• L’Analisi grafica necessita il salvataggio di tutti i loghi utilizzati da
ciascun cliente nel proprio sito web;
• L’Analisi grafica dovendo ricercare sottimmagini in immagini più gran-
di, gli screenshot delle pagine web, consuma notevoli risorse di storage
e temporali;
• A causa della presenza di alcuni siti contenenti JavaScript particolar-
mente complessi, l’esecuzione di questi script non sempre garantisce un
risultato corretto.
L’ultimo punto descritto rappresenta il principale motivo per cui non è
stata scelta questa proposta.
Inoltre, a causa della complessità degli algoritmi che eseguono l’Analisi
JavaScript e l’Analisi grafica, non è stato possibile applicare i risultati a
CS-Precog, a causa dell’elevato numero di risultati che esso fornisce.
3.2.2 CS-Precog-Analisi lessicale
Per superare queste limitazioni e soprattutto volendo preferire i risultati pro-
posti da CS-Precog piuttosto che da DM-Precog, si è pensato di individuare
lo script di analisi più efficiente tra quelli proposti e rendere indipendente la
sua esecuzione.
Sulla base della buona selezione effettuata e del numero di veri posi-
tivi ottenuti, è stata scelta l’Analisi lessicale. Si è voluto eseguire questo
strumento successivamente all’esecuzione di CS-Precog. Con il risultato ot-
tenuto, poi, si è deciso di eseguire l’algoritmo di classificazione per ottenere
una confidenza e poter valutare se e quali fossero i vantaggi offerti da questa
soluzione. Tale processo è illustrato in Figura 3.2.
Una volta valutati i vantaggi offerti da questa soluzione, si è deciso di
integrare il tutto, adeguando gli output ottenuti da ciascuno strumento agli
input necessari a far funzionare il successivo. In questo modo si è potuto
creare uno strumento unico che implementasse la proposta finale e infine
11

19. CAPITOLO 3. ANALISI E PROGETTAZIONE
Figura 3.1: Proposta iniziale di progettazione: DM-Precog-Analisi.
Figura 3.2: Proposta finale di progettazione: CS-Precog-Analisi lessicale.
12

20. CAPITOLO 3. ANALISI E PROGETTAZIONE
condividesse i risultati agli operatori del SOC, per poter eseguire l’analisi
conclusiva.
13

21. Capitolo 4
Realizzazione
Il processo di creazione di un flusso che fosse eseguibile in modo automatico
e indipendente è stato realizzato in quattro fasi:
1. I programmi già presenti sono stati modificati in modo tale da realiz-
zare la compatibilità tra gli output di un singolo processo e gli input
del processo successivo;
2. Sono stati aggiunti degli script che realizzassero delle selezioni e degli
ordinamenti sui file risultanti dai singoli processi;
3. Al fine di condividere i risultati con gli analisti è stato introdotto uno
script che convertisse l’output finale in un Foglio Google, poi caricato
su una cartella Drive. Tramite Google Chat viene mandato il link di
condivisione al Foglio Google creato;
4. È stata configurata un’esecuzione periodica (ogni giorno) che esegue in
ordine tutte le fasi descritte nei punti precedenti.
Di seguito viene analizzata ciascuna fase separatamente.
Gli script che verranno descritti in seguito sono stati scritti nel linguaggio
Python 3.6.5, utilizzando PyCharm1 come strumento di programmazione.
4.1 Adattamento
Sul software CS-Precog non è stata apportata alcuna modifica, in quanto
erano già presenti le API per scaricare i risultati.
Tra gli script di analisi presenti è stato selezionato solo il processo che
esegue l’Analisi lessicale dei domini, al quale sono state apportate opportune
modifiche.
Al processo Phishsense, invece, sono state apportate diverse modifiche.
1
https://www.jetbrains.com/pycharm/
14

22. CAPITOLO 4. REALIZZAZIONE
Il classificatore di Phishsense è costruito a partire da dati, definiti featu-
res, estratti sia da domini legittimi che da domini di phishing. Per ottenere
un classificatore continuamente aggiornato, è stato implementato un mec-
canismo per cui ogni volta che è richiesta la ricostruzione del classificatore,
le features si riferiscano ai domini più recenti disponibili. In questo mo-
do il classificatore, ricostruito due volte a settimana, non può considerarsi
obsoleto e continua a mantenere la sua validità.
Se nel tempo si usasse sempre lo stesso classificatore, la classificazione non
sarebbe più valida. Questo perché il fenomeno del phishing è in continua evo-
luzione e quindi anche i valori delle features delle pagine web appositamente
create per gli attacchi possono variare. Inoltre, nel lungo periodo, potrebbe
risultare necessario modificare la definizione di alcune features, piuttosto che
considerarne di nuove, a causa dell’evoluzione del phishing. Tali modifiche
devono essere effettuate in seguito a delle analisi approfondite sulle tenden-
ze del phishing da parte degli sviluppatori, i quali sono a conoscenza delle
features che attualmente considera il processo Phishsense.
Successivamente sono state aggiunte all’output prodotto dal processo di
Phishsense ulteriori informazioni, ricavate dai domini utilizzati per costruire
il database e, di conseguenza, il classificatore. Queste informazioni riguarda-
no i certificati SSL emessi per ciascun dominio e comprendono: la presenza o
meno di un certificato, la sua validità, il confronto tra l’issuer common name
e il subject common name.
In questo modo è possibile facilitare le verifiche sui certificati SSL, che
devono essere effettuate dagli operatori per i controlli sui domini.
4.2 Integrazione
Per realizzare l’integrazione tra le varie parti, sono stati aggiunti due script
in modo da avere output compatibili con l’input del processo successivo del
flow.
Il primo script ha lo scopo di eliminare, dai risultati di CS-Precog, i domi-
ni che hanno un punteggio percentuale ottenuto da Precog inferiore ad una
certa soglia2. Questo script ha come input il file ottenuto successivamente
all’Analisi lessicale e produce un file che verrà dato in input al classificatore
di Phishsense.
Si noti che i file di output di ciascuno strumento e i file di input di
ciascuno strumento descritto in questa sezione sono file in formato csv. Per
tale motivo questo script si indicherà con modifica csv.
In un secondo momento, dopo la classificazione eseguita da Phishsen-
se e l’aggiunta al file di output delle informazioni ricavate dal certificato
SSL dei domini, i risultati vengono ordinati in ordine decrescente in base
2
La soglia è stata impostata a 90, in quanto la quantità di domini effettivi di phishing
rilevati con punteggio inferiore a tale soglia è risultata trascurabile.
15

23. CAPITOLO 4. REALIZZAZIONE
alla confidenza assegnata ad ogni dominio da Phishsense, tramite uno script
appositamente creato, che verrà indicato con modifica last csv.
4.3 Condivisione
Nella quarta fase si è fatto uso di strumenti commerciali, quali:
• Google Drive3;
• Google Sheet4;
• Hangouts Chat5.
In questa fase è stato realizzato uno script che, ricevendo il file contenente
i domini e le informazioni relative ad essi, prodotto dallo script denominato
modifica last csv, crea un Foglio Google che viene caricato su una cartella
Drive.
Inoltre, invia un messaggio in una chat di Hangouts Chat, condivisa con
gli operatori del SOC, contenente il link al Foglio Google creato. È stata
aggiunta una sezione con l’elenco dei primi 20 potenziali siti di phishing
suddivisi per cliente. In tal modo sono immediatamente visibili i domini
ritenuti più probabilmente illegittimi.
Tramite il link ricevuto, gli operatori hanno la possibilità di eseguire le
opportune analisi sui domini rilevati ed evidenziarli secondo la legenda che
sarà illustrata nella sezione 5.1.
Nella Figura 4.1 è mostrato un esempio di un messaggio inviato quoti-
dianamente su Hangouts Chat.
Successivamente questa fase verrà denominata send to google chat.
4.4 Implementazione
Per ultimare l’integrazione degli strumenti è stato creato un ulteriore script,
che sarà indicato con run all. Tale script permette l’esecuzione di ogni parte
del flusso automaticamente, una di seguito all’altra. Gli strumenti la cui
esecuzione è gestita da questo script comprendono l’Analisi lessicale, modifica
csv, Phishsense, modifica last csv e send to google chat.
Questo script è un file eseguibile che può essere inserito nel crontab e
viene attualmente eseguito ogni giorno alle 6:00.
Inoltre, inserendo opportuni comandi nel crontab, due volte al giorno
vengono scaricati i dati che saranno necessari per la costruzione del classi-
ficatore di Phishsense, ricostruito due volte a settimana, secondo il metodo
descritto in sezione 4.1.
3
https://developers.google.com/drive
4
https://docs.google.com/spreadsheets
5
https://chat.google.com
16

24. CAPITOLO 4. REALIZZAZIONE
Figura 4.1: Esempio di messaggio ricevuto dagli operatori del SOC.
In questo modo è stato possibilire completare il funzionamento del flow
in modo automatico.
4.5 Riassunto
A conclusione di queste quattro fasi è stato realizzato un flusso, illustrato in
Figura 4.2.
Il procedimento di esecuzione è il seguente:
1. CS-Precog: ottiene una lista di domini dai CT Logs e ricerca tra di essi
quelli compatibili con le parole chiave inserite per ciascun cliente;
2. Run all: è il punto di partenza del flow e ne garantisce la corretta
esecuzione;
(a) Analisi lessicale: esegue l’analisi lessicale sui domini ottenuti da
CS-Precog;
(b) Modifica csv: elimina dal file in input i domini con punteggio
inferiore ad una certa soglia;
(c) Phishsense: classifica i restanti domini assegnando loro un valore
di confidenza percentuale, misurato dal classificatore;
(d) Modifica last csv: riordina i domini in base alla confidenza di
Phishsense, in ordine decrescente;
17

25. CAPITOLO 4. REALIZZAZIONE
Figura 4.2: Descrizione completa del flusso, con la specifica dell’input e
l’ouput di ciascun componente.
18

26. CAPITOLO 4. REALIZZAZIONE
(e) Send to google chat: converte la lista di input con i domini e
le relative informazioni in un Foglio Google, caricato su Google
Drive. Quindi invia un messaggio su una chat di Google condivisa,
contenente il link di condivisione del Foglio creato.
19

27. Capitolo 5
Misure
Una volta ottenuto un insieme di domini sospetti è necessario analizzarli per
verificare la presenza di effettivi domini di phishing tra di essi. In seguito
verrà presentata l’analisi sui dati.
5.1 Verifica
Per determinare se i domini risultanti siano di phishing o legittimi si può
procedere all’analisi delle seguenti caratteristiche:
• Individuato da terzi: si verifica se il dominio in questione sia già
stato individuato e segnalato da Google, VirusTotal o PhishTank;
• Certificato SSL: tramite l’ispezione dei dati di WHOIS realizza-
to da Phishsense per estrarre alcune delle features, si possono ot-
tenere informazioni come il certificato SSL, la sua validità ed altre
informazioni;
• Redirect: presenza di reindirizzamenti al sito legittimo prima di poter
accedere ai form di autenticazione, caratteristica non riconducibile ai
siti di phishing, il cui scopo è di memorizzare le informazioni inserite
in tali form. In questo modo infatti i form di autenticazione a cui si è
reindirizzati sono immediatamente quelli legittimi;
• Parked domain: un dominio parcheggiato è un sito registrato ma
non utilizzato. Esso può possedere alcune caratteristiche ricorrenti: la
presenza di frasi specifiche, come ad esempio "Coming soon" e "Under
Costruction", di frasi di cortesia, o, se si tratta di domini parcheggiati
monetizzati, di annunci pubblicitari;
• Form di Login: se la pagina web contiene un form di Login o un
form per l’inserimento di dati personali, la possibilità che il sito non
sia legittimo aumenta;
20

28. CAPITOLO 5. MISURE
• Analisi del codice sorgente della pagina HTML: si verifica la
presenza di link interni alla pagina non funzionanti o di immagini atte
a sostituire porzioni del sito web originale;
• Sottodomini di domini legittimi: nel caso in cui un ente legitti-
mo registri certificati per suoi sottodomini è possibile escludere questi
sottodomini dalla lista dei potenziali domini di phishing;
• Domini legittimi per altri paesi: questa situazione si verifica quan-
do i clienti registrano nuovi domini legittimi aventi suffissi differenti da
quelli già registrati, ad esempio con TLD geografici di altri paesi (.it,
.uk, .tw, ecc). Questi nuovi domini non sono considerati da Precog
come legittimi;
• Geolocalizzazione: analisi della locazione geografica a cui può essere
ricondotto l’indirizzo IP pubblico associato al dominio.
Nella maggior parte dei casi, non è necessario analizzare tutte le prece-
denti caratteristiche per una corretta classificazione dei domini: se alcune
sono verificate, non è necessario valutarne altre.
Questo lavoro viene effettuato periodicamente dagli operatori del SOC.
Per facilitare la comunicazione con questi ultimi si è stabilito l’uso di semplici
regole per l’evidenziazione di domini di phishing, elencati in appositi Fogli
Google:
• Verde: segnala la presenza di un sito di phishing;
• Rosso: segnala la presenza di un sito legittimo;
• Bianco: descrive la presenza di un sito non raggiungibile o non deter-
minabile;
• Arancione: descrive la presenza di un sito sospetto, ma non comple-
tamente verificabile.
Tale legenda può risultare ambigua. Risulterebbe più logico infatti se-
gnalare i siti di phishing, ovvero quelli pericolosi, con il colore rosso e i siti
legittimi con il verde. L’uso di questa convenzione apparentemente illogica
si può spiegare riflettendo sul fatto che l’obiettivo del flow è quello di indivi-
duare siti di phishing, obiettivo che viene raggiunto quando ne viene trovato
uno. Di conseguenza quando si è in presenza di un sito di phishing, esso
viene segnalato in verde al fine di evidenziare il corretto funzionamento dello
strumento.
In Tabella 5.1 è presentato un esempio di output.
21

29. CAPITOLO 5. MISURE
Tabella 5.1: Esempio di output finale. <cliente> indica il nome del cliente
per cui è stato rilevato il dominio, <match> il tipo di compatibilità tra
il dominio e la parola chiave, riportata nella quarta colonna, indicata con
<chiave>.
www.phishing.com cliente match chiave 100 78,37 InfoSSL
www.legittimo.com cliente match chiave 95 78,34 InfoSSL
nonverificabile2.net cliente match chiave 100 78,33 InfoSSL
www.pericoloso.org cliente match chiave 100 78,28 InfoSSL
legittimo2.it cliente match chiave 95 77,7 InfoSSL
www.phishing2.com cliente match chiave 100 77,69 InfoSSL
nonverificabile.org cliente match chiave 100 77,34 InfoSSL
5.1.1 Esempio
È utile fornire un esempio per mostrare come si presenta un sito di phishing
e quali sono alcune delle caratteristiche che possono essere verificate dagli
operatori, al fine di effettuare l’analisi descritta nella sezione 5.1.
Per mostrare alcune delle caratteristiche di un sito di phishing saranno
forniti due esempi: un sito di phishing, hitbtc.cam, e il corrispettivo sito
legittimo, hitbtc.com. Nella Figura 5.1 e nella Figura 5.2 sono mostrate le
rispettive pagine web, come si presentano sul browser dell’utente.
Per quanto riguarda la ricerca di form di login all’interno del sito di phi-
shing, si è notato che la maggior parte dei link della pagina puntano al form
di login illustrato in Figura 5.3. Ad esempio, cliccando sulla sezione Fast,
responsive and feature-packed in basso nel sito illustrato in Figura 5.2,
si viene reindirizzati al form di login sopra citato. Gli altri link della pagina,
invece, sono fittizi in quanto non puntano a nulla.
Al contrario, solo il pulsante in alto a sinistra Sign in del sito legittimo
reindirizza al form di login, identico a quello del sito di phishing.
Nel tentativo di individuare la geolocalizzazione dell’IP di ciascuna pa-
gina web si sono ottenuti i risultati illustrati in Figura 5.4 e in Figura 5.5.
Da questi si può notare la netta distinzione tra le geolocalizzazioni degli IP
pubblici dei due domini.
5.2 Misure
L’efficienza dell’integrazione fra i vari componenti può essere valutata sotto
diversi aspetti.
• Come prima cosa bisogna rilevare la mole di dati che il sistema prende
in input, la riduzione in ciascuna fase e il numero di domini ottenuti
nell’ultimo ouput;
22

30. CAPITOLO 5. MISURE
Figura 5.1: Sito legittimo hitbtc.com.
Figura 5.2: Sito di phishing hitbtc.cam.
23

31. CAPITOLO 5. MISURE
Figura 5.3: Form di login di hitbtc.cam, a cui reindirizzano tutti i link non
fittizi della pagina.
24

32. CAPITOLO 5. MISURE
Figura 5.4: Geolocalizzazione dell’indirizzo IP di hitbtc.com.
Figura 5.5: Geolocalizzazione dell’indirizzo IP hitbtc.cam.
25

33. CAPITOLO 5. MISURE
• In secondo luogo è possibile rilevare le tempistiche di elaborazione e
filtraggio dei dati, tramite la presenza di appositi file log generati dagli
script stessi, in modo tale da monitorare la durata di ogni elaborazione.
Verrà analizzato ciascun aspetto separatamente.
5.2.1 Efficienza spaziale
Una misura di efficienza spaziale può essere realizzata tramite l’analisi del-
le quantità di risultati mantenuti in ciascuna fase. Si può quindi valuta-
re la quantità di risultati di partenza, i risultati finali e ciascun risultato
intermedio.
Per valutare questi dati è possibile calcolare di quanto si riduce il numero
di domini da analizzare, tramite la relazione
guadagno =
dominiiniziali
dominifinali
È possibile calcolare la riduzione percentuale del numero di domini, tra-
mite la formula
riduzione percentuale =
dominiiniziali − dominifinali
dominiiniziali
∗ 100
5.2.2 Efficienza temporale
Per rilevare le tempistiche di elaborazione e filtraggio dei dati, è possibile
fare uso dei file di log, contenenti i tempi di esecuzione di ciascun algoritmo,
generati dagli script stessi.
Inoltre per calcolare le tempistiche di esecuzione di CS-Precog è pos-
sibile calcolare l’intervallo di tempo dall’ora in cui è iniziata l’esecuzione
dell’algoritmo e l’ora in cui tali risultati sono stati pubblicati.
In questo modo è possibile calcolare le tempistiche di esecuzione per
ciascuno strumento e il tempo totale di esecuzione del flusso.
5.3 Validità
Grazie al feedback ottenuto dagli analisti, secondo le modalità descritte nella
sezione 5.1 è possibile valutare la validità dell’integrazione.
In primis, si può contare il numero di domini di phishing rispetto ai do-
mini ottenuti quotidianamente, i domini legittimi e i domini potenzialmente
pericolosi ma non completamente verificabili. Collezionando questi dati per
un intervallo di tempo predefinito, una settimana in questo caso, è possibile
calcolare la media di ciascun dato.
26

34. CAPITOLO 5. MISURE
A partire da queste informazioni, si può calcolare la precisione dello
strumento, come descritto in [3], come:
precisione =
dominiphishing
dominifinali
In questo modo è possibile fare delle considerazioni sui risultati ottenu-
ti. Si noti che, per una completa analisi, sarebbe necessario conoscere la
quantità di domini di phishing che sono stati erroneamente scartati duran-
te l’esecuzione del flow, i falsi negativi. Questo numero non è calcolabile,
a causa dell’elevata quantità di domini iniziali di CS-Precog. Quest’ultima
quantità è stata precedentemente illustrata nella Tabella 3.1.
5.3.1 Google
Come citato nel Capitolo 2, Google offre agli utenti di Google Chrome e non
solo un servizio atto ad individuare e segnalare domini di phishing. Questo
servizio viene denominato Google Safe Browsing1. Quando lo strumento
individua un sito di phishing, quest’ultimo, se aperto con uno dei browser che
utilizza questo servizio, mostrerà la pagina web con un avviso che segnala la
pericolosità del sito, come illustrato in Figura 5.6. Ad ogni modo è possibile
visionare la pagina web tramite l’opzione "Details" messa a disposizione da
Google.
Tramite una semplice ricerca su Chrome, è possibile verificare se un sito
di phishing è già stato segnalato da Google Safe Browsing. In questo modo
è possibile sapere quanti dei domini individuati dal flusso siano già stati
individuati e segnalati da Google.
1
https://safebrowsing.google.com/
27

35. CAPITOLO 5. MISURE
Figura 5.6: Sito di phishing segnalato da Google Safe Browsing.
28

36. Capitolo 6
Risultati sperimentali
In questo capitolo verrà valutato il guadagno ottenuto dall’integrazione degli
strumenti precedentemente descritti. Queste valutazioni verrano fatte sulla
base delle misure sperimentali descritte nel Capitolo 5.
6.1 Efficienza spaziale
Per valutare correttamente la riduzione di domini prodotta dal flusso è ne-
cessario riportare quanti domini sono generati da ciascun strumento che
compone il flusso, calcolandone la media per un periodo di tempo prefissato.
Si è scelta come unità di tempo la settimana. Questo poiché in una set-
timana si ottiene un numero sufficiente di risultati, veri positivi, per poter
trarre delle corrette conclusioni. Non è necessario utilizzare un’unità di mi-
sura maggiore in quanto si sarebbero ottenuti valori analoghi ma con una
quantità di dati di gran lunga superiore.
Nella Tabella 6.1 sono rappresentate le quantità di domini quotidiana-
mente analizzate dai vari strumenti compresi nel flow.
Tabella 6.1: Numero domini di output per ciascun strumento in una
settimana.
Domini di output CS-Precog Analisi Lessicale Modifica csv
6-06-2018 101132 29459 301
7-06-2018 114663 33124 313
8-06-2018 108197 32178 323
9-06-2018 109352 31281 394
10-06-2018 99918 28887 286
11-06-2018 84112 24244 240
12-06-2018 106015 31761 292
Media 103341 30133 307
29

37. CAPITOLO 6. RISULTATI SPERIMENTALI
Tabella 6.2: Tabella dei tempi di esecuzione dell’Analisi lessicale e calcolo
del tempo totale.
Data CS-Precog Analisi lessicale Totale
6-06-2018 01:09:19 00:29:34 01:38:53
7-06-2018 01:11.39 00:32:05 00:33:16
8-06-2018 01:08:24 00:29:34 01:37:58
9-06-2018 01:06:15 00:32:50 01:39:05
10-06-2018 00:59:49 00:27:55 01:27:44
11-06-2018 00:56:57 00:24:00 01:20:57
12-06-2018 01:09:23 00:29:24 01:38:47
Dalla tabella si può notare come siano state escluse le informazioni ri-
guardanti gli strumenti di Phishsense e i successivi. Questa scelta non ha
alcun impatto sulle considerazioni che verranno fatte in seguito, in quanto
il numero di domini è fissato successivamente alla selezione dei domini con
punteggio superiore alla soglia. Infatti i processi di Phishsense, modifica last
csv e send to google chat non modificano il numero di domini ma aggiungono
eventualmente informazioni ai domini già presenti.
Tramite il flow realizzato, il numero dei domini da analizzare si riduce.
Il guadagno diventa:
guadagno =
103341
307
= 337
Questo significa che il numero di domini da analizzare si riduce mediamente
di 337 volte. La riduzione percentuale del numero di domini risulta essere
del 99,7%, calcolata tramite la formula:
riduzione percentuale =
103341 − 307
103341
∗ 100 = 99.7
6.2 Efficienza temporale
Nella Tabella 6.2 sono riportati i risultati sperimentali ottenuti tramite le
misure descritte nella sottosezione 5.2.2.
Si noti come nella tabella siano stati ignorati i tempi di classificazione
del classificatore di Phishsense, i tempi di modifica dei file e il tempo di
esecuzione dello script send to google chat. Questo perché, confrontati con i
tempi di CS-Precog e dell’Analisi lessicale sono irrilevanti, essendo dell’ordine
di pochi secondi.
30

38. CAPITOLO 6. RISULTATI SPERIMENTALI
Tabella 6.3: Confronto fra domini effettivi di phishing e domini legittimi
rilevati dai domini di output del flow.
Data Domini finali Phishing Legittimi Sospetti
6-06-2018 301 18 25 0
7-06-2018 313 21 33 0
8-06-2018 323 29 60 2
9-06-2018 394 19 16 0
10-06-2018 286 17 14 0
11-06-2018 240 16 10 0
12-06-2018 292 30 11 0
Media 307 21 24 0.3
6.3 Validità
Per valutare la validità dell’integrazione è necessario riconoscere quali tra
i domini selezionati alla fine del flow siano realmente di phishing. Questo
feedback è reso possibile dal lavoro degli operatori del SOC.
Si ricorda, come già accennato precedentemente, che per una validazione
completa dell’integrazione sarebbe necessario quantificare anche i falsi ne-
gativi. Tale validazione non è realizzabile a causa dell’elevata quantità di
domini iniziali di CS-Precog.
I risultati ottenuti in una settimana, possono essere illustrati nella Ta-
bella 6.3. È stata scelta come unità di tempo la stessa settimana utilizzata
per verificare l’efficienza spaziale e temporale dell’integrazione.
Nella tabella sono visibili i domini in output ottenuti dal flow, tra questi
i domini di phishing e i domini legittimi. L’ultima colonna è dedicata a
domini sospetti ma non verificabili.
I domini restanti, non conteggiati nelle colonne presenti, sono domini
per i quali la compatibilità con le parole chiave è stata rilevata ma non c’è
correlazione alcuna tra tale dominio e il cliente per cui è stata inserita la
parola chiave. Per fare un esempio, se si ricercasse la parola chiave poste
per l’ente Poste Italiane, si potrebbero avere come domini risultanti i domini
www.deutschepost.de e www.ilpost.it, che evidentemente non sono correlati
con le Poste Italiane.
Su una media di 307 domini potenzialmente di phishing al giorno, in
media 21 tra di essi sono effettivamente siti di phishing o compromessi.
La precisione quindi di tale algoritmo è di 0.068, ottenuta tramite l’ope-
razione:
precisione =
21
307
= 0.068
Ciò significa che la percentuale di domini di phishing rispetto ai domini
potenzialmente di phishing, ovvero la precisione percentuale, è del 6.8%.
31

39. CAPITOLO 6. RISULTATI SPERIMENTALI
Tabella 6.4: Confronto fra domini di phishing trovati dal flow e domini di
phishing già segnalati da Google Safe Browsing.
Data Phishing Segnalato
6-06-2018 18 9
7-06-2018 21 6
8-06-2018 29 7
9-06-2018 19 8
10-06-2018 17 6
11-06-2018 16 14
12-06-2018 30 11
Media 21 9
6.3.1 Google
Come già accennato, Google è uno degli enti maggiormente impegnati nel
monitoraggio di domini, tramite un servizio apposito denominato Google
Safe Browsing. Può quindi risultare interessante verificare se i domini indi-
viduati dal flow siano già stati segnalati da quest’ultimo.
Nella Tabella 6.4 sono mostrati quanti tra i domini di phishing individuati
dal flow siano già stati segnalati da Google Safe Browsing, prendendo in
considerazione i dati della stessa settimana già analizzata in precedenza.
Come si evince dalla tabella, meno della metà dei domini di phishing trovati
in media ogni giorno è stata già individuata da Google.
Questa verifica viene effettuata dagli operatori del SOC nel momento in
cui analizzano i domini finali ottenuti dal flow.
32

40. Capitolo 7
Considerazioni
I risultati sperimentali precedentemente illustrati portano alle seguenti con-
siderazioni, per quanto riguarda l’efficienza e la validità dell’integrazione, e
la segnalazione ai clienti che hanno richiesto il servizio.
7.1 Efficienza
Il numero dei domini da analizzare manualmente è stato ridotto in maniera
significativa. Infatti solo lo 0.3% di tali domini è stato selezionato per essere
poi verificato dagli operatori del SOC. I domini ottenuti sono verificabili da
un singolo operatore in un massimo di due ore, essendo in media 307, rispetto
al numero medio di domini di partenza di 103341.
Questo risultato è vantaggioso rispetto allo strumento DM-Precog che,
pur fornendo molti meno risultati - in media 478 contro i 103341 di CS-Precog
-, tra di essi al massimo 1 o 2 domini sono di phishing. Questo strumento
non produce sufficienti risultati positivi da giustificare il tempo impiegato
dagli operatori del SOC al controllo di tutti i domini.
Dal punto di vista dell’efficienza spaziale si può quindi concludere che l’in-
tegrazione del flusso porta vantaggi significativi rispetto ai singoli strumenti
CS-Precog e DM-Precog.
Per quanto riguarda l’efficienza temporale, il tempo complessivo di ese-
cuzione del flusso è adeguato per fornire una risposta puntuale a coloro che
richiedono il servizio. Iniziando alle 3:00, il flow conclude la sua esecuzione
entro le 7:00 del mattino, orario adatto affinché gli operatori possano iniziare
le opportune analisi all’inizio del turno. Questo fa sì che, una volta iniziato
il turno, gli operatori possano avere tutto il materiale disponibile online, così
da poter iniziare la verifica dei domini trovati con l’attività di monitoraggio,
e in questo modo verificare la presenza di domini di phishing non già rilevati
da Google o da altri concorrenti.
33

41. CAPITOLO 7. CONSIDERAZIONI
7.2 Validità
Per valutare la validità del flow realizzato è necessario far riferimento alla
sezione 6.3.
Si può notare che l’integrazione, con una precisione del 6.8%, fornisce un
numero di falsi positivi maggiore rispetto al numero di veri positivi. Questo
perché tra i domini ottenuti dall’integrazione, da valutare, sono presenti più
tipologie di domini:
• Domini di phishing o compromessi;
• Domini legittimi del cliente per il quale sono stati individuati;
• Domini non raggiungibili o non verificabili;
• Domini legittimi ma non correlati in alcun modo al cliente per il quale
sono stati individuati.
L’ultima categoria di domini è la più numerosa. Questo è accettabile
in quanto è preferibile individuare il maggior numero possibile di siti di
phishing, veri positivi, a discapito di un aumento inevitabile dei falsi positivi.
Il flusso realizzato è in grado di rilevare mediamente 21 domini illegittimi
al giorno. Questo numero è di gran lunga superiore al numero di domini
illegittimi individuati con gli strumenti prima utilizzati, ma non integrati.
Inoltre, come mostrato nella sottosezione 6.3.1 dei 21 domini individuati
dal flow in media solo 9 domini sono già stati segnalati da Google Safe
Browsing. Questo significa che il flow può essere considerato uno strumento
competitivo per il monitoraggio dei domini, essendo Google uno degli enti
maggiormente impiegati nella ricerca e segnalazione di domini di phishing.
In seguito all’individuazione di tali domini, si può procedere istantanea-
mente, dopo le legittime verifiche, alla segnalazione del dominio al cliente
che ha richiesto il servizio, in modo tale che possa avviare le procedure di
takedown.
7.3 Segnalazione
Riuscire a rilevare prontamente i domini di phishing non appena sono stati
creati può portare numerosi benefici.
Innanzitutto, gli attaccanti hanno a disposizione minor tempo per otte-
nere informazioni dalle vittime. Questo perché, potendo segnalare al cliente
un sito di phishing trovato, egli può avviare l’iter di denuncia web per reati
telematici alla Polizia di Stato. Come specificato nel sito del Commissaria-
to della Polizia di Stato1, «chi legittimamente detiene il diritto d’autore
1
https://www.commissariatodips.it
34

42. CAPITOLO 7. CONSIDERAZIONI
relativo alla pagina web riprodotta fraudolentemente potrebbe, facendo vale-
re tale diritto, denunciare la riproduzione e la diffusione della propria opera.»
Questo processo diminuisce inoltre la probabilità che il marchio o ente perda
credibilità.
In aggiunta, è possibile segnalare questi domini illegittimi a Google, Phi-
shTank, VirusTotal o APWG, in modo tale da sfruttare l’influenza e popo-
larità di tali enti al fine di ridurre o evitare gli attacchi di phishing ai danni
degli utenti.
In questo modo è possibile avere una risposta puntuale al fenomeno.
Infine, se il sito di phishing è in realtà un sito legittimo, ma compromes-
so, si possono avviare altri tipi di procedure. Il dominio compromesso viene
segnalato al cliente e quest’ultimo può avviare le analisi opportune alla ri-
cerca delle vulnerabilità del suo sito web, che hanno permesso all’attaccante
di perpetrare l’attacco. Questo strumento quindi può essere utilizzato da un
ente anche come verifica delle proprie vulnerabilità, che probabilmente non
sarebbero state indivduate altrettanto prontamente.
7.4 Confronto
È possibile effettuare un confronto tra i risultati dell’integrazione e i risulta-
ti precedentemente ottenuti, in particolare durante l’analisi degli strumenti
descritta nella sezione 3.1.
Il processo DM-Precog ottiene in media 478 risultati al giorno. Tra que-
sti, pur eseguendo su di essi una riduzione grazie all’utilizzo degli script
di analisi precedentemente descritti, solo un paio di domini trovati in una
settimana risultano essere siti di phishing. Quindi, se ogni settimana venis-
sero rilevati esattamente 2 domini di phishing, la precisione dello strumento
sarebbe comunque inferiore dello 0.1%.
L’integrazione, al contrario, permette di raggiungere una precisione del
6.8%, nettamente superiore a quella di DM-Precog.
Questo è un notevole risultato in quanto è possibile individuare in media
147 siti illegittimi o compromessi a settimana. Tale risultato rende quindi
consigliabile l’utilizzo di questa integrazione al fine di monitorare e segnalare
domini illegittimi.
35

43. Conclusioni
L’obbiettivo di questa tesi è stato quello di sviluppare uno strumento capace
di individuare tempestivamente la creazione di nuovi siti di phishing. Il
phishing è un fenomeno diffuso su larga scala ed in continua evoluzione. Per
contrastarlo, è necessario l’utilizzo di nuove tecniche, capaci di mitigare il
fenomeno nonostante la sua continua evoluzione.
A tale scopo, sono stati analizzati gli strumenti già sviluppati nell’azienda
Emaze S.p.A, tra i quali alcuni in uso ed altri no. Tra questi strumenti
sono stati selezionati quelli con maggior efficacia nella rilevazione di siti di
phishing.
In seguito, sono state apportate delle modifiche agli strumenti selezionati.
Avendo deciso di realizzare un flusso in cui gli strumenti fossero utilizzati in
cascata, sono stati sviluppati degli algoritmi in grado di adattare l’output di
ciascun strumento all’input dello strumento successivo.
Grazie all’esecuzione quotidiana di tale flusso sono stati raccolti i dati
utilizzati per produrre i risultati qui presentati. Tra questi, di particolare
interesse sono le quantità di domini di partenza e il numero di domini so-
spetti, da verificare. Tra i potenziali domini di phishing ottenuti, è stato
utile verificare quali fossero siti illegittimi e valutare il guadagno ottenuto
dall’implementazione di questo flusso. Inoltre si è posta attenzione al tempo
di esecuzione.
Questo strumento esegue una selezione sui domini da verificare, riducen-
done il numero del 99,7%. Tra i domini ottenuti quotidianamente, in media
307, sono presenti mediamente 21 siti di phishing, tra cui siti illegittimi e
siti compromessi. Questo significa che tra i domini da verificare ottenuti in
un giorno il 6.8% di questi è di phishing. Tra questi, meno della metà è
già stato segnalato da Google Safe Browsing, un servizio offerto da Google.
Questo rende il flow uno strumento competitivo rispetto a quelli attualmente
presenti. Infine, questi risultati sono stati raggiunti in un tempo medio di
un’ora e mezza, a cui va sommato il tempo dedicato alla verifica dei domini
da parte degli operatori del SOC, che non supera le due ore.
È possibile quindi affermare che l’integrazione realizzata ha raggiunto
l’obbiettivo prefissato, quello cioè di monitorare e segnalare siti di phi-
shing, tentando di ridurre il lavoro svolto manualmente dagli operatori e
aumentando la precisione degli strumenti presenti in azienda.
36

44. CONCLUSIONI
Personalmente, questa esperienza è stata molto soddisfacente, sia per i
numerosi insegnamenti appresi, sia per l’occasione di mettersi in gioco in un
ambiente completamente nuovo.
Il lavoro svolto in questa tesi ha fatto emergere numerosi spunti per
ottimizzazioni ed eventuali estensioni. Tra questi, si elencano i principali:
• Apportare modifiche a Precog per evitare la rilevazione di sottodo-
mini di domini legittimi ed evitare la re-individuazione di domini già
individuati in precedenza;
• Ottimizzare alcuni degli algoritmi compresi nel flow;
• Implementare tutto il meccanismo sui server di monitoraggio dei do-
mini;
• Costruire un container Docker per poter esporre il servizio al pubblico.
37

45. Appendice A
Tecnologie utilizzate
Come accennato nel Capitolo 4, l’integrazione fra tutti i componenti, svi-
luppata nel corso di questa tesi, è stata realizzata tramite l’uso di Python
3.6.5. Si è scelto questo linguaggio di programmazione per la sua efficienza
e portabilità. Inoltre la maggior parte degli strumenti presenti fanno già uso
di tale linguaggio.
Per lo sviluppo del flow si è utilizzato come strumento di programmazione
il software PyCharm.
Per realizzare il caricamento e la condivisione dei risultati si è fatto uso
di API apposite per la comunicazione con Google Drive, Google Sheet e
Hangouts Chat.
38

46. Bibliografia
[1] H. Abroshan, G. Poels J. Devos, and E. Laermans. Phishing attacks
root causes. Risks and Security of Internet and Systems, Crisi 2017,
pages 187–202, Sep 2018.
[2] J. Robertson E. Lam, J. Lee. Cryptocurrencies lo-
se $42 billion after south korean bourse hack. https:
//www.bloomberg.com/news/articles/2018-06-10/
bitcoin-tumbles-most-in-two-weeks-amid-south-korea-exchange-hack.
Accessed: 19-08-2018.
[3] M. Lenk F. Salfner and M. Malek. A survey of online failure prediction
methods. ACM Comput. Surv. 42, 42(10), Mar 2010.
[4] R. Rasmussen G. Aaron. Global phishing survey: Trends and domain
name use in 2016. Technical report, APWG, Internet Policy Committee,
2017.
[5] D. Sankoff J. Kruskal and foreword by J. Nerbonne. Reprint. An Over-
view of Sequence Comparison. In Time Warps, String Edits and Ma-
cromolecules: The Theory and Practice of Sequence Comparison. CSLI
Publications, 1999.
[6] M. Khonji, Senior Member Y. Iraqi, IEEE, and Andrew Jones. Phi-
shing detection: A literature survey. IEEE Communications Surveys
and Tutorials, 15:2091–2121, 2013.
[7] M. K. Sohrabi M. Arab. Proposing a new clustering method to de-
tect phishing websites. Turkish Journal of Electrical Engineering and
Computer Sciences, pages 4757–4767, 2017.
[8] P. S. Novikov. Binary codes capable of correcting deletions, insertions,
and reversals, levenshtein. Soviet Physics - Doklady, 10:845–848, Feb
1966.
[9] C. Gonzalez P. Rajivan. Creative persuasion: A study on adversarial
behaviors and strategies in phishing attacks. Frontiers in Psychology,
9, Feb 2018.
39

47. BIBLIOGRAFIA
[10] Phishlabs. 2017 phishing trends and intelligence report: hacking the
human. Technical report, Ecrime Management Strategies, Inc., 2017.
[11] Phishlabs. 2018 phishing trends and intelligence report: hacking the
human. Technical report, Ecrime Management Strategies, Inc., 2018.
[12] E. S. Ristad and P. N. Yianilos. Learning string edit distance. Technical
report, Department of Computer Science, Princeton University, 1997.
[13] J. J. Roberts. Another crypto fail: Hackers steal $23.5 million from to-
ken service bancor. http://fortune.com/2018/07/09/bancor-hack/.
Accessed: 19-08-2018.
[14] M. T. Sharabian S. Nasiri and M. Aajami. Using combined one-time
password for prevention of phishing attacks. Engineering Technology
and Applied Science Research, pages 2328–2333, Dec 2017.
[15] Wombat Security. State of the phishTM 2018. Technical report, Wombat
Security Technologies, Inc., 2018.
[16] J. Wilmoth. Bitcoin gold hit by double spend at-
tack, exchanges lose millions. https://www.ccn.com/
bitcoin-gold-hit-by-double-spend-attack-exchanges-lose-millions/.
Accessed: 19-08-2018.
[17] I. Khaliland Z. Dou, A. Al-Fuqaha A. Khreishah, and M. Guizani. Syste-
matization of knowledge (sok): A systematic review of software-based
web phishing detection. IEEE Communications Surveys and Tutorials,
pages 2797–2819, Sep 2017.
40

48. Ringraziamenti
A mia madre Rita per l’entusiasmo e il sostegno in ogni decisione,
A mio padre Alex per i consigli e gli insegnamenti,
A mio fratello Marco per le chiacchierate intellettuali e non,
Ai miei nonni che nonostante tutto mi sono sempre vicini,
A Matteo per la pazienza e l’immancabile supporto anche nei momenti più
difficili,
Ai colleghi in Emaze per i continui insegnamenti e la voglia di conoscere che
mi hanno trasmesso,
Agli amici e compagni di corso che, tra preziosi consigli e serate indimenti-
cabili, hanno reso unica la mia esperienza universitaria,
grazie