Un attacco informatico di grandi dimensioni sta mirando a milioni di utenti di Microsoft 365, con oltre 81 milioni di tentativi di login falliti in un periodo di soli 14 giorni. Sebbene molte organizzazioni abbiano implementato l’autenticazione multi-fattore (MFA) per proteggere i loro account, i criminali informatici hanno trovato un modo per bypassare questa protezione sfruttando flussi di accesso obsoleti. La soluzione immediata per gli utenti e le aziende è verificare che l’MFA sia configurato per ‘tutte le applicazioni cloud’ e non solo per alcuni gruppi specifici, bloccando inoltre l’uso del vecchio protocollo OAuth chiamato ROPC. Questo attacco non è mirato a un settore particolare, ma sfrutta semplicemente password vecchie e non aggiornate che sono state rubate in precedenti incidenti di sicurezza.
La campagna, monitorata dall’azienda di sicurezza Huntress, ha visto un picco di attività tra il 12 e il 26 giugno 2026. Durante questo periodo, l’attore malevolo ha tentato di accedere a oltre 64 organizzazioni diverse, compromettendo con successo almeno 78 account Microsoft. All’inizio, il numero di account compromessi era basso, con circa 2-4 compromissioni al giorno, ma il 22 giugno l’attacco ha escalato drasticamente, portando a 30 compromissioni in un solo giorno. Questo aumento improvviso indica che i criminali hanno trovato un modo più efficace per sfruttare le vulnerabilità o hanno identificato una nuova serie di credenziali vulnerabili.
L’attacco è parte di un trend più ampio e preoccupante: il volume di tentativi di spray delle credenziali è aumentato di oltre 155 volte negli ultimi sei mesi. Attualmente, ogni tenant registra in media circa 1.964 tentativi di attacco falliti al mese. La selezione dei target non dipende dal tipo di azienda o dall’industria, ma è interamente basata sulla prevalenza di password che sono già presenti in liste di combinazioni rubate. Questo significa che l’attacco è opportunistico: i criminali provano semplicemente password vecchie su account che non hanno mai cambiato le credenziali dopo un precedente furto.
La maggior parte del traffico di attacco proviene da un indirizzo IPv6 specifico (2a0a:d683::/32), associato a un provider di infrastrutture internet chiamato LSHIY LLC. Questo provider opera da diversi indirizzi, inclusi Hong Kong, Wuhan e New York, una configurazione che rende difficile determinare la vera proprietà operativa. Huntress ha già inviato report di abuso a questo provider, ma non ha ricevuto alcuna risposta. L’attore malevolo utilizza coppie di username e password vecchie, esposte in precedenti violazioni, e le valida utilizzando il flusso ROPC (Resource Owner Password Credentials), che è stato deprecato nella versione OAuth 2.1 ma che molti sistemi ancora supportano.
Il flusso ROPC è pericoloso perché permette di scambiare username e password direttamente con il server di token senza richiedere un passaggio di autorizzazione interattivo. Poiché le policy di accesso condizionale (CAP) richiedono spesso l’MFA solo al momento dell’autorizzazione interattiva, l’uso di ROPC può bypassare queste policy se non sono configurate correttamente. In molti casi, gli tenant compromessi avevano MFA e CAP attivi, ma con configurazioni critiche errate. Ad esempio, l’MFA era applicato solo ad alcune applicazioni specifiche, non a ‘tutte le applicazioni cloud’, o solo a gruppi privilegiati come gli amministratori, lasciando gli utenti standard senza protezione. Inoltre, alcune policy erano impostate in modalità ‘solo report’, quindi registravano gli eventi ma non bloccavano l’accesso.
Un altro problema è la geolocalizzazione errata: alcuni indirizzi IP degli attaccanti sono stati erroneamente identificati come provenienti dagli Stati Uniti, permettendo loro di bypassare le policy basate sulla posizione geografica, anche se altre fonti indicavano che provenivano dalla Cina. Questo errore di geolocalizzazione ha facilitato l’accesso agli attaccanti.
Per mitigare questo rischio, le organizzazioni devono trattare il CLI di Azure e il flusso ROPC come superfici ad alto rischio. È fondamentale richiedere l’MFA per tutti gli utenti, tutte le applicazioni cloud e tutti i tipi di client, e bloccare l’accesso se non necessario. Inoltre, è consigliabile disabilitare i protocolli di autenticazione legacy e i flussi di grant obsoleti, e testare continuamente le policy di accesso condizionale utilizzando strumenti di simulazione come il ‘What If’ di Microsoft per identificare policy che sono solo in report o che hanno eccezioni pericolose.
Technical Deep Dive
Per gli utenti tecnici e gli esperti di sicurezza, è fondamentale comprendere i dettagli operativi di questo attacco e le specifiche configurazioni necessarie per prevenire future compromissioni. L’attacco sfrutta il flusso ROPC (Resource Owner Password Credentials) di OAuth 2.0, che è stato deprecato in OAuth 2.1. In questo flusso, il client applicativo riceve direttamente username e password dall’utente e le trasmette al server di autorizzazione per ottenere un token di accesso. La vulnerabilità critica nasce dal fatto che il token endpoint non richiede un passaggio di autorizzazione interattivo, bypassando quindi le policy di accesso condizionale (CAP) che tipicamente richiedono l’MFA solo al momento dell’autorizzazione.
Le policy CAP che non sono configurate correttamente per includere il CLI di Azure come applicazione ‘enforced’ sono il principale punto di fallimento. Le configurazioni errate comuni includono:
- MFA limitato a specifiche applicazioni cloud: il CLI di Azure non è coperto.
- MFA limitato a gruppi specifici (es. solo amministratori): gli utenti standard non sono protetti.
- MFA limitato a posizioni non fidate: gli indirizzi IP con geolocalizzazione errata (es. identificati come USA invece di Cina) sono trattati come fidati.
- Policy CAP in modalità ‘report-only’: gli eventi sono registrati ma non bloccati.
- ROPC legacy ancora attivo: l’MFA non viene invocato sul token endpoint.
L’indirizzo IPv6 2a0a:d683::/32 è associato all’AS32167 (LSHIY LLC), che gestisce anche l’AS955. La telemetria di terze parti associa questi prefissi IPv6 a origini cinesi. La registrazione aziendale di LSHIY mostra indirizzi in Hong Kong, Wuhan e un ufficio condiviso a New York (42 Broadway), una configurazione che oscura la vera proprietà operativa.
Le mitigazioni tecniche raccomandate includono:
- Bloccare l’accesso ROPC tramite policy CAP che richiedono MFA per ‘Tutti gli utenti’, ‘Tutte le applicazioni cloud’ e ‘Tutti i tipi di client’.
- Limitare l’uso del CLI di Azure solo agli utenti non amministratori che necessitano effettivamente di tale accesso, o bloccarlo esplicitamente tramite regole CAP dedicate.
- Disabilitare i protocolli di autenticazione legacy e i grant legacy.
- Rafforzare le posizioni nominali (named locations) e testare continuamente le policy CAP utilizzando il simulatore ‘What If’ di Microsoft per identificare policy in report-only o con eccezioni.
- Implementare l’autenticazione forte a livello di client (es. utenteStrongAuthClientAuthNRequired) per prevenire concessioni di token basate su ROPC.
In sintesi, la chiave per la sicurezza non è solo l’implementazione dell’MFA, ma la sua corretta configurazione per includere tutti i flussi di accesso, inclusi quelli legacy come ROPC, e per tutte le applicazioni, inclusi il CLI di Azure.
Fonte: https://cybersecuritynews.com/microsofts-azure-password-spray-attack/
