Milioni di tentativi di accesso, centinaia di migliaia di applicazioni fittizie coinvolte: sono questi i numeri che descrivono lo spoofing del client ID OAuth che ricercatori di Proofpoint hanno osservato su scala crescente contro ambienti Microsoft Entra ID. Ricordiamo che i log di accesso di Entra ID rappresentano una delle fonti di telemetria principali per individuare attività di autenticazione malevola, inclusi enumerazione di utenti, password spraying e tentativi di accesso iniziale. Per eludere questi controlli, gli attaccanti ricorrono da tempo a tecniche evasive come la rotazione degli user agent e l'uso di servizi proxy che cambiano indirizzo IP a ogni richiesta.

La novità è che i ricercatori di Proofpoint hanno individuato più campagne in cui gli attaccanti falsificano il client ID OAuth, un codice che identifica ogni applicazione autorizzata a collegarsi a un account Microsoft. Ciascun tentativo di accesso viene registrato nei log insieme a questo codice; il problema è che se tale codice viene falsificato (ossia se indica un'applicazione che non esiste), il sistema continua ugualmente a rispondere. Gli attaccanti possono sfruttare questa debolezza per scoprire se una password è corretta e se un certo account esiste, senza che il tentativo compaia tra gli accessi riusciti nei log. In questo modo l’attacco risulta invisibile a chi controlla la sicurezza.

Partecipa agli ItalianSecurityAwards 2026 ed esprimi il tuo voto premiando le soluzioni di cybersecurity che reputi più innovative

Per verificare il funzionamento di questo meccanismo, i ricercatori hanno inviato automaticamente coppie di username e password direttamente al sistema di autenticazione di Microsoft, come farebbe un attaccante reale, e hanno osservato come il sistema rispondeva a ogni tentativo, con o senza un'applicazione falsa.

Il risultato è che quando veniva usato un codice che corrispondeva a un'applicazione reale, il sistema registrava tutto normalmente. Nei casi in cui il codice era inventato, sebbene scritto nel formato corretto, nei log rimaneva solo il codice stesso e il nome dell'applicazione restava vuoto. Un vuoto è proprio un punto di partenza che agli attaccanti serve, perché Entra ID annota solo i tentativi contro account reali; se lo username non esiste, il sistema restituisce un errore ma non lo registra registrato nei log. Se lo username è corretto ma la password è sbagliata, c'è un altro errore che non appare nei log. Il dato più rilevante si verifica quando sia lo username che la password sono corretti: il sistema dà un errore relativo all'applicazione non riconosciuta (perché è inesistente), confermando all'attaccante di aver trovato una combinazione valida.

L’attaccante sfrutta il fatto che non resta alcuna traccia nei log, attuando un attacco brute force che può andare avanti all’infinito, senza destare sospetti, fino a quando non ha trovato una combinazione valida di username e password. Infatti, le regole di sicurezza che cercano picchi sospetti di richieste verso una singola app diventano inefficaci, dato che quel campo viene semplicemente lasciato vuoto. In più, anche qualora l'attività sospetta venisse notata, i team di sicurezza rischierebbero di non capire che, tra tutti quei tentativi falliti, ci sono in realtà credenziali valide già in possesso degli attaccanti.

A questo punto si inserisce un’altra intuizione geniale degli attaccanti. I metodi di attacco più vecchi si concentrano su applicazioni reali molto diffuse, che generano subito l'allerta (pensiamo per esempio ad Outlook). Distribuendo invece i tentativi su centinaia di migliaia di applicazioni inventate, l'attività diventa molto più difficile da individuare e correlare. Anzi, dai test effettuati risulta possibile aggirare anche i sistemi che limitano il numero di tentativi consentiti.

Le applicazioni reali

La prima campagna analizzata è stata battezzata UNK_pyreq2323 e ha raggiunto un picco tra la fine di gennaio e i primi di febbraio, per poi diminuire progressivamente entro marzo 2026. L'attaccante ha distribuito tentativi su oltre 700.000 applicazioni inventate, generando tutte le richieste da un semplice script. L’attacco è partito da un’infrastruttura Amazon Web Services, ha colpito oltre un milione di account distribuiti su quasi 4.000 aziende. Il volume dei tentativi ha causato il blocco automatico degli account nel 28% degli utenti colpiti. In questo caso l'attaccante ha preso il codice di Microsoft Exchange Online e ne ha modificato solo l'ultima parte in modo casuale. Ogni codice falso veniva riutilizzato al massimo per una dozzina di account diversi, mai due volte sullo stesso.

A partire da dicembre 2025 è stata osservata una seconda campagna, più ampia, ribattezzata UNK_OutFlareAZ e proveniente principalmente da infrastruttura Cloudflare. La tecnica di base usata è stata la stessa della precedente, ma con volumi molto più elevati: oltre 2 milioni di utenti colpiti e 3,7 milioni di applicazioni false coinvolte. Le richieste in questo caso imitavano Microsoft Outlook. Molti degli username presi di mira seguivano schemi generici, come iniziale del nome più cognome. Questo suggerisce che gli attaccanti abbiano utilizzato la stessa lista di nomi comuni contro aziende diverse. In questo caso, però, il metodo era più sofisticato: ogni tentativo usava un codice applicazione completamente nuovo e casuale, mai riutilizzato.

Pur utilizzando la stessa tecnica di base, le due campagne presentano differenze evidenti in termini di travestimento, infrastruttura e modo di generare i codici falsi, a indicare che sono state orchestrate da operatori differenti. UNK_OutFlareAZ ha enumerato gli utenti in ordine alfabetico e ha usato un codice diverso per ogni tentativo invece di riciclarli, per rendere ancora più difficile il collegamento tra i vari tentativi.

Questa doppia applicazione della stessa tecnica conferma, secondo i ricercatori, che lo spoofing del client ID OAuth sta diventando una pratica sempre più comune tra coloro che attaccano gli ambienti cloud.

Secondo gli esperti, i team di sicurezza dovrebbero considerare le voci nei log senza il nome dell'applicazione come un potenziale segnale di questa tecnica, tenendo presente che l'errore relativo a un'applicazione non riconosciuta può nascondere credenziali già compromesse, oltre a un tentativo fallito.