Salta al contenuto
News

Phishing dall'account ufficiale Microsoft: la truffa che bypassa la 2FA

Email di phishing che arrivano dal dominio ufficiale Microsoft, superano i filtri antispam e usano voice fraud per bypassare la 2FA. Come riconoscerle e cosa configurare in azienda per proteggersi.

SynSphere Italia 7 min di lettura

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 Evilginx e Modlishka fanno 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”

  1. 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.com o https://admin.microsoft.com.
  2. 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.com o office365.com. Domini con trattini sospetti (microsoft-security[.]com) sono fake.
  3. Controlla il link reale passando il mouse sopra senza cliccare (su mobile: long-press). Domini diversi da microsoft.com / office.com / live.com sono indicatori di phishing.
  4. 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.

Prodotti SynSphere correlati

I prodotti del catalogo SynSphere richiamati in questo articolo.