Business email compromise su Microsoft 365 — il playbook di risposta

Questo playbook scatta nel momento in cui hai un segnale credibile che una casella Microsoft 365 (o Google Workspace) è sotto controllo di un attaccante: un sign-in impossible-travel, un utente che segnala un pagamento non autorizzato, un addetto amministrazione che nota un IBAN alterato su una fattura, o un alert Defender/Entra su un grant OAuth anomalo o una regola di posta appena creata.

In scope: takeover della casella, redirezione fraudolenta di pagamenti (varianti fattura-fornitore e frode-del-CEO) e la variante token-OAuth / device-code in cui l'attaccante non ha mai avuto bisogno della password.

Fuori scope: phishing di credenziali commodity senza ancora accesso alla casella (gestiscilo come un normale reset password) e compromissione Exchange on-premises (superficie di eradicazione diversa). Se sono presenti anche ransomware o estorsione-dati, esegui questo playbook in parallelo al piano ransomware — i passi di containment dell'identità qui vengono prima.

Due clock corrono insieme e nessuno aspetta la fine della tua investigation.

Il clock dei soldi. Se un bonifico fraudolento è partito, la finestra pratica di recupero si misura in ore. La FBI Financial Fraud Kill Chain funziona al meglio quando la banca originante e IC3 vengono ingaggiate entro circa 72 ore dal trasferimento fraudolento; dopo, i fondi sono di norma stratificati altrove. I richiami ACH domestici e SWIFT hanno finestre proprie, più corte e specifiche della banca. Tratta *qualsiasi* pagamento fraudolento sospetto come escalation nella stessa ora.

Il clock regolatorio. Se la casella compromessa conteneva dati personali — e quasi sempre è così — l'art. 33 GDPR ti dà 72 ore dall'awareness per notificare l'autorità di controllo. Se sei entità essenziale o importante, può scattare anche NIS2 Title 13 (early warning 24h / notifica 72h); per le entità finanziarie corre in parallelo l'art. 19 DORA.

Avvia subito un log incidente datato. Il punto *avresti dovuto sapere*, non il punto *confermato*, fa partire entrambi i clock.

Due binari corrono in parallelo. Non serializzarli.

Binario 1 — congela i soldi (lead amministrazione + legale): - Chiama l'ufficio frodi della banca originante. Richiedi un richiamo del bonifico / richiamo SWIFT sul trasferimento specifico, per numero di riferimento. - Presenta una denuncia IC3 su ic3.gov e cita la Financial Fraud Kill Chain. - Congela ogni pagamento pendente o schedulato verso la stessa controparte; ri-verifica out-of-band qualsiasi IBAN cambiato di recente, su un numero di telefono che già avevi — mai uno preso dall'email.

Binario 2 — contieni l'identità (lead SOC / IR): - Revoca sessioni e refresh token — non limitarti a resettare la password. Il solo reset password lascia un refresh token OAuth rubato pienamente valido. In Entra: disabilita l'account, poi *Revoca sessioni di accesso*, che invalida i refresh token emessi. - Resetta la password e ri-registra l'MFA da un canale noto-pulito. - Blocca l'account dal mail flow se phishing in uscita o esfiltrazione sono in corso. - Prima di cambiare qualsiasi cosa che puoi preservare, cattura Unified Audit Log e message trace dell'account (vedi checklist evidenze).

L'errore più comune a questo gate è trattare un BEC come una compromissione di password. Il BEC moderno è una compromissione di *token*.

Un reset password cambia una credenziale. L'attaccante ha piantato persistenza che gli sopravvive. Cerca e rimuovi ognuna:

• Regole di posta. Cerca regole che spostano, cancellano o segnano-come-letti i messaggi con parole come *fattura, pagamento, bonifico, banca, IBAN*, o che inoltrano a un indirizzo esterno o a una cartella oscura (Feed RSS, Cronologia conversazioni). Gli attaccanti le usano per nascondere alla vittima le sue stesse risposte.
• Inoltro posta. Controlla sia il forwarding a livello casella (indirizzo SMTP di inoltro) sia le transport rule. Rimuovi l'auto-forwarding esterno e disabilitalo a livello tenant se non hai un'esigenza di business.
• Applicazioni OAuth consentite. Rivedi le enterprise application e le app registration consentite dall'utente legate all'account. Revoca ogni grant non riconosciuto o sovra-permissivo (*Mail.ReadWrite*, *Mail.Send*, *offline_access*). È la persistenza che sopravvive a ogni reset password.
• Dispositivi e sessioni registrate. Revoca ogni dispositivo registrato o sessione di authentication-transfer che non riconosci.

Usa Microsoft Defender Threat Explorer per tracciare il lure di phishing consegnato e trovare ogni altro destinatario della stessa campagna — il takeover raramente è una casella sola.

Chiudi la porta di initial access. Il vettore dominante attuale è il phishing via device-code flow: alla vittima viene mostrata una pagina device-code Microsoft legittima e, inconsapevolmente, autorizza l'attaccante. L'advisory FBI Kali365 del maggio 2026 documenta questo kit phishing-as-a-service che fa esattamente questo su larga scala. Distribuisci una policy di Conditional Access che blocca il device code flow per tutti gli utenti tranne una lista di eccezioni documentata, e blocca la legacy authentication.

Notifica. Deposita la notifica art. 33 GDPR entro 72h se erano accessibili dati personali nella casella; deposita le notifiche NIS2 / DORA se in scope; conserva il numero di riferimento della denuncia IC3. Se dati di clienti o fornitori sono stati esposti tramite la casella, pianifica subito le notifiche a valle.

Ripristina. Riabilita l'account solo dopo che i token sono revocati, l'MFA è ri-registrata phishing-resistant (FIDO2 / passkey, non SMS), la persistenza è confermata rimossa e l'audit log è preservato. Avvisa ogni controparte che ha ricevuto phishing dalla casella compromessa — prima che anche loro bonifichino all'attaccante.

Preserva questi prima che la remediation li sovrascriva, ordinati per il gate che li consuma:

• Export Unified Audit Log dell'account (sign-in, creazione regole, grant di consenso, accesso ai messaggi) sulla finestra incidente più 30 giorni precedenti.
• Message trace dell'account (il lure in ingresso e la posta fraudolenta in uscita).
• Log di sign-in che mostrano l'uso anomalo del token: ASN/IP di origine, dispositivo e l'application ID OAuth usato.
• L'email fraudolenta con header completi, più la fattura o l'istruzione di pagamento alterata.
• Corrispondenza bancaria e numero di riferimento IC3 per il binario di richiamo fondi.
• La lista di regole di posta, indirizzi di forwarding e grant OAuth rimossi, ciascuno con timestamp e l'operatore che li ha rimossi.

La parte difficile non è la lista — è avere la telemetria quando serve. Il mailbox audit logging deve essere attivo *prima* dell'incidente, e i log di sign-in e token devono essere ritenuti abbastanza a lungo da ricostruire il takeover. È qui che una vista comportamentale continua ripaga: il pilastro AI Traffic Analysis di Zero Hunt osserva il layer comportamentale — un refresh token OAuth rigiocato da un ASN nuovo, un burst di creazione regole di posta, un pattern di esfiltrazione anomalo in uscita — i segnali che sopravvivono a un reset password e che l'MFA non vede mai, e mantiene il record datato che i gate di notifica chiederanno.

• Resettare la password e cantare vittoria. Il refresh token rubato e l'app OAuth consentita sopravvivono entrambi a un reset password. Revoca le sessioni e audita i consensi app, ogni singola volta.
• Serializzare soldi e identità. L'amministrazione aspetta che l'IT *finisca di investigare* prima di chiamare la banca, e la finestra di richiamo si chiude. Fai correre entrambi i binari nella prima ora.
• Fidarsi di un canale in-band per verificare. Confermare un IBAN cambiato rispondendo sullo stesso thread email — che la regola di posta dell'attaccante sta intercettando in silenzio. Verifica out-of-band, su un numero che già avevi.
• Distruggere la timeline. Cancellare regole e forwarding malevoli prima di esportare l'audit log, senza lasciare evidenza di cosa è stato esfiltrato e quando. Prima preserva, poi rimedia.
• Sistemare una casella sola. Il lure è andato a una lista di distribuzione; altri tre account sono già compromessi e silenti. Pivota dal messaggio consegnato a ogni destinatario.

Un singolo BEC può far scattare più regimi sulla stessa base evidenza:

• Art. 33/34 GDPR — dati personali nella casella erano accessibili: notifica all'autorità di controllo in 72h, più notifica agli interessati dove il rischio è elevato.
• NIS2 Title 13 — entità essenziali/importanti: early warning 24h, notifica 72h, report finale 1 mese. Stessa evidenza, summary diverso.
• Art. 19 DORA — entità finanziarie: reporting incidente maggiore sulla cadenza DORA.
• Forze dell'ordine — IC3 negli USA; in Italia una *denuncia* alla Polizia Postale e, per il binario di richiamo fondi, l'ufficio frodi della banca della vittima.

Costruisci la chain di evidenza una volta ed esporta per regime, invece di far girare tracce parallele. Vedi il playbook compromissione identity provider quando il takeover ha raggiunto l'IdP stesso, e l'angolo ransomware solo-esfiltrazione quando il furto della casella è il precursore dell'estorsione.