Da fine maggio 2026 stanno circolando email di phishing che mettono in difficoltà anche chi è abituato a riconoscerle: arrivano dall’account ufficiale Microsoft account-security-noreply@accountprotection.microsoft.com, superano i filtri antispam aziendali, sono firmate correttamente con DKIM e SPF, e sembrano in tutto e per tutto avvisi legittimi di sicurezza del proprio tenant Microsoft 365.
Il messaggio tipico avverte di un “tentativo di accesso sospetto” e invita a verificare l’identità chiamando un numero di telefono che — naturalmente — non è di Microsoft. È a quel punto che parte la fase voice della truffa: un finto operatore del supporto chiede di approvare una notifica push sull’app Authenticator o di leggere a voce un codice 2FA, ottenendo così l’accesso completo all’account anche se la vittima ha la multifactor authentication correttamente attiva.
Come fanno a inviare email dal vero dominio Microsoft
La tecnica sfrutta un abuso del servizio di notifiche di Microsoft 365: l’attaccante registra un finto tenant Microsoft, configura un alias o un alert di sicurezza in modo che le email di sistema vengano inviate alla vittima — partendo però dal mittente legittimo noreply@accountprotection.microsoft.com. I filtri antispam (incluso EOP, Exchange Online Protection) considerano il mittente affidabile perché lo è davvero: l’email viene davvero da un server Microsoft.
Variante più sofisticata: l’attaccante crea contenuto di phishing dentro Microsoft Forms o OneNote (ospitati sui domini forms.office.com e onenote.com, in whitelist ovunque) e invia il link via email da un account compromesso. La pagina di phishing è ospitata su infrastruttura Microsoft — certificato SSL ufficiale, dominio in whitelist, nessun warning del browser.
Perché la 2FA da sola non basta
L’autenticazione a due fattori protegge il login. Non protegge da:
- Voice phishing (vishing) — la vittima approva manualmente la notifica push sull’app Authenticator perché crede di parlare con il supporto Microsoft.
- OAuth consent phishing — l’attaccante non chiede la password, chiede di concedere permessi a un’app malevola (es. “Microsoft Security Validator”). L’utente clicca “Accept” sulla schermata di consenso ufficiale di Microsoft; l’app ottiene token di accesso permanenti senza mai vedere la 2FA.
- Session token theft — tecniche come
EvilginxeModlishkafanno da proxy fra utente e Microsoft, catturando il token di sessione dopo che l’utente ha completato la 2FA legittimamente.
In tutti e tre i casi la 2FA gira regolarmente, ma il risultato finale è un account compromesso.
Cosa controllare prima di rispondere a un’email “Microsoft”
- Microsoft non chiede mai di chiamare un numero di telefono in un avviso di sicurezza. Le notifiche legittime invitano a fare login su
https://account.microsoft.comohttps://admin.microsoft.com. - Verifica gli headers dell’email completi (in Outlook: File → Proprietà → Internet headers): un’email legittima ha il path SPF/DKIM da
microsoft.com,accountprotection.microsoft.comooffice365.com. Domini con trattini sospetti (microsoft-security[.]com) sono fake. - Controlla il link reale passando il mouse sopra senza cliccare (su mobile: long-press). Domini diversi da
microsoft.com/office.com/live.comsono indicatori di phishing. - Mai approvare una notifica push sull’app Authenticator se non hai appena tentato un login: chiunque la stia spingendo da remoto è un attaccante.
Cosa fare nelle PMI italiane
Per ridurre l’esposizione a questa famiglia di attacchi in azienda, agire su tre livelli.
Configurazione del tenant
- In Microsoft Entra ID, abilita Conditional Access con condizioni geografiche e device-compliant (vedi setup Conditional Access).
- Disattiva il user consent a app di terze parti non verificate: Entra ID → Enterprise applications → Consent and permissions → “Do not allow user consent” o “Allow user consent for verified publishers only”.
- Configura Defender for Office 365 anti-phishing policies con detection di impersonation (anche degli executive interni) — guida completa in Defender for Office 365: configurare anti-phishing.
- Abilita la passwordless authentication con Windows Hello, FIDO2 keys o Microsoft Authenticator number matching: chiude il vettore voice-phishing perché non c’è una push generica da approvare.
Formazione utenti
- Esercizio periodico di phishing simulato con Attack Simulator di Defender (vedi tutorial Attack Simulator).
- Procedura aziendale chiara: nessuno del supporto IT — interno o di SynSphere — chiama mai per chiedere conferma di un codice 2FA o di una push. Mai.
Incident response
- Avere già pronta una procedura di account-compromise: revocare i token attivi (Entra ID → Users → Sign-in logs → Revoke sessions), forzare il cambio password, audit dei consent grant recenti dell’utente.
- Defender XDR consolida automaticamente queste azioni in un playbook riusabile.
Quando ha senso un servizio gestito
Sotto i 50 utenti molte PMI non hanno né le competenze né il tempo per configurare Defender for Office 365, Entra Conditional Access, Authenticator number matching e Attack Simulator in modo coerente. È il caso d’uso tipico per un servizio di assistenza cybersecurity gestita: SynSphere applica le baseline Microsoft di sicurezza, monitora gli alert Defender 24/7 e gestisce gli incident al posto del cliente. Discovery gratuita: contattaci.