La compromissione delle credenziali di accesso rappresenta soltanto il punto di ingresso attraverso cui un attaccante può iniziare a operare, sfruttando ulteriori privilegi e autorizzazioni legittime per muoversi inosservato all’interno dell’infrastruttura IT aziendale e provocare danni. Non si tratta quindi soltanto di proteggere il punto di accesso, rafforzando i sistemi di autenticazione, ma di implementare una governance delle identità strutturata, intervenendo sulle lacune nei controlli relativi ai privilegi e alle autorizzazioni successive al primo accesso. Le carenze nella governance delle identità ampliano infatti la superficie di attacco, offrendo ai criminali informatici ulteriori opportunità di sfruttamento anche senza dover ricorrere a malware o a vulnerabilità tecniche dei sistemi IT.
Il problema della corretta governance delle identità, che va oltre il mero punto di accesso e l’immissione di una password, è salito alla ribalta in relazione a un attacco messo a segno dal gruppo Storm-2949 e reso noto lo scorso maggio da Microsoft: in questo caso, infatti, la campagna è evoluta dalla singola compromissione di un’identità a una violazione dell’intero ambiente cloud dell’organizzazione vittima. Con nella fattispecie una scansione durata soli quattro minuti e che ha portato al furto di dati da Microsoft 365, alla scansione di Azure Key Vault, all’esfiltrazione di dati SQL e alla compromissione di macchine virtuali. Il tutto senza malware di alcun tipo.
Ciò è stato possibile in prima istanza sfruttando una lacuna del processo di ripristino delle password (reset gap), per cui l’hacker ha avviato la procedura di SSPR (Self-Service Password Reset) su un utente scelto come bersaglio. Per fare questo, ha impiegato tecniche di social engineering, effettuando una chiamata fingendosi il supporto IT interno, per indurre l’utente ad approvare una richiesta MFA (autenticazione multifattore) di routine, che lo stesso attaccante aveva avviato in simultanea. Una volta reimpostata la password tramite un flusso SSPR legittimo, l’attaccante ha proceduto indisturbato a rimuovere e modificare i metodi di autenticazione associati all’account (telefono, e-mail e Authenticator), tagliando così fuori l’utente legittimo e disponendo di un proprio nuovo accesso MFA conforme e perfettamente legittimo. L’hacker ha quindi avviato la ricerca di ulteriori identità privilegiate, compromettendo altri tre account aziendali.
Nella seconda fase della campagna di attacco l’hacker ha quindi potuto approfittare delle lacune nella governance delle identità dell’azienda: sfruttando i privilegi RBAC (Role-Based Access Control) ereditati dall’utente compromesso, ha ottenuto l’accesso a Key Vault con ruolo di proprietario (Owner) permanente, sottraendo in quattro minuti una quantità di dati e risorse sensibili. Il team di Threat Intelligence di Microsoft evidenzia come i cybercriminali possano sfruttare funzionalità amministrative legittime che, nel tempo, non vengono sottoposte a verifiche adeguate rispetto all’evoluzione delle esigenze operative, dei carichi di lavoro e del contesto aziendale. Questo consente agli attaccanti di ottenere risultati analoghi a quelli del tradizionale movimento laterale, sfruttando privilegi e autorizzazioni già presenti nell’infrastruttura.
La campagna descritta da Microsoft evidenzia come non sia sufficiente rafforzare la protezione del solo punto di accesso. È possibile, ad esempio, sostituire l’SSPR (Self-Service Password Reset) con sistemi di verifica resistenti al phishing, integrando controlli biometrici in grado di accertare la presenza effettiva dell’utente durante ogni procedura di ripristino e richiedendo, ove necessario, la verifica di documenti d’identità ufficiali. Molte e diverse sono infatti le porte di accesso mediante credenziali compromesse che un attaccante può sfruttare in alternativa. Ciò che è invece fondamentale per fermare un attaccante è avere una governance attenta ed efficace di ciò che accade dopo che l’accesso è avvenuto, possibile innanzitutto adottando il principio del privilegio minimo, limitando quello che gli utenti possono fare. Il che significa concedere agli utenti solo le autorizzazioni indispensabili per svolgere i loro compiti, applicando questo principio non solo alle normali credenziali utente, ma anche a tutte quelle credenziali di servizio e di sistema spesso inserite e dimenticate in file di configurazione o in script-batch. Le necessità del business, l’ambiente IT e le interazioni tra gli utenti compongono infatti un ecosistema in evoluzione continua, e continua deve pertanto essere anche la revisione di ruoli e privilegi. Anche mediante procedure regolari e quotidiane, che richiedono sia la corretta configurazione delle funzionalità native offerte dalle piattaforme, sia l’implementazione di strumenti volti al controllo e alla gestione dinamica e in tempo reale di identità e privilegi.
In tal senso, è fondamentale implementare una governance delle identità che funzioni come una disciplina, che provveda alla verifica costante che i privilegi associati a un’identità siano ancora appropriati e necessari: chiedendosi ogni giorno cosa possa fare ogni identità presente nella directory, chi sia stato a confermare la legittimità di tali permessi e implementando adeguati meccanismi che avvisino in caso di comportamenti anomali in assenza di un corrispondente ticket di workflow.
Il caso Storm-2949 esemplifica in modo chiaro alcune delle lacune nel sistema di gestione delle identità sfruttate nella catena di attacco. Partendo dalla mancanza di un controllo capace di rilevare modifiche non autorizzate ai metodi di autenticazione: nella fattispecie, un nuovo autenticatore si è registrato su un dispositivo non in possesso dell’utente originale, rimuovendo e modificando tutti e tre i metodi di autenticazione, una sequenza che nessun flusso aziendale plausibile prevede. Altra mancanza riguarda il presupposto che le assegnazioni di ruolo rimangano valide in maniera indefinita: l’utente compromesso deteneva infatti un ruolo di Owner permanente sul Key Vault. Grave lacuna è allora la mancanza di una ricertificazione delle configurazioni RBAC, mentre sarebbe bene eliminare il presupposto di permanenza dei privilegi basati sui ruoli: una corretta governance dovrebbe implicare che l’utente non detenga il ruolo di Owner stabilmente, ma ne richieda i privilegi come utente umano presente che necessiti di svolgere un’attività specifica e per un determinato tempo, con una richiesta di elevazione just-in-time.
Infine, l’adozione di strumenti aggiuntivi, come la verifica out-of-band del service desk, basata su un token collegato al flusso di lavoro, avrebbe neutralizzato le tecniche di social engineering usate dall’attaccante per indurre l’utente ad approvare la richiesta MFA. Il metodo comporta che, quando un addetto al service desk deve assistere un utente in operazioni di ripristino, recupero o modifica dell’autenticatore, venga generato un codice di verifica visibile solo all’interno del sistema di gestione dei ticket. L’utente comunica il codice nel corso della chiamata stessa: senza questo passaggio la finta procedura di assistenza fallisce.
Un ulteriore strumento di rilevamento, che nel caso descritto avrebbe potuto generare un alert di sicurezza, consiste nella correlazione degli eventi registrati nei log dei diversi componenti del piano di controllo del cloud, così da garantire una maggiore visibilità sui movimenti laterali tra ambienti differenti. Questa lacuna è emersa chiaramente nell’attacco Storm-2949. Il piano di controllo del cloud comprende infatti molteplici superfici, ciascuna monitorata attraverso una propria pipeline di logging, che registra gli eventi all’interno del singolo sistema. La disponibilità di log separati, tuttavia, non garantisce di per sé una visione d’insieme: senza un’adeguata correlazione tra gli eventi, diventa più difficile ricostruire le attività che si sviluppano tra componenti e ambienti diversi e individuare tempestivamente eventuali movimenti laterali. Una buona governance delle identità dovrebbe implicare il monitoraggio del comportamento di un’identità su tutti i target con cui interagisce, mediante acquisizione e gestione unificata di tutti gli eventi di LOG. Nel caso in oggetto, un simile modello di governance avrebbe generato un avviso del tipo ‘Questa identità ha interagito negli ultimi 45 minuti con sette target, con cui non aveva mai avuto contatto nei 90 giorni precedenti’. Avviso che sarebbe scattato prima dell’avvio della scansione del Key Vault.
In conclusione, la corretta risposta di sicurezza in questo caso non consiste in un rilevamento più efficace da parte del SOC o del SIEM – la scansione e l’enumerazione sono infatti avvenute in soli quattro minuti, finestra temporale molto al di sotto della soglia minima di reazione. La risposta più efficace risiede invece in un approccio preventivo, basato sul principio dell’assenza di privilegi permanenti e sull’adozione del privilegio minimo come impostazione predefinita. Questo approccio richiede una revisione strutturale dell’architettura e delle procedure di governance delle identità aziendali. Si tratta di un cambiamento che porta a considerare la governance delle identità come un livello di controllo continuo e in tempo reale, anziché affidato esclusivamente a verifiche periodiche. Di conseguenza, anche questo ambito deve rispondere agli stessi requisiti di tempestività, copertura e integrazione nei flussi operativi previsti per il rilevamento delle minacce sugli endpoint e il monitoraggio della rete.