Email Bombing: T1667

Per simulare un email bombing in ambiente controllato serve un'infrastruttura lab isolata: un mail server locale — Postfix su Linux o hMailServer (open source) su Windows — e caselle di test senza esposizione esterna. L'obiettivo è verificare se i controlli di rate limiting, le regole anti-spam e le procedure di escalation del SOC reggono sotto pressione.

Lo strumento più diretto è swaks (open source), lo "Swiss Army Knife for SMTP" disponibile nei repository di quasi tutte le distribuzioni Linux. Un ciclo bash che invoca swaks ripetutamente simula l'effetto valanga:

for i in $(seq 1 500); do swaks --to vittima@lab.local --from "newsletter-${i}@spam.local" --server 127.0.0.1 --header "Subject: Conferma iscrizione newsletter #${i}" --body "Benvenuto nella nostra mailing list."; done

Questo comando genera 500 email con mittenti diversi, replicando il pattern di iscrizione massiva a newsletter. Variando il campo Subject e il corpo del messaggio si aumenta il realismo e si testa la capacità dei filtri di aggregare messaggi eterogenei.

Per scenari più sofisticati, si può usare GoPhish (open source), normalmente impiegato per campagne di phishing simulato, configurando un template generico e un gruppo target con un singolo destinatario. GoPhish permette di schedulare l'invio e registrare le metriche di consegna, utile per misurare quanti messaggi raggiungono effettivamente la inbox prima che i controlli intervengano.

Su ambienti Microsoft 365 di laboratorio, il modulo PowerShell Send-MailMessage (nativo in Windows PowerShell) offre un'alternativa rapida:

1..200 | ForEach-Object { Send-MailMessage -From "bot$@lab.local" -To "vittima@lab.local" -Subject "Aggiornamento servizio #$" -Body "Messaggio automatico." -SmtpServer smtp.lab.local }

Durante la simulazione, misurate tre parametri chiave: il tempo di saturazione della inbox (quanti messaggi servono prima che l'utente perda visibilità sulle email legittime), il tempo di detection del SOC e il tempo di reazione dell'helpdesk. Se l'organizzazione target utilizza regole di trasporto Exchange, verificate se il rate limiting scatta e dopo quante email. Documentate anche se la vittima riceve notifiche push su dispositivi mobili — l'effetto denial-of-service si estende anche lì.

La sfida nel detectare l'email bombing sta nel distinguere un picco anomalo dal rumore fisiologico di una casella molto attiva. La detection strategy documentata (DET0355) fornisce quattro analytic complementari che coprono l'intero spettro operativo.

Su ambienti Windows e Microsoft 365, la sorgente primaria è il log unificato m365:unified, dove ogni messaggio in ingresso genera un evento con destinatario, mittente, oggetto e dimensione degli allegati. L'analytic AN1008 suggerisce di aggregare il conteggio dei messaggi per destinatario entro una finestra temporale configurabile — il parametro [TimeWindow] — e confrontarlo con una soglia massima, il [RecipientThreshold]. In pratica, una regola in Splunk (a pagamento) o Microsoft Sentinel (freemium) può raggruppare gli eventi MessageReceived per RecipientAddress in bucket da 5 minuti e triggerare quando il conteggio supera, ad esempio, 150 messaggi.

La correlazione con Sysmon (EventID 11 — FileCreate) permette di catturare la creazione massiva di allegati nelle directory cache di Outlook. Quando centinaia di file .eml o .msg appaiono in %LOCALAPPDATA%\Microsoft\Outlook\ nel giro di pochi minuti, è un segnale robusto.

Su Linux, l'analytic AN1009 punta ai log del mail server — Postfix scrive ogni transazione in /var/log/mail.log. Un conteggio delle righe contenenti status=sent o to=<vittima@dominio> aggregato per minuto e confrontato con il [MailVolumeThreshold] costituisce l'alert di base. Il log auditd:SYSCALL aggiunge visibilità sulle scritture in /var/mail/ e /var/spool/mail/, catturando la syscall write associata al processo del MDA.

Per macOS (AN1011), i log unificati (log show --predicate 'process == "Mail"') espongono l'attività di Mail.app. La creazione ripetitiva di file sotto ~/Library/Mail/ con timing anomalo è l'indicatore chiave, regolato dal [FileCountThreshold].

L'analytic AN1010 per le suite Office monitora i log m365:exchange alla ricerca di pattern di consegna massiva verso singoli utenti, con il parametro [UserContext] che permette di differenziare utenti VIP — CISO, CFO, helpdesk — da caselle generiche, applicando soglie più basse per i profili ad alto rischio.

Per ridurre i falsi positivi, escludete le mailing list interne autorizzate e i sistemi di ticketing che generano notifiche ad alto volume. Una whitelist basata sui domini mittenti noti abbatte il rumore senza sacrificare la copertura.

Quando l'email bombing è sospettato come precursore di un'intrusione più ampia, la ricostruzione della timeline deve partire dalla casella di posta e allargarsi a cerchi concentrici verso endpoint e rete.

Il primo artefatto da acquisire è il log di consegna lato server. Su Exchange Online, il Message Trace — esportabile dal portale di amministrazione o tramite il cmdlet PowerShell Get-MessageTrace — restituisce mittente, destinatario, timestamp e stato di consegna per ogni messaggio. Filtrando per la casella vittima e ordinando per data, si ottiene l'esatto profilo temporale del bombing: inizio, picco, durata e volume totale.

Get-MessageTrace -RecipientAddress vittima@dominio.com -StartDate "2025-01-15 08:00" -EndDate "2025-01-15 12:00" | Sort-Object Received | Export-Csv bombing_trace.csv

Su server Postfix, il file /var/log/mail.log contiene le stesse informazioni in formato testuale. Un parsing con grep e awk estrae rapidamente il conteggio per minuto:

grep "to=vittima@dominio" /var/log/mail.log | awk '{print $1,$2,$3}' | uniq -c | sort -rn | head -20

Lato endpoint Windows, gli artefatti rilevanti si trovano nella cache locale di Outlook: i file .ost e .pst in %LOCALAPPDATA%\Microsoft\Outlook\ registrano ogni messaggio scaricato. L'analisi con Kernel OST Viewer (freemium) o pffexport da libpff (open source) permette di estrarre gli header completi, inclusi i campi Received che tracciano il percorso SMTP di ogni messaggio. La presenza di centinaia di header con server diversi ma timestamp ravvicinati conferma il pattern di iscrizione massiva a newsletter.

Su macOS, la struttura ~/Library/Mail/V*/ contiene i messaggi in formato .emlx. I metadati del filesystem — timestamp di creazione ottenibili con stat o con mac_apt (open source) — costruiscono una timeline granulare della ricezione.

L'elemento critico è la correlazione temporale con l'attività post-bombing. Cercate nei log del centralino VoIP o nel registro chiamate del dispositivo della vittima eventuali telefonate in ingresso entro 15-60 minuti dal picco di spam. Se trovate evidenza di installazione di software di accesso remoto — AnyDesk, TeamViewer, Quick Assist — nei log Sysmon (EventID 1 — ProcessCreate) o negli artefatti di esecuzione come Prefetch e AmCache, avete la catena completa: bombing → vishing → compromissione.

I log DNS dell'endpoint, catturati da Sysmon EventID 22 (DNSQuery), possono rivelare risoluzioni verso domini di C2 avvenute subito dopo l'installazione del tool remoto, chiudendo il cerchio della kill chain.

Il panorama threat intelligence per l'email bombing è attualmente concentrato su un singolo cluster di attività documentato, ma il pattern operativo che emerge è estremamente indicativo di una tendenza in crescita nell'ecosistema ransomware.

Storm-1811 è il gruppo di riferimento per questa tecnica. Il loro modus operandi è caratteristico: dispiegano grandi volumi di spam email non malevolo — newsletter, conferme di registrazione, notifiche di servizio — verso le caselle delle vittime. Lo spam non contiene payload o link malevoli, il che lo rende invisibile ai filtri anti-phishing tradizionali. Il vero attacco arriva nella fase successiva, quando un operatore contatta telefonicamente la vittima spacciandosi per il supporto IT o l'helpdesk aziendale, offrendo assistenza per "risolvere" il problema dell'inbox intasata.

Questo schema a due fasi — disruption digitale seguita da social engineering vocale — rappresenta un'evoluzione significativa rispetto al phishing tradizionale. Storm-1811 sfrutta il principio psicologico dell'urgenza: la vittima è già frustrata e sotto pressione per il bombing, quindi è molto più propensa ad accettare aiuto non sollecitato. L'obiettivo finale del gruppo converge verso l'installazione di software di accesso remoto, furto di credenziali e, nelle fasi terminali, deployment di ransomware o furto finanziario diretto.

Dal punto di vista dell'analisi predittiva, il pattern di Storm-1811 suggerisce diversi sviluppi da monitorare. Il bombing come precursore di vishing è una tecnica a basso costo e alta scalabilità: non richiede exploit, non richiede infrastruttura C2 nella fase iniziale, e il volume di spam proveniente da fonti legittime rende inefficaci le blacklist tradizionali. È ragionevole aspettarsi che altri cluster ransomware adottino la stessa metodologia.

Per il monitoraggio proattivo, integrate nei vostri feed i domini di newsletter abuse — servizi di iscrizione massiva senza double opt-in — e tracciate le segnalazioni di bombing ricevute dall'helpdesk interno come indicatori anticipatori di possibili tentativi di vishing. La correlazione tra ticket di supporto per "spam improvviso" e chiamate telefoniche non sollecitate nelle ore successive è il segnale più forte che la catena di attacco è in corso.

Le due mitigazioni documentate — User Training (M1017) e Software Configuration (M1054) — riflettono la natura duale della difesa: da un lato addestrare gli utenti a riconoscere lo schema bombing-vishing e a non fidarsi di chiamate non verificate, dall'altro configurare meccanismi di autenticazione email come SPF, DKIM e DMARC per filtrare almeno la componente di spam con mittenti spoofati.

Framework MITRE ATT&CK: tecnica T1667 (Email Bombing), tattica TA0040 (Impact), gruppo G1046 (Storm-1811), mitigazioni M1017, M1054, detection DET0355 con analytic AN1008, AN1009, AN1010, AN1011. Integrato con conoscenza professionale per tool e procedure operative.