Phishing Microsoft 365 nonostante MFA: sessioni rubate

Il phishing Microsoft 365 non si limita a e-mail scadenti e pagine di accesso contraffatte. Gli attacchi iniziano da un account aziendale compromesso, conducono a pagine Microsoft ingannevoli o legittime e, nonostante l’MFA, terminano nella casella di posta, in SharePoint o in Teams.

Il Rapporto semestrale 2026/1 dell’Ufficio federale della cibersicurezza riguarda anche le imprese svizzere. Nel primo semestre del 2026 sono aumentate le segnalazioni di account Microsoft 365 compromessi, utilizzati per phishing e frodi. Gli aggressori si sono presentati come helpdesk IT o dirigenti e hanno aggirato i controlli mediante token di sessione, Device Code Phishing o reverse proxy.

L’MFA resta indispensabile. Non tutti i metodi sono resistenti al phishing. Una sessione confermata può diventare il bersaglio dell’attacco. Microsoft 365 deve essere protetto come piattaforma di identità, non soltanto come servizio di posta elettronica.

Come funziona il phishing Microsoft 365 nonostante l’MFA

Dopo aver verificato password, secondo fattore, stato del dispositivo e condizioni, Entra ID emette token o cookie di sessione. Come per un pass visitatori, da quel momento conta soprattutto la loro validità. Se finiscono nelle mani di un’altra persona, questa potrebbe non dover ripetere la verifica.

I tipi di token in Microsoft Entra ID differiscono per scopo e durata. L’aspetto decisivo è questo: un token rubato o concesso all’aggressore può rappresentare una sessione autenticata.

Adversary-in-the-Middle Phishing con reverse proxy

In un attacco Adversary-in-the-Middle (AiTM), l’infrastruttura di phishing si colloca tra il browser e Microsoft e inoltra l’accesso reale in tempo reale:

1. Un’e-mail rimanda, ad esempio, a un documento SharePoint, un messaggio vocale, una fattura o una firma.
2. Il link conduce all’accesso Microsoft attraverso il reverse proxy dell’aggressore.
3. Nome utente, password e risposta MFA vengono inoltrati a Microsoft.
4. Microsoft accetta l’accesso confermato e crea la sessione.
5. Il proxy intercetta il cookie di sessione o i token. L’accesso termina soltanto alla scadenza, alla revoca o al blocco.

L’MFA non è stata violata. L’utente ha confermato una sessione intercettata. I codici TOTP e le conferme push non impediscono per principio questo relay. Le chiavi FIDO2, Windows Hello for Business e i passkey implementati correttamente vincolano invece crittograficamente l’accesso al servizio legittimo. Tuttavia, neppure questi metodi proteggono dal malware su un dispositivo già autenticato o da ogni forma di furto della sessione.

Device Code Phishing tramite una pagina Microsoft autentica

Il Device Code Flow è previsto per dispositivi privi di una modalità di immissione comoda. Un dispositivo per sale riunioni o un programma da riga di comando mostra un codice che viene confermato su un secondo dispositivo tramite Microsoft.

Gli aggressori avviano personalmente la procedura e inviano il codice con un pretesto. Dopo il suo inserimento sulla pagina Microsoft autentica, i token finiscono nella loro sessione. Il dominio e il certificato sono corretti, ma viene autorizzato un accesso estraneo. Microsoft classifica questo flusso come rischioso e consiglia di bloccarlo in assenza di una necessità documentata.

Raffica di e-mail, falso supporto IT e phishing a catena

Una catena di attacco può iniziare con centinaia di e-mail di newsletter, registrazione e notifica. Queste generano stress e nascondono gli avvisi reali. In seguito, un presunto supporto IT contatta l’utente tramite Teams o telefono e richiede Quick Assist o uno strumento di accesso remoto. In questo modo è possibile eseguire comandi, installare malware, leggere i dati del browser e rubare credenziali. A essere compromessa è la postazione di lavoro, non l’accesso.

Dopo la compromissione, l’aggressore sfrutta corrispondenza autentica, fornitori noti e conversazioni esistenti per inviare fatture manipolate, condurre ulteriori campagne di phishing e compromettere altri account. SPF, DKIM e DMARC non bastano quando il messaggio proviene dal tenant Microsoft 365 legittimo.

Cosa offre l’MFA e dove incontra i suoi limiti

L’MFA impedisce molte compromissioni degli account perché la password da sola non è più sufficiente. I metodi si distinguono come segue:

• Password più SMS, chiamata o semplice conferma push: meglio della sola password, ma vulnerabile a social engineering, SIM swapping, MFA fatigue e phishing in tempo reale.
• TOTP o Authenticator con Number Matching: più resistente alle conferme accidentali, ma un codice può essere inoltrato direttamente da una pagina AiTM.
• Autenticazione resistente al phishing: FIDO2, Windows Hello for Business, autenticazione basata su certificati e passkey verificano crittograficamente il servizio legittimo e riducono nettamente gli accessi AiTM.

Restano altri rischi: un endpoint infetto può leggere le sessioni, un’applicazione OAuth può ottenere autorizzazioni permanenti e un utente può confermare Device Code estranei o accessi remoti. L’MFA resistente al phishing è fondamentale, ma non costituisce da sola un concetto di sicurezza completo.

Rafforzare Microsoft Entra ID in modo efficace

Conditional Access e Token Protection richiedono licenze Entra adeguate, mentre le condizioni sui dispositivi presuppongono una base di dispositivi gestiti. Le policy devono essere verificate prima in modalità Report-only con un gruppo pilota.

Dare priorità all’autenticazione resistente al phishing

Il primo rollout dovrebbe includere amministratori, responsabili finanziari, direzione e helpdesk. In questi gruppi, le Authentication Strengths di Conditional Access possono imporre Windows Hello for Business, chiavi FIDO2, passkey o autenticazione basata su certificati.

Serve inoltre un processo di recovery con almeno due metodi registrati, dispositivi sostitutivi verificati e account di emergenza monitorati separatamente. La perdita di una chiave non deve causare né interruzioni prolungate né eccezioni dell’helpdesk facilmente manipolabili. I passkey sono adatti anche per l’accesso a Sophos Central, ma anche in questo caso occorre pianificare il recovery e il cambio di dispositivo.

Verificare e, se possibile, bloccare il Device Code Flow

L’utilizzo può essere inventariato nei Sign-in Logs di Entra mediante Authentication protocol > Device code. Dispositivi per sale riunioni, strumenti meno recenti o applicazioni da riga di comando potrebbero dipendere da questo flusso. Senza una necessità motivata, in Entra ID > Conditional Access > Policies viene creata una policy:

1. Selezionare gli utenti o i gruppi standard.
2. Escludere gli account di emergenza e le eccezioni tecniche motivate.
3. In Target resources, scegliere se possibile All resources; utilizzare obiettivi più limitati solo con una motivazione.
4. In Conditions > Authentication flows, attivare Device code flow.
5. In Grant, bloccare l’accesso.
6. Utilizzare prima Report-only, controllare i log e attivare la policy soltanto in seguito.

Le eccezioni devono essere strettamente limitate, documentate e associate a specifici account o risorse.

Vincolare l’accesso a dispositivi gestiti

Conditional Access può richiedere un dispositivo conforme o connesso a Microsoft Entra per le applicazioni sensibili. Ciò rende più difficile l’abuso dei token su dispositivi sconosciuti, ma coinvolge anche BYOD, ospiti, dispositivi mobili e client speciali. È quindi necessario conoscere l’inventario dei dispositivi, i sistemi operativi e le applicazioni. Record obsoleti, enrollment debole o eccezioni troppo ampie compromettono il controllo.

Testare Token Protection in modo mirato

Token Protection vincola crittograficamente i Sign-in-Session-Token supportati al dispositivo per il quale sono stati emessi e rende più difficile il replay su altri sistemi. La funzione richiede Entra ID P1 e copre soltanto determinate piattaforme, applicazioni e risorse. In Windows protegge soprattutto le applicazioni Microsoft 365 native supportate. I dispositivi Apple richiedono una gestione e il Microsoft Enterprise SSO Plug-in. Le app Mail e Calendario di Apple attualmente non supportano Token Protection.

L’introduzione inizia con un perimetro ristretto in modalità Report-only. In seguito vengono verificati nei Sign-in Logs Token Protection Status Details, client e risorse. L’applicazione effettiva della policy avviene soltanto dopo aver confermato la compatibilità. Browser, software legacy e dispositivi speciali vengono valutati separatamente.

Controllare Teams e l’accesso remoto

Occorre stabilire quali domini o tenant esterni possano contattare gli utenti tramite Teams e come rendere riconoscibili i partecipanti esterni. Per il supporto valgono queste regole:

• L’accesso remoto viene avviato soltanto con un ticket o una richiamata verificata a un numero noto.
• Le sessioni Quick Assist inattese provenienti da chat o telefonate non vengono accettate.
• Gli strumenti di accesso remoto consentiti sono documentati e monitorati.
• Gli strumenti RMM sconosciuti vengono bloccati o segnalati mediante Application Control, AppLocker, Windows Defender Application Control o controlli equivalenti.
• Una raffica insolita di e-mail viene segnalata all’IT o al team Security e non viene trattata soltanto come spam.

La formazione deve riprodurre questi processi. Sophos Phish Threat diventa più efficace con canali di segnalazione chiari, scenari Teams e un runbook realistico per l’helpdesk.

Quali tracce devono verificare gli amministratori

Un evento MFA riuscito non dimostra che l’accesso fosse legittimo. In caso di AiTM o Device Code, il fattore potrebbe essere stato confermato dall’utente stesso. Identità, casella di posta, endpoint e comunicazioni devono essere analizzati insieme.

Microsoft Entra Sign-in Logs

I log si trovano in Entra ID > Monitoring & health > Sign-in logs e sono consultabili dal ruolo Reports Reader in su. A seconda del sospetto, l’analisi deve includere accessi interattivi e non interattivi, Service Principals e Managed Identities. Sono rilevanti:

• dispositivi sconosciuti o non conformi, nonché IP, regioni, applicazioni e client insoliti,
• Device code come Authentication Protocol,
• nuove combinazioni di browser o dispositivo dopo un accesso normale,
• accessi insoliti a Exchange Online, SharePoint o Microsoft Graph,
• esito di Conditional Access, requisiti di autenticazione soddisfatti e
• accessi riusciti senza l’interazione prevista dell’utente tramite token esistenti.

Un singolo segnale non basta. Un indirizzo IP svizzero può appartenere a una rete mobile o a una VPN, mentre un accesso dall’estero può essere legittimo. È decisiva la combinazione di utente, dispositivo, orario, applicazione e attività successiva.

Exchange Online, audit ed endpoint

Dopo una compromissione, gli aggressori cercano spesso fatture e conversazioni. Occorre controllare inoltri interni ed esterni, Inbox Rules visibili e nascoste, deleghe e autorizzazioni Send-as, attività insolite di ricerca, lettura, download e invio, nuovi consensi OAuth ed Enterprise Applications, metodi di autenticazione modificati e tutti i messaggi inviati nel periodo interessato.

In caso di falso supporto IT, le tracce si trovano sull’endpoint: programmi di accesso remoto, download, PowerShell, MSHTA, attività pianificate, accessi al browser e processi sospetti. La sicurezza e-mail, Endpoint Protection, XDR o MDR possono bloccarli e correlarli, se le fonti dati sono coperte dalle licenze, integrate e monitorate. La strategia Sophos Fusion contribuisce a questo obiettivo, ma non sostituisce né Conditional Access né il processo di incident response.

La conservazione e il livello di dettaglio dei dati di audit dipendono dalla licenza e dalla configurazione. Entrambi devono essere chiariti in anticipo, perché i log attivati successivamente non creano dati storici.

Piano di emergenza per un account Microsoft 365 compromesso

Cambiare la password non basta. Le sessioni, i metodi MFA estranei, i consensi OAuth e le regole della casella di posta possono rimanere attivi.

1. Utilizzare un dispositivo di amministrazione pulito

Se si sospetta la compromissione dell’endpoint, la modifica della password e le attività amministrative devono avvenire da un altro dispositivo. Il sistema interessato viene isolato senza cancellare precipitosamente le tracce. In caso di attacco in corso o di account privilegiato, può essere utile una disattivazione temporanea.

2. Revocare le sessioni attive

Le sessioni possono essere revocate nell’Entra Admin Center o con Microsoft Graph PowerShell:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

L’User Principal Name deve essere adattato. A seconda dell’applicazione, del tipo di token e di Continuous Access Evaluation, l’accesso può continuare per breve tempo. Il risultato deve quindi essere verificato nei log e nelle applicazioni.

3. Cambiare la password e ripulire l’autenticazione

La password viene modificata nella fonte di identità primaria; per gli account sincronizzati o federati, nell’Active Directory locale o nell’Identity Provider. Successivamente vengono controllati metodi MFA, passkey, numeri di telefono, dispositivi e Temporary Access Pass, rimuovendo le voci estranee. In presenza di malware o accesso remoto, l’endpoint viene analizzato in parallelo e, se necessario, ricostruito.

4. Controllare consensi OAuth e ruoli

I consensi degli utenti, le Enterprise Applications e i Service Principals sospetti possono consentire un accesso permanente. Per gli account privilegiati vengono controllati anche i ruoli Entra, Azure e Microsoft 365.

5. Controllare inoltri e Inbox Rules

Exchange Online PowerShell mostra le impostazioni centrali della casella di posta:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Le regole sospette vengono documentate e rimosse. Deleghe, autorizzazioni Send-as e regole di trasporto amministrative vengono controllate separatamente.

6. Individuare e informare le vittime successive

Message Trace e i dati di audit mostrano i messaggi inviati. I destinatari interni ed esterni devono essere informati prima che link, pagamenti o altri account vengano coinvolti. In caso di variazioni nei pagamenti, banca, contabilità e partner commerciali vengono contattati tramite canali noti. L’articolo sulle misure immediate in caso di phishing e hacking descrive ulteriori passaggi.

7. Determinare causa e portata

Infine occorre chiarire se siano stati coinvolti AiTM, Device Code, MFA confermata o accesso remoto, quali file SharePoint o OneDrive siano stati sottratti, se siano stati registrati altri account, applicazioni o dispositivi e se siano interessati dati personali o segreti aziendali. Senza un’analisi delle cause, la vulnerabilità rimane aperta.

Checklist pratica per amministratori Microsoft 365

• Dare priorità all’autenticazione resistente al phishing per amministratori, finanza, direzione e helpdesk.
• Mantenere separati gli account di emergenza, monitorarli e testarli regolarmente.
• Inventariare l’utilizzo del Device Code, bloccarlo o autorizzare eccezioni motivate.
• Verificare Conditional Access in modalità Report-only con un gruppo pilota.
• Richiedere dispositivi gestiti per le risorse sensibili e distribuire Token Protection soltanto con client compatibili.
• Regolamentare in modo vincolante le comunicazioni Teams esterne, gli strumenti di accesso remoto, la richiamata dell’helpdesk e la verifica dell’identità.
• Impostare avvisi per raffiche di e-mail, accessi insoliti, consensi OAuth e inoltri.
• Testare revoca delle sessioni, ripristino MFA, Inbox Rules, tracce di invio e isolamento degli endpoint.
• Chiarire prima dell’incidente la conservazione dei dati di audit e le responsabilità.

La mia raccomandazione

L’MFA resta obbligatoria, ma la combinazione di password e app push non tiene sufficientemente conto degli attacchi moderni. Per prima cosa, gli account privilegiati e finanziariamente critici devono passare a un’autenticazione resistente al phishing. Seguono il controllo del Device Code, i dispositivi gestiti e Conditional Access. A causa dei suoi limiti, Token Protection richiede un rollout controllato. Parallelamente, l’helpdesk deve disporre di procedure sicure per i contatti Teams inattesi.

È decisiva la combinazione di identità forte, dispositivo attendibile, sessione controllata, comunicazione monitorata e un piano di emergenza per token attivi e persistenza nascosta.

FAQ