Uno spray, non una scoperta tecnica
La società di sicurezza Huntress ha reso pubblica una campagna di password spraying che è andata avanti dal 12 al 26 giugno 2026, con il picco il 22 giugno. In quelle due settimane più di 81 milioni di tentativi di accesso sono stati diretti contro account Microsoft 365. Il traffico usciva da un intervallo IPv6 registrato a un unico operatore, e gli attaccanti non tiravano a indovinare le password. Rigiocavano coppie di nome utente e password raccolte da violazioni precedenti e del tutto slegate tra loro, scommettendo sul fatto che le persone riutilizzano le stesse credenziali da un servizio all'altro. Da quel diluvio sono usciti 78 account compromessi in 64 organizzazioni.
Quello che colpisce è l'assenza di qualsiasi cosa esotica. Non c'era uno zero-day, non c'era malware raffinato, non c'era alcun trucco sulla catena di fornitura. C'erano volume, credenziali riutilizzate e un percorso di autenticazione debole. Quella combinazione è alla portata di qualunque attaccante ordinario, ed è proprio per questo che merita l'attenzione di un titolare. La tecnica costa poco, si ripete all'infinito e punta allo strato di identità che la maggior parte delle aziende dà per protetto dall'autenticazione a più fattori.
Come gli accessi hanno superato l'MFA
Il meccanismo era un vecchio percorso di accesso. Gli attaccanti si sono autenticati attraverso gli strumenti da riga di comando di Azure usando il flusso Resource Owner Password Credentials, noto come ROPC, un metodo OAuth datato che accetta direttamente nome utente e password e che, in molti tenant, non fa scattare alcuna richiesta a più fattori. Dove un tenant aveva l'MFA attivo ma con un ambito ristretto, le credenziali riutilizzate sono entrate dritte dal varco. Huntress ha trovato sempre le stesse configurazioni sbagliate: MFA applicato solo ad applicazioni selezionate, MFA imposto solo ai gruppi di amministratori, MFA richiesto solo dalle posizioni non attendibili e policy di Conditional Access lasciate in modalità solo report, dove registrano ma non bloccano mai.
La lezione meno ovvia è che l'MFA non è un interruttore, ma una mappa di copertura. Un tenant può superare un audit che si limita a chiedere se l'MFA esiste e lasciare comunque una vecchia porta aperta. Gli attaccanti non hanno battuto l'autenticazione a più fattori. Hanno trovato gli accessi in cui non veniva mai chiesta. Tutta la storia sta in questa differenza, e resta invisibile finché nessuno controlla quali percorsi di autenticazione un tenant continua a consentire.
La mezz'ora che chiude il buco
Un problema di configurazione ha una risposta di configurazione, e quasi tutto si risolve in una breve sessione amministrativa, senza comprare nulla. Bloccate l'autenticazione legacy e disattivate il flusso ROPC, così che gli accessi con nome utente e password che saltano l'MFA vengano semplicemente respinti. Imponete l'autenticazione a più fattori su ogni applicazione e su ogni accesso, non solo sugli account amministratore o sulle posizioni non attendibili, e portate Conditional Access dalla modalità solo report al blocco attivo. Poi controllate i log degli accessi cercando il pattern dello spray fallito e reimpostate ogni credenziale che una violazione passata possa avere esposto.
Per un'azienda europea c'è una seconda ragione per muoversi in fretta. Se delle credenziali riutilizzate aprono una casella di posta che contiene dati personali, l'incidente può far scattare un obbligo di notifica ai sensi del GDPR entro 72 ore, e un buco di identità silenzioso diventa così un evento da notificare e un colloquio con l'autorità di controllo. Chiudere la porta costa un pomeriggio di configurazione. Lasciarla aperta si paga in obblighi di comunicazione e in fiducia perduta. Trattate lo strato di identità per quello che è diventato, cioè il perimetro.
Da leggere ora: Un audit di IA non ha visto il bug Linux che dà root | Un difetto Squid di 29 anni espone i login in chiaro
