UNK-CondorFiltration: attacco a tenant Microsoft 365

Una nuova campagna di attacco sta mettendo a dura prova la sicurezza dei tenant Microsoft 365, e il suo nome è UNK_CondorFiltration. Collegata al framework TeamFiltration, questa operazione ha dimostrato quanto possano essere pericolose le identità macchina dimenticate e prive di autenticazione a più fattori (MFA). Non si tratta di un attacco contro utenti distratti o password deboli scelte da persone fisiche: il vero punto di ingresso sono stati gli account di servizio non monitorati, veri e propri punti ciechi nella sicurezza aziendale. Scopriamo insieme come funziona questa campagna, quali tecniche usa e, soprattutto, come proteggersi.

Cos’è la campagna UNK_CondorFiltration

UNK_CondorFiltration è una campagna di password-spraying su larga scala che ha colpito tenant Microsoft 365 in tutto il mondo. I numeri parlano chiaro: oltre 5.700 account scansionati in circa 28 tenant differenti, con sette account effettivamente compromessi. Tra le vittime più colpite figurano un grande retailer cileno e diverse istituzioni finanziarie del Cile.

La particolarità di questa campagna non sta nella quantità di bersagli, ma nella qualità del vettore di accesso utilizzato. Gli attaccanti non hanno puntato sugli utenti umani, bensì su account di servizio e identità macchina lasciate senza supervisione, spesso con password di default mai cambiate e completamente sprovviste di MFA.

L’infrastruttura dietro l’attacco

Per portare avanti questa operazione su scala globale, gli attaccanti hanno sfruttato un’infrastruttura cloud distribuita impressionante: più di 1.400 indirizzi IP, principalmente istanze AWS EC2. Questa rotazione costante di regioni e IP ha permesso di eludere i tradizionali blocchi basati su geolocalizzazione o blacklist IP, rendendo il rilevamento molto più complesso per i team di sicurezza.

Le tattiche e tecniche utilizzate (TTP)

Capire come agisce un attaccante è il primo passo per difendersi. Ecco le fasi principali osservate nella campagna:

Enumeration degli account tramite Teams API, per costruire liste di bersagli affidabili prima di lanciare l’attacco.
Password spraying: pochi tentativi su ogni singolo account, ma ripetuti su migliaia di account, per restare sotto la soglia di blocco automatico.
Rotazione di infrastruttura cloud e IP per evitare i sistemi di rilevamento basati su pattern di rete.
Attività post-compromissione: accessi a SharePoint, OneDrive, Teams e chiamate Microsoft Graph per ricognizione e potenziale esfiltrazione di dati.
Creazione o abuso di app e service principal per mantenere persistenza nell’ambiente compromesso.

Perché le identità macchina sono il vero tallone d’Achille

La domanda che molti si pongono è: perché proprio gli account di servizio? La risposta è semplice e al tempo stesso preoccupante. Queste identità, a differenza degli utenti umani, spesso sfuggono ai controlli di sicurezza standard:

Non sono soggette a policy di MFA obbligatoria come gli account utente.
Spesso mantengono password di default o segreti mai ruotati nel tempo.
Sono frequentemente “ownerless”: nessuno in azienda ne monitora attivamente lo stato o l’utilizzo.
Generano pattern di autenticazione (user-agent, orari di accesso) diversi da quelli umani, che possono passare inosservati se non si dispone di un monitoraggio dedicato.

In pratica, questi account diventano delle porte sul retro lasciate aperte, ignorate da chi gestisce la sicurezza IT ma ben note a chi cerca di sfruttarle.

Come rilevare un attacco di questo tipo

Per i team di sicurezza, identificare precocemente un attacco come UNK_CondorFiltration richiede l’attenzione a specifici indicatori comportamentali:

Picchi di tentativi di accesso falliti su un numero elevato di account in un breve lasso di tempo.
Accessi riusciti provenienti da un gran numero di IP distribuiti su infrastrutture cloud.
Attività insolita su SharePoint, OneDrive o Teams immediatamente dopo un login riuscito.
User-agent identici o sospetti ripetuti su più account, segno di automazione.
Chiamate anomale verso Microsoft Graph o le API di Teams, tipiche delle fasi di enumeration.

Chi utilizza strumenti come Azure Sentinel può impostare query Kusto (KQL) mirate per intercettare pattern di password-spraying, correlando tentativi falliti e successi su finestre temporali ristrette, oltre a monitorare l’audit log per attività sospette post-login come download massivi di file o creazione di nuove app registration.

Cosa fare subito: azioni prioritarie

Se sospetti di essere stato colpito da una campagna simile, agisci rapidamente seguendo questi passi:

Isola gli account compromessi: revoca sessioni, token e forza il reset delle credenziali.
Attiva l’MFA obbligatoria per tutte le identità con accesso a dati sensibili, inclusi gli account di servizio dove tecnicamente possibile.
Metti in quarantena gli account di servizio senza owner e forza la rotazione immediata dei segreti.
Potenzia il logging attivando o incrementando i log di Azure AD e l’Unified Audit Log, inoltrandoli verso un SIEM.
Blocca le autenticazioni legacy tramite Conditional Access, limitando l’accesso a client moderni e sicuri.

Strategie a medio e lungo termine

Rispondere all’emergenza non basta. Serve una strategia strutturata per evitare che situazioni simili si ripetano in futuro.

Governance delle identità non umane

Il primo passo è costruire un inventario completo di tutte le identità macchina presenti nel tenant: service principal, managed identity, account di servizio locali e app registration. Ogni identità dovrebbe avere un owner chiaramente identificato, oltre a una classificazione in base al livello di privilegio e sensibilità dei dati a cui accede.

Gestione centralizzata dei segreti

Spostare tutte le credenziali verso un vault centralizzato, come Azure Key Vault, permette di automatizzare la rotazione dei segreti e tenere traccia di ogni accesso. Eliminare le password di default e preferire, dove possibile, certificati o managed identity riduce drasticamente la superficie di attacco.

Monitoraggio comportamentale continuo

Implementare soluzioni di UEBA (User and Entity Behavior Analytics) consente di individuare automaticamente pattern anomali, come user-agent sospetti o tentativi di accesso massivi, prima che si trasformino in una violazione conclamata.

Conclusione

La campagna UNK_CondorFiltration è un campanello d’allarme per tutte le organizzazioni che utilizzano Microsoft 365. Il messaggio è chiaro: il rischio maggiore non arriva sempre dagli utenti umani, ma spesso da identità macchina trascurate, prive di MFA e senza un owner responsabile. Investire in un inventario completo delle identità non umane, centralizzare la gestione dei segreti e implementare un monitoraggio comportamentale continuo non sono più opzioni accessorie, ma requisiti fondamentali per la sicurezza aziendale. Solo un approccio proattivo e strutturato può davvero ridurre il rischio di cadere vittima di attacchi sofisticati come questo.