Bombardamento Email: Email Bombing (T1667)
L'Email Bombing è una tecnica di Impact (TA0040) catalogata da MITRE ATT&CK come T1667, in cui l'attaccante inonda una casella di posta bersaglio con un volume abnorme di messaggi, spesso migliaia in pochi minuti. L'obiettivo non è compromettere direttamente il sistema di posta, ma saturare l'attenzione della vittima, seppellendo tra lo spam messaggi legittimi come alert di sicurezza, ticket helpdesk, notifiche bancarie o corrispondenza operativa.
La modalità operativa più diffusa sfrutta bot che iscrivono l'indirizzo bersaglio a centinaia di newsletter e mailing list che non validano la registrazione tramite double opt-in. Il risultato è una valanga di email tecnicamente legittime, provenienti da mittenti reali, che aggirano molti filtri antispam basati su reputazione.
Questo rumore digitale è frequentemente il preludio a un attacco di social engineering: dopo aver disorientato la vittima, l'attaccante la contatta telefonicamente fingendosi supporto IT (Spearphishing Voice) e la induce a installare software di accesso remoto come AnyDesk o Quick Assist. Da qui, la catena prosegue verso furto credenziali, deploy ransomware o frode finanziaria.
Il gruppo Storm-1811 ha adottato sistematicamente questo pattern, combinando volumi massicci di spam non malevolo con chiamate vishing per ottenere accesso iniziale a workstation aziendali. La tecnica è quindi un moltiplicatore di efficacia per campagne più ampie, non un fine in sé.
In un esercizio red team autorizzato, la simulazione di Email Bombing richiede cornici legali molto rigide: consenso scritto del cliente, indirizzo bersaglio isolato (una casella dedicata al test, mai produttiva) e coordinamento con il provider di posta per evitare blacklist del dominio corporate. Senza queste tutele si rischia abuso di servizi terzi e violazione di ToS.
Dal punto di vista tecnico, la simulazione ricalca il comportamento reale attraverso due vettori. Il primo è la subscription bomb: uno script itera su un elenco di form di iscrizione a newsletter pubbliche inviando l'indirizzo target. Strumenti come Selenium (open source) o Playwright (open source) permettono di automatizzare la compilazione di form CAPTCHA-free. Il carico legale ricade interamente sull'operatore, quindi in laboratorio si usa un web server interno con endpoint di iscrizione fittizi ospitati su infrastruttura controllata, senza toccare servizi reali.
Il secondo vettore è la generazione diretta di traffico SMTP verso un mail server di test. Con swaks (open source, Swiss Army Knife for SMTP) si può scriptare l'invio di N messaggi:
swaks --to victim@lab.local --from noise@test.local --server smtp.lab.local --body "test" --header "Subject: Newsletter #$i"
iterato in un ciclo bash. Per volumi più elevati, smtp-source (incluso in Postfix, open source) genera migliaia di messaggi al minuto:
smtp-source -s 20 -l 1024 -m 5000 -f sender@test.local -t victim@lab.local smtp.lab.local:25
La componente più realistica di un red team maturo è però la catena completa Storm-1811-style: dopo il bombing, l'operatore simula una chiamata di vishing al bersaglio (con script concordato), lo guida all'apertura di Quick Assist (integrato in Windows 10/11) o AnyDesk (freemium), e documenta se l'utente autorizza la sessione remota. Questa fase è la vera misura di efficacia: il bombing è solo il rumore di copertura.
Per la parte di payload post-accesso, in lab si usano framework come Sliver (open source) o Havoc (open source) per emulare C2, evitando Cobalt Strike se non disponibile su licenza. La documentazione del test deve includere metriche precise: numero di email consegnate, tempo di reazione dell'utente, tempo di detection del SOC, tempo di contenimento. Sono questi i KPI che trasformano l'esercizio in valore difensivo.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.