Il 3 agosto 2026 qualcosa di insolito ha iniziato ad attraversare i filtri antispam di centinaia di organizzazioni statunitensi: oltre un milione di email di richiesta pagamento, tutte diverse tra loro, tutte credibili, tutte generate in appena tre giorni. Non è la solita campagna di phishing a basso costo con errori grammaticali e loghi sgranati: secondo il report pubblicato dal Microsoft Threat Intelligence Center il 10 settembre 2026, dietro questa ondata di frodi BEC (Business Email Compromise) ci sono chiari indizi dell’uso di modelli linguistici generativi per scrivere, personalizzare e scalare l’inganno.

Per chi amministra infrastrutture di posta elettronica e sistemi di sicurezza, questa campagna è un caso di studio prezioso: mostra sia quanto l’AI stia alzando la qualità media degli attacchi di ingegneria sociale, sia quali segnali tecnici restano comunque rilevabili, se si sa dove guardare.

Anatomia della campagna

I ricercatori Microsoft hanno ricostruito una timeline precisa. Gli attaccanti hanno registrato domini “lookalike” — pensati per assomigliare a fornitori o partner legittimi — il 31 luglio 2026, pochi giorni prima del lancio operativo. Tra il 3 e il 5 agosto sono state distribuite oltre un milione di email, con l’87,7% dei destinatari concentrato negli Stati Uniti.

Il bersaglio era il personale degli uffici contabilità fornitori (accounts payable): le email si spacciavano per comunicazioni di dirigenti — CEO, CFO — che sollecitavano bonifici ACH da circa 50.000 dollari, corredati da fatture false con branding contraffatto (in diversi casi imitando ServiceNow) e sezioni “Fatturato a” personalizzate con il nome dell’azienda bersaglio.

Come si riconosce la mano dell’AI

Il dato più interessante per chi fa detection non è “che è stata usata l’AI”, ma come lo si vede. Microsoft ha individuato pattern strutturali tipici della generazione automatica di contenuti:

• Commenti HTML estesi che descrivono le sezioni del messaggio, tipicamente residui del prompt o del template usato per generare il markup
• Intestazioni di sezione tutte maiuscole e verbose, con commenti sullo stile eccessivamente dettagliati
• Uso sistematico di trattini lunghi (em dash) e divisori a banner (====================)
• Struttura a template coerente, con formattazione uniforme ma dettagli organizzativi variabili tra un’email e l’altra

In parallelo, gli attaccanti hanno anche costruito thread email interamente fittizi — conversazioni mai avvenute, presentate come inoltri — per dare l’impressione di uno scambio già in corso e abbassare la guardia del destinatario. Qui però l’AI lascia scoperture tecniche concrete: gli header di inoltro standard mancavano, il testo delle conversazioni precedenti era allineato a sinistra invece di essere formattato come citazione, e ricorrevano frasi innaturali come “no need to copy me” pensate per scoraggiare la verifica incrociata con altri colleghi.

Segnali da mettere nei playbook SOC

Riassumendo gli indicatori tecnici emersi dall’analisi, ecco cosa vale la pena monitorare attivamente:

• Mismatch tra display name e indirizzo email del mittente (nome del dirigente, dominio esterno appena registrato)
• Parole chiave finanziarie urgenti nell’oggetto (“due bill”, “ACH Payment”, “pagamento in sospeso”)
• Header email mancanti o incoerenti in messaggi presentati come inoltri
• Domini “lookalike” registrati nei giorni immediatamente precedenti l’invio massivo

Difese tecniche concrete

La prima linea di difesa resta l’autenticazione email correttamente configurata. Se il vostro dominio non ha ancora un record DMARC in modalità di enforcement, è il momento di sistemarlo:

; Esempio di record DMARC in modalità di quarantena progressiva
_dmarc.tuodominio.it. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@tuodominio.it; ruf=mailto:dmarc-forensics@tuodominio.it; fo=1"

; SPF: elenca esplicitamente solo gli host autorizzati a inviare
tuodominio.it. IN TXT "v=spf1 include:spf.protection.outlook.com -all"

Su Microsoft 365, oltre a SPF/DKIM/DMARC, vanno attivate le funzionalità di Defender for Office 365 pensate proprio per questo scenario: lo Zero-hour Auto Purge (ZAP), che mette in quarantena retroattivamente i messaggi già recapitati quando emergono nuove informazioni di threat intelligence, e l’Automatic Attack Disruption, che contiene automaticamente attacchi in corso limitando l’impatto sull’organizzazione.

Per chi vuole aggiungere una regola di trasporto mirata a intercettare l’impersonificazione dei dirigenti, un buon punto di partenza in Exchange Online PowerShell è una regola che segnala i messaggi esterni il cui nome visualizzato coincide con quello di un dirigente interno:

New-TransportRule -Name "Flag possibile impersonificazione executive" `
  -HeaderContainsMessageHeader "From" `
  -HeaderContainsWords "Mario Rossi","Giulia Bianchi" `
  -SenderDomainIs "tuodominio.it" -ExceptIfSenderDomainIs "tuodominio.it" `
  -PrependSubject "[POSSIBILE IMPERSONIFICAZIONE] " `
  -Mode Enforce

Da ultimo, la parte umana del processo resta insostituibile: la verifica dei pagamenti ad alto valore va fatta fuori banda, ad esempio con una telefonata a un numero già noto (mai a un numero indicato nell’email stessa), e il personale amministrativo va addestrato periodicamente a riconoscere questi pattern — Microsoft mette a disposizione l’Attack Simulation Training in Defender for Office 365 proprio per esercitazioni realistiche su scenari di questo tipo.

Conclusione

Questa campagna conferma una tendenza che i team di sicurezza dovrebbero dare ormai per acquisita: l’AI generativa non introduce necessariamente nuove tecniche di attacco, ma innalza drasticamente la qualità e la scala di quelle esistenti, rendendo la BEC “tradizionale” più difficile da distinguere da una comunicazione legittima. La buona notizia è che gli stessi strumenti di detection basati su pattern e comportamento — autenticazione email, regole di trasporto mirate, ZAP, attack disruption — restano efficaci, a patto di tenerli configurati e aggiornati. La differenza, oggi più che mai, la fa la disciplina nella configurazione, non l’ennesimo layer di prodotto.

Fonte: Microsoft Security Blog, via Petri IT Knowledgebase