- Home
- Academy
- Ethical Hacking: percorso tecnico
- Social engineering e phishing: studiare le difese
Social engineering e phishing: studiare le difese
Il social engineering sfrutta fiducia, abitudini e pressioni del contesto per ottenere un comportamento. Non riguarda soltanto email scritte male: può presentarsi come una richiesta plausibile del responsabile, una telefonata urgente o un passaggio apparentemente normale di una procedura.
In questa lezione analizzi le decisioni che rendono credibile una richiesta e progetti una simulazione da tavolo. Non costruisci pagine per raccogliere password e non contatti persone ignare. Il laboratorio serve a valutare il processo di verifica e segnalazione, usando messaggi fittizi e partecipanti informati.
Social engineering: il contesto prima del messaggio
Una richiesta può sembrare credibile perché arriva nel momento giusto, usa un linguaggio familiare o richiama un’attività attesa. Autorità, urgenza, reciprocità e prova sociale possono influenzare una decisione. Non sono comandi che controllano automaticamente una persona: il loro effetto dipende da contesto, abitudini e possibilità di verificare.
Chi lavora sotto pressione può scegliere una scorciatoia anche conoscendo le regole. Per questo la difesa non può ridursi a «stare più attenti». Devi costruire un percorso semplice per controllare una richiesta e un canale che permetta di chiedere aiuto senza essere giudicati.
Distingui contenuto della richiesta e autorità dichiarata. Una firma, una fotografia o un nome noto sono elementi rappresentabili da altri. Il punto è verificare il rapporto tra quella persona e quell’azione attraverso un canale indipendente, non semplicemente riconoscere un marchio o un tono.
Phishing, pretesti e canali
Il phishing usa messaggi o interfacce ingannevoli per indurre azioni come aprire un collegamento, condividere un segreto o autorizzare un’operazione. Varianti mirate possono usare informazioni contestuali, ma la presenza di dettagli corretti non dimostra l’identità del mittente.
Un pretesto costruisce una situazione nella quale la richiesta sembra necessaria: assistenza tecnica, modifica di coordinate bancarie, problema a un account o consegna di un documento. Il canale può essere email, telefono, messaggistica o interazione fisica. La stessa procedura può essere messa sotto pressione attraverso più canali.
Studia anche le richieste che non chiedono password. Un’autorizzazione di accesso, un cambio di beneficiario o l’apertura di un documento possono avere impatti diversi. Se la formazione controlla soltanto il furto di credenziali, lascia fuori una parte delle decisioni importanti dell’organizzazione.
Segnali utili e limiti delle scorciatoie
Il dominio effettivo di un collegamento conta più del testo mostrato nel messaggio. Sottodomini, caratteri simili e collegamenti riscritti possono complicare la lettura. Non chiedere però a ogni persona di svolgere un’analisi tecnica completa prima di ogni clic: serve anche una regola chiara per i casi dubbi.
Un messaggio privo di errori può essere fraudolento. Un messaggio con errori può essere legittimo. Le etichette del programma di posta sono segnali utili, ma non una prova universale dell’intenzione. L’attaccante può usare anche un account realmente compromesso, dal quale il messaggio appare tecnicamente autenticato.
SPF, DKIM e DMARC affrontano aspetti dell’autenticazione e dell’allineamento della posta. Non certificano la correttezza di ogni richiesta contenuta nel messaggio e non dimostrano che l’account o il mittente agiscano in modo autorizzato. Le specifiche DMARC aiutano a capire il ruolo del protocollo, senza attribuirgli il compito di valutare il significato di un pagamento.
Progettare una verifica indipendente
Una verifica indipendente usa un recapito o un processo già noto, non quello fornito nel messaggio sospetto. Per un cambio di coordinate di pagamento puoi prevedere un controllo attraverso il contatto registrato e un secondo ruolo autorizzato. Per una richiesta di assistenza puoi usare il canale ufficiale interno.
Il controllo deve essere praticabile. Se la procedura richiede di trovare una persona sempre irreperibile, i partecipanti impareranno presto a saltarla. Definisci una sostituzione e una modalità di gestione dell’urgenza che non annulli la verifica.
La segnalazione deve ricevere una risposta. Chi segnala un messaggio e non sa mai che cosa sia successo può smettere di considerare utile il canale. Il processo dovrebbe restituire almeno una conferma e indicare come proseguire l’attività legittima.
Laboratorio passo per passo
Prepara tre messaggi fittizi stampati o salvati in un dossier locale. Il primo chiede di aggiornare un account. Il secondo propone un cambio di coordinate bancarie. Il terzo contiene una richiesta legittima ma insolita. Usa soltanto nomi inventati e domini di esempio, senza collegamenti a infrastrutture di raccolta.
Per ogni messaggio definisci la decisione attesa. Non sempre è «cancellare»: potrebbe essere verificare con un canale indipendente, segnalare o procedere dopo un controllo. Un esercizio che premia soltanto il rifiuto rischia di insegnare a bloccare il lavoro invece di gestire l’incertezza.
Con partecipanti informati, esamina la richiesta e annota quali elementi aumentino o riducano la fiducia. Poi chiedi come venga effettuata la verifica. Il risultato importante è la sequenza di decisioni, non il punteggio individuale ottenuto riconoscendo un tranello.
Ripeti l’esercizio aggiungendo pressione temporale soltanto nel racconto, senza interrompere davvero il lavoro delle persone. Osserva quali passaggi diventano difficili. Se la verifica richiede informazioni che non sono disponibili, il problema riguarda il processo e deve essere corretto lì.
Concludi aggiornando una pagina di procedura. Deve indicare che cosa fare, quale canale usare, chi risponde e come riprendere l’attività. Fallo leggere a un collega che non ha partecipato alla discussione: se non riesce a usarlo senza spiegazioni, il documento è ancora troppo dipendente da conoscenze implicite.
Misurare senza colpevolizzare
Misura la disponibilità del canale, la capacità di verificare e il tempo necessario a ricevere aiuto. La percentuale di clic può essere un dato in una simulazione concordata, ma non descrive da sola il rischio né la qualità della risposta. Conta anche che cosa avvenga dopo un errore o una segnalazione.
Se una persona ha già eseguito un’azione, il processo deve favorire una comunicazione rapida. Una cultura punitiva può ritardare proprio l’informazione che serve a limitare l’incidente. Nel dossier scrivi come cambierebbe la risposta se il messaggio fosse stato aperto o se una credenziale fittizia fosse stata condivisa.
Il NIST SP 800-61 Rev. 3 offre un riferimento per collegare preparazione e risposta. Non tutte le segnalazioni diventano incidenti; serve un criterio di triage che permetta di approfondire senza ignorare il contesto operativo.
Checklist ed errori da evitare
- Il pretesto è descritto senza attribuire capacità magiche al messaggio.
- La verifica usa un canale indipendente.
- Il laboratorio non raccoglie segreti o dati personali reali.
- La procedura funziona anche quando il primo referente è assente.
- La risposta a un errore è prevista e praticabile.
- Le metriche valutano anche processo, aiuto e recupero.
Evita l’idea che un buon corso renda impossibile sbagliare. Evita anche simulazioni sorprendenti non concordate, campagne umilianti e classifiche che confondono apprendimento e colpevolizzazione. Qui studi come rendere più affidabile un sistema di decisioni, non come mettere in difficoltà i colleghi.
Consigli pratici
Sostituisci «non fidarti» con un’istruzione utilizzabile. Per esempio: «Per modificare un beneficiario, richiama il contatto già registrato e fai approvare la variazione». La seconda frase descrive un comportamento che puoi provare e migliorare.
Questo approccio si collega alla formazione dei dipendenti: il contenuto tecnico deve diventare un’azione compatibile con il lavoro quotidiano, altrimenti rimane una regola conosciuta ma difficile da applicare.
Domande frequenti
Un messaggio autentico è sempre sicuro?
No. Un account reale può essere compromesso o usato per una richiesta non autorizzata. L’autenticazione tecnica del messaggio non sostituisce la verifica del processo richiesto.
Una simulazione deve necessariamente inviare email?
No. Il laboratorio da tavolo permette di studiare pretesti, decisioni e procedure senza introdurre collegamenti, raccolta di dati o interazioni non previste.
Che cosa devo consegnare?
Tre schede di analisi, una procedura di verifica indipendente e due metriche del processo. Spiega come gestiresti una segnalazione tardiva senza ritardare la risposta.
Riferimento di studio: Ric Messier, CEH v12 Certified Ethical Hacker Study Guide with 750 Practice Test Questions, Wiley/Sybex, 2023, capitolo 10.
Continua il percorso
Riparti dal capitolo 11: Sniffing e Wireshark: leggere il traffico di rete. Prosegui con il capitolo 13: HTTP e sessioni: le basi della sicurezza web. L’indice dei venti capitoli è nella pagina della serie.






