Account Microsoft 365 violati senza password: ecco il nuovo incubo OAuth Ammassi.IT

Tempo di lettura: 5 minuti

Gli account Microsoft 365 possono oggi essere violati anche senza rubare la password, sfruttando app malevole che ottengono accesso via OAuth (spesso tramite il flusso “device code”) e restano dentro anche dopo cambio password e MFA.

Come funziona l’attacco OAuth “senza password”

I criminali inviano email o messaggi che simulano notifiche Microsoft (account bloccato, verifica urgente, nuova app aziendale da autorizzare) con link, QR code o codici dispositivo.
L’utente viene portato su una vera pagina Microsoft (es. device login), inserisce il codice o accede normalmente e concede permessi a una falsa app OAuth controllata dall’attaccante, spesso con scope molto ampi (lettura posta, file, impostazioni, graf API, ecc.).

Perché è così pericoloso

Una volta autorizzata, l’app malevola ottiene token OAuth che danno accesso persistente a mailbox, OneDrive/SharePoint, Teams e dati vari senza bisogno di conoscere la password o passare per MFA nelle sessioni successive.
L’accesso risulta “legittimo” ai log (è la tua identità che autorizza un’app Microsoft), quindi l’attività dell’attaccante (lettura email, regole di inoltro, frodi interne, esfiltrazione dati) è difficile da distinguere dal normale lavoro dell’utente.

Cosa stanno vedendo i ricercatori

Proofpoint e altri vendor hanno segnalato campagne dal 2025 che usano kit come Tycoon/ODx per phishing MFA e impersonazione di app Microsoft, con migliaia di account e centinaia di tenant coinvolti.
L’abuso del device code flow è diventato un pattern ricorrente: basta far inserire alla vittima un codice su un sito Microsoft legittimo per farsi concedere controllo completo dell’account (scenari descritti anche da Red Hot Cyber e altri CSIRT).

Difese tecniche lato admin Microsoft 365

Abilitare le protezioni contro il consent phishing in Microsoft Entra ID:
- Disabilitare o limitare il “user consent” alle app, consentendo solo app verificate o approvate tramite admin consent workflow.
- Usare Microsoft Defender for Cloud Apps per analizzare e classificare app OAuth rischiose, revocare permessi e automatizzare la correzione con policy (ban/revoke).
Hardening dell’ambiente:
- Condizional access per limitare l’uso del device code flow e dei grant OAuth da posizioni/device non gestiti.
- Monitorare log Entra ID / Cloud Apps per nuove app OAuth, permessi ad alto privilegio e anomalie (impossibile travel, attività massiva su mailbox).

Cosa fare come utente / azienda

Non autorizzare mai “al volo” app che chiedono accesso a posta, file o impostazioni se non sono chiaramente riconosciute e approvate dall’IT.
Se sospetti un abuso OAuth su un account:
- Revoca immediatamente le app collegate da “App e servizi con accesso all’account” / portale Entra, poi forza logout e reset token sessione, oltre al cambio password.
- Lato SOC/IT, esaminare tutte le app OAuth recentemente autorizzate, bloccare quelle sospette e verificare regole di inoltro mail, accessi da IP insoliti ed eventuale esfiltrazione.

Se vuoi, si può impostare insieme una checklist specifica per il tuo tenant Microsoft 365 (policy Entra, CA, Defender for Cloud Apps) da usare come base per un articolo o per hardening operativo.

L’attacco OAuth con device code è essenzialmente un abuso del normale “device authorization grant”: l’utente vede una richiesta legittima su microsoft.com/devicelogin, inserisce un codice fornito dal phisher e finisce per concedere token OAuth a un’app controllata dall’attaccante, che poi usa quei token per prendere il controllo dell’account Microsoft 365 bypassando MFA.

1. Flusso legittimo del device code (base tecnica)

Il dispositivo “limitato” (TV, stampante, script headless) chiede un device code e una verification URL al device authorization endpoint, ricevendo: user code, device code, verification URI (es. microsoft.com/devicelogin) e intervallo di polling.
L’utente, da un altro device con browser, visita la verification URI, inserisce il user code, fa login, accetta i permessi richiesti dall’app; nel frattempo il dispositivo originale polla il token endpoint con il device code fino a ricevere access/refresh token.

2. Preparazione dell’attaccante

Registra un’app in Entra ID/Azure AD (client ID reale, spesso con nome e logo che ricordano Microsoft o l’azienda) e abilita il device code flow con scope appetibili (Mail.Read, Files.Read.All, offline_access, ecc.).
Integra l’app in un kit di phishing (SquarePhish, Graphish, Tycoon, ecc.) che automatizza la generazione di device code, la creazione di email/landing e la gestione del polling e dei token.

Invia email o messaggi di spear phishing che:
- fingono avvisi di sicurezza (“verifica MFA”, “sblocco account”, “nuova app aziendale”), inviti a eventi, documenti condivisi, ecc.;
- includono il codice dispositivo da inserire, un link a microsoft.com/devicelogin o un QR code che lo incorpora.
Per aumentare fiducia, il messaggio spinge l’utente a “verificare sul sito Microsoft ufficiale”, sapendo che la pagina devicelogin è autentica.

4. Interazione della vittima con microsoft.com/devicelogin

La vittima apre microsoft.com/devicelogin (o URL equivalenti) e inserisce il device/user code ricevuto nel phishing.
Il server Entra ID riconosce il codice associato all’app dell’attaccante, chiede all’utente di autenticarsi (username, password, MFA) e poi mostra una schermata di consent con i permessi richiesti dall’app (che spesso sembrano generici o “IT tool”).

5. Concessione del consenso e rilascio dei token

Se l’utente conferma il consenso, il grant viene marcato come APPROVED e il device (in realtà l’infrastruttura del phisher) che stava pollando il token endpoint con il device code riceve:
- access token (e spesso refresh token) validi per le API Microsoft Graph con gli scope concessi;
- a questo punto l’attaccante ha accesso API-driven all’account, senza bisogno di password né MFA ulteriori.
Dal punto di vista dei log, tutto appare come “utente che ha autorizzato un’app registrata in Entra”, quindi il flusso è perfettamente conforme agli standard OAuth.

6. Post‑compromissione: cosa fa l’attaccante

Usa i token per:
- leggere e-mail, impostare regole di inoltro/auto‑delete, accedere a OneDrive/SharePoint, Teams, contatti, calendario, ecc.;
- esfiltrare dati, fare BEC, muoversi lateralmente, generare nuovi token usando il refresh token finché il consenso resta valido.
Il cambio password o l’MFA aggiuntiva non revocano automaticamente il consenso all’app: l’accesso resta attivo finché l’app OAuth non viene esplicitamente revocata o disabilitata via Entra/Defender for Cloud Apps.

7. Punti chiave da monitorare/difendere

Segnali tecnici tipici del device code phishing: molte richieste di device code, nuove app registrate o poco usate che ricevono improvvisamente grant con scope privilegiati, poll persistente da IP non aziendali verso token endpoint.
Contromisure: limitare o bloccare il consent degli utenti a nuove app, restringere il device code flow, usare CA e Defender for Cloud Apps per individuare e revocare app sospette, più training specifico sugli “strani codici da inserire su microsoft.com/devicelogin”.

Se ti interessa, si può trasformare questa sequenza in uno schema/diagramma tecnico pronto per slide interne o per un articolo con focus blue team (log da guardare, KQL, policy Entra da impostare).

Per revocare app OAuth sospette registrate in Microsoft Entra ID (ex Azure AD), segui questa procedura step-by-step dal portale admin, che permette audit, classificazione e revoca sia manuale che automatica. Richiede ruolo Global Admin o Application Admin.

1. Accesso al portale e primo audit OAuth

Accedi a portal.azure.com > Microsoft Entra ID > Applicazioni aziendali (Enterprise applications) > Tutte le applicazioni.
Filtra per OAuth 2.0 o usa la vista App con permessi utente per vedere grant attivi (scope, utenti autorizzati, data consenso). Ordina per “Data creazione” o “Sign-ins sospetti” per identificare recenti/sospette.
Esporta report CSV per analisi offline (colonne: App name, Publisher, Permissions, Users count).

2. Analisi con Defender for Cloud Apps (consigliato)

Vai su security.microsoft.com > Microsoft Defender for Cloud Apps > OAuth Apps.
Visualizza Risky OAuth apps (policy automatiche rilevano app con scope alti, molti utenti, publisher sconosciuti, basso utilizzo). Clicca su app sospetta per dettagli: permessi (es. Mail.Read.All), utenti colpiti, attività API.
Per threat hunting: filtra per “Newly registered”, “High risk permissions”, “Unverified publisher”.

3. Revoca manuale di app sospette

Opzione A – Da Enterprise Applications (Entra ID):

Seleziona l’app > Proprietà > Elimina (top-right) > Conferma “Sì”. Questo rimuove il Service Principal e revoca tutti i token/refresh per quell’app nel tenant.
Per app specifiche per utente: Utenti e gruppi > Rimuovi assegnazioni > Permessi > Revoca consensi amministratore/utente.

Opzione B – Da Defender for Cloud Apps:

In OAuth Apps, seleziona app risky > Suspend o Ban (revoca permessi per tutti gli utenti). O Revoke specific user per granularità.
Automatico: Crea policy (es. “Ban app con Mail.Read.All + >10 users”) per revoca auto su alert.

4. Revoca refresh token e force logout (emergenza)

Per utente specifico sospetto: Microsoft Entra ID > Utenti > Seleziona utente > Autenticazione > Richiedi nuova autenticazione (invalida tutti i token attivi). O PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId <user-id>.
Globale: Applicazioni > Consensi > Revoca tutti i consensi admin/utente pendenti.

5. PowerShell per bulk operations (avanzato)

powershell# Connetti
Connect-MgGraph -Scopes "Application.ReadWrite.All", "Policy.ReadWrite.Authorization"

# Elenca app sospette
Get-MgServicePrincipal -Filter "signInActivity/LastSignInDateTime eq null or createdDateTime gt 2025-12-01"

# Revoca specifica (usa ObjectId dall'elenco)
Remove-MgServicePrincipal -ServicePrincipalId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Revoca refresh token utente
Revoke-MgUserAllRefreshToken -UserId "user@tenant.com"

6. Verifica post-revoca e hardening

Controlla Sign-in logs (Entra ID) per attività residue dall’app/IP sospetti.
Abilita policy: Entra ID > Protezioni app > Richiesta consenso admin per tutte le app, blocca device code flow non trusted, CA per IP/device noti.
Monitora alert Defender: “Mass user OAuth consent”, “New risky OAuth app”.

Questa procedura pulisce il tenant in <30min per audit base; per tenant grandi, usa script + Defender. Se hai tenant ID o esempi di app sospette, posso raffinare con query KQL/Log Analytics.

＼ Get the latest news ／