Tre domande diverse, tre strumenti diversi

Quando un incidente tocca Microsoft 365, il SOC si pone tre domande che l’esame tende a mescolare di proposito. Quale azione è stata compiuta, da chi e quando? Risponde Microsoft Purview Audit. Che cosa conteneva davvero quel messaggio o quel file? Risponde Content search in Microsoft Purview eDiscovery. Chi ha chiamato l’API, con quale applicazione e con quale token? Rispondono i Microsoft Graph activity log.

Il criterio di scelta non è il prodotto ma il tipo di evidenza che serve: un record di attività, un contenuto, una chiamata API. Sbagliare strumento in un incident di business email compromise significa concludere “non risulta nulla” quando l’evidenza esiste, semplicemente altrove.

Purview Audit: chi ha fatto cosa e quando

L’unified audit log raccoglie le operazioni dei workload Microsoft 365 e di Microsoft Entra ID: accessi, creazione di regole di posta, condivisioni di file, download da SharePoint e OneDrive, modifiche di ruolo, accesso ai messaggi in cassetta. È la fonte primaria per ricostruire la timeline di un account compromesso. La ricerca si esegue dal portale Microsoft Purview oppure via PowerShell con Search-UnifiedAuditLog, quando serve un output ripetibile o un intervallo ampio.

Due dettagli contano per la scelta. Il primo è la retention: il piano Audit (Standard) conserva i record per un periodo limitato, mentre Audit (Premium) abilita una conservazione più lunga tramite audit log retention policy e alcuni eventi di forensics aggiuntivi — su tutti l’accesso ai singoli messaggi di posta, decisivo per stimare l’esposizione dei dati in un BEC. Il secondo è che l’audit search non genera alert: è una ricerca investigativa, non un rilevamento. Se serve una detection continua, l’attività M365 va portata in Microsoft Sentinel o interrogata in advanced hunting (per esempio CloudAppEvents per le attività applicative viste da Defender for Cloud Apps).

Content search in eDiscovery: cosa c’era dentro

Purview Audit dice che un file è stato scaricato e che una mail è stata letta; non dice cosa contenevano. Per questo serve Content search, che indicizza e cerca dentro i contenuti — corpo dei messaggi, allegati, documenti in SharePoint e OneDrive, chat di Teams — e permette anteprima ed export delle evidenze. Nella suite eDiscovery le ricerche vivono dentro un caso, con hold e review set quando il materiale deve essere preservato per fini legali.

Nel security operations serve tipicamente a due cose: quantificare l’esposizione (quali dati sensibili erano nei messaggi effettivamente acceduti) e trovare tutte le copie di un contenuto malevolo o riservato. Non è invece lo strumento di remediation della posta: la rimozione di campagne di phishing dalle cassette è un’azione di Microsoft Defender for Office 365.

Graph activity log: quando l’attaccante passa dall’API

Dopo un illicit consent grant o un furto di token, l’attaccante spesso non tocca mai un’interfaccia: legge la posta e scarica file chiamando Microsoft Graph con l’identità di un’applicazione. I Microsoft Graph activity log registrano proprio queste richieste API — endpoint invocato, applicazione chiamante, identità, esito, indirizzo di origine — e sono l’unica fonte che distingue “l’utente ha fatto” da “un’app ha fatto per conto dell’utente”.

Due vincoli operativi decidono se saranno disponibili quando servono: richiedono una licenza Microsoft Entra ID P1 o superiore e vanno instradati in anticipo verso una destinazione (Log Analytics workspace, storage account, event hub) tramite diagnostic setting. Non esiste una raccolta retroattiva: se non erano configurati prima dell’attacco, quei dati non esistono. Una volta in workspace si correlano con SigninLogs e AuditLogs per legare la sessione, il token e l’app usata.

Trappole tipiche d’esame

  • Ricostruire quali messaggi l’attaccante ha aperto → Purview Audit, non Content search: l’audit registra l’accesso ai messaggi; il contenuto di quei messaggi si esamina poi con Content search. Prima la lista, poi il contenuto.
  • Rimuovere dalle cassette le mail di una campagna di phishing → Defender for Office 365, non eDiscovery: la remediation della posta è un’azione di risposta nel portale Microsoft Defender XDR; eDiscovery serve a cercare e preservare, non a bonificare.
  • Esfiltrazione senza alcun sign-in interattivo sospetto → Microsoft Graph activity log: se l’azione è passata da un’applicazione con consent abusivo, il segnale sta nelle chiamate API; ricordati che devono essere già instradati via diagnostic setting.
  • Query di Content search → Keyword Query Language, non Kusto: nelle ricerche eDiscovery non si scrivono pipeline KQL su tabelle di advanced hunting; sono due linguaggi diversi con lo stesso acronimo.
  • Analista che deve solo consultare l’audit → ruolo View-Only Audit Logs: assegnare eDiscovery Manager o un ruolo amministrativo globale per una semplice ricerca viola il least privilege ed è la risposta sbagliata.
  • Serve un rilevamento continuo sulle attività M365 → analytics rule in Microsoft Sentinel o custom detection rule in Defender XDR: una ricerca nell’audit log resta manuale e non produce alcun alert né incident.