OAuth Client ID Spoofing, la nuova minaccia cloud scoperta da Proofpoint

Gli errori di autenticazione possono rivelare se un account esiste e se la password inserita è corretta. È il principio sfruttato da una tecnica osservata da Proofpoint in diverse campagne contro ambienti Microsoft 365.

La tecnica, definita OAuth client ID spoofing, consiste nell’inserire identificativi di applicazione falsi nelle richieste inviate a Microsoft Entra ID. L’obiettivo non è impersonare una specifica applicazione o ottenere direttamente un token OAuth, ma analizzare le risposte del servizio per verificare account e credenziali.

Come funziona il client ID spoofing

Ogni applicazione registrata in Microsoft Entra ID è associata a un client ID, cioè un identificativo univoco in formato GUID. Questo valore viene incluso nelle richieste OAuth e riportato nei log di accesso insieme al nome dell’applicazione.

Nelle campagne analizzate da Proofpoint, gli attaccanti hanno inviato le richieste all’endpoint OAuth 2.0 di Microsoft attraverso il flusso Resource Owner Password Credentials, che permette di trasmettere direttamente username e password. Al posto dell’identificativo di un’applicazione reale viene però utilizzato un client ID inventato o modificato.

Entra ID continua a elaborare la richiesta e restituisce codici di errore differenti in base ai dati inseriti. L’errore AADSTS50034 indica che il nome utente non esiste, mentre AADSTS50126 viene restituito quando l’account è valido ma la password è errata.

Il codice AADSTS50034, normalmente associato a un’applicazione non riconosciuta, può invece indicare che username e password sono corretti, ma che il client ID non corrisponde a un’applicazione registrata. L’attaccante può quindi scoprire di avere trovato credenziali valide, anche se l’autenticazione non viene completata.

Perché è difficile da rilevare

Gli attacchi tradizionali di password spraying e account enumeration prendono spesso di mira applicazioni Microsoft note e diffuse. Un numero elevato di richieste contro la stessa applicazione può essere individuato attraverso regole basate sul volume dei tentativi o sul nome del servizio.

Con il client ID spoofing, invece, le richieste vengono distribuite fra centinaia di migliaia o milioni di applicazioni inesistenti. Nei log può comparire soltanto l’application ID, senza il relativo nome. Quando l’identificativo utilizzato non è nemmeno un GUID valido, entrambi i campi possono risultare vuoti.

Anche i tentativi contro nomi utente inesistenti possono rimanere fuori dai log di accesso, perché Entra ID registra gli eventi associati ad account validi. L’attività risulta quindi frammentata fra numerosi identificativi, senza accessi riusciti e con pochi elementi facilmente correlabili.

La tecnica può inoltre ridurre l’efficacia delle policy di Conditional Access applicate soltanto a specifiche applicazioni. Un client ID inventato non corrisponde al servizio protetto e potrebbe non attivare i controlli previsti per quella particolare applicazione.

Milioni di identificativi OAuth falsi

Proofpoint ha analizzato due campagne su larga scala, apparentemente condotte da operatori o strumenti differenti.

La prima, denominata UNK_pyreq2323, è stata osservata fra gennaio e marzo 2026 e ha utilizzato oltre 700.000 client ID falsi. La campagna ha colpito più di un milione di account distribuiti fra quasi 4.000 tenant, utilizzando infrastrutture AWS e il client python-requests/2.32.3.

In questo caso gli attaccanti partivano dall’identificativo di Exchange Online e ne modificavano le ultime cifre. Ogni client ID veniva utilizzato contro un numero limitato di utenti, riducendo la possibilità di rilevare un volume anomalo associato a una singola applicazione. Secondo Proofpoint, circa il 28% degli account presi di mira è stato bloccato a causa dei numerosi tentativi.

La seconda campagna, monitorata come UNK_OutFlareAZ, è stata osservata a partire da dicembre 2025 e ha raggiunto una scala ancora maggiore: oltre due milioni di utenti e 3,7 milioni di client ID falsi.

Ogni tentativo utilizzava un UUID completamente casuale e differente. Gran parte del traffico proveniva dall’infrastruttura di Cloudflare, mentre lo user agent simulava una versione di Microsoft Outlook. Le differenze nella generazione degli identificativi e nell’infrastruttura utilizzata indicano che la tecnica potrebbe essere stata adottata indipendentemente da più gruppi.

Cosa cercare nei log di Microsoft Entra ID

Per individuare queste attività non basta controllare il numero di autenticazioni fallite associate alle applicazioni più utilizzate. I SOC dovrebbero analizzare gli eventi in cui il nome dell’applicazione è assente, i client ID che non corrispondono ad applicazioni registrate e le richieste nelle quali sia l’application ID sia l’application name risultano vuoti.

Particolare attenzione dovrebbe essere riservata all’errore AADSTS700016. Non indica necessariamente un semplice problema di configurazione: in presenza di un client ID falsificato può segnalare che l’attaccante ha già verificato la correttezza di username e password.

Il client ID spoofing non permette da solo di superare l’autenticazione multifattore o di accedere al tenant. Può però essere utilizzato per individuare gli account esistenti, verificare credenziali già compromesse e preparare attacchi successivi con meno tentativi e maggiori probabilità di successo.