Chi controlla gli account che nessuno usa?
Proofpoint ha descritto una campagna, battezzata UNK_CondorFiltration, rilevata a fine luglio 2026 e attiva dal 21 luglio al 16 agosto. Ha preso di mira 28 tenant Microsoft 365 in America Latina, con un forte accento sul Cile: un grande retailer e diverse istituzioni finanziarie. In totale gli attaccanti hanno tentato l'accesso a 5.714 account, con 32.825 tentativi di autenticazione partiti da 1.487 indirizzi IP, tutti su server AWS.
Come funziona il password spraying
Il password spraying ribalta la logica della forza bruta. Invece di provare mille password su un solo account, si prova la stessa password, o poche password comuni, su migliaia di account. Ogni utente vede al massimo un tentativo fallito, quindi il blocco automatico dopo troppi errori non scatta mai. Lo strumento usato si chiama TeamFiltration, pubblico dal 2022. Verifica quali indirizzi esistono davvero passando dalle API di Teams, cambia regione AWS a ogni ondata per aggirare i blocchi per IP e, a compromissione avvenuta, può scaricare posta, chat di Teams e file di OneDrive e SharePoint.
Sette account, nessuno con un proprietario
Il dato che conta è un altro: su 5.714 tentativi gli account violati sono stati sette, tutti nel retailer, e tutti erano account funzionali o di servizio. Erano stati creati per un compito preciso: gestire ticket, approvare pagamenti a fornitori, far funzionare una cassa. Poi erano rimasti lì. Nessuno aveva mai avuto sessioni di accesso da parte di utenti legittimi nella telemetria di Proofpoint. Sei su sette sono caduti nell'arco di sette minuti, un indizio di una password iniziale uguale per tutti, mai cambiata. Proofpoint la presenta come un'ipotesi, non come un fatto accertato. Gli account personali dei dipendenti, che le password le devono cambiare, sono rimasti al sicuro.
Cosa hanno fatto una volta dentro
Dopo l'accesso gli attaccanti sono comparsi su Teams, Office e OneDrive, sempre da AWS: uno schema compatibile con l'esfiltrazione automatica dello strumento, anche se i log di accesso da soli non bastano a confermarla. Su un account hanno provato ad andare oltre: dopo circa 90 secondi sono passati da un nodo VPN in Germania e hanno tentato l'accesso al portale VPN aziendale. Il tentativo è stato bloccato da MFA e accesso condizionale. Poi hanno provato ad aprire il portale Azure, che ha chiesto di registrare l'autenticazione a più fattori: l'account non ne aveva nessuna. Il dettaglio dice tutto.
💬 Il mio commento
Gli account di servizio sono il parente povero dell'identità aziendale. Un dipendente ha un nome, un capo, un'offboarding quando se ne va. L'account «cassa-negozio-3» o «approvazioni-fornitori» no: lo crea qualcuno per far funzionare una cosa, e da quel momento non è più di nessuno. Non lo dico per fare la morale, capita in tutte le aziende, comprese quelle ben organizzate, perché il lavoro vero è sempre altrove. Il caso di Proofpoint mi colpisce per questo: non c'è nessuna vulnerabilità sofisticata, c'è una password di partenza mai cambiata e l'assenza dell'MFA. Ed è comunque bastato a entrare.
La cosa più sensata è partire da un inventario noioso: quali account non corrispondono a una persona, chi ne risponde, quando è cambiata l'ultima password, se hanno l'MFA o almeno una regola di accesso condizionale che limita da dove possono accedere. Lo so che non è semplice: alcuni account di servizio non supportano l'MFA e vanno trattati con altri strumenti, per esempio identità gestite, restrizioni per rete o segreti ruotati in automatico. Su questo punto io stesso ho spesso dei dubbi su quale sia la soluzione meno dolorosa caso per caso. Ma partire dal sapere che esistono mi sembra già metà del lavoro. Voi, nel vostro tenant, sapreste dire oggi quanti sono gli account senza un responsabile con nome e cognome, e chi se ne accorgerebbe se uno di loro iniziasse a comportarsi in modo strano?