In prima linea contro gli attacchi informatici

I migliori consigli per mettere in sicurezza l’AD (Active Directory), alcune best practices che possono essere intraprese e le regole fondamentali per mitigare i rischi.

di Bruno Filippelli *
* Sales Director di Semperis Italia

 

Nei cyberattacchi l’AD (Active Directory) è spesso il primo punto di arrivo. Infatti si stima che nel 90% degli attacchi l’AD in qualche modo viene sempre coinvolto, sia che si tratti di vettore di attacco iniziale o che l’attacco è rivolto a ottenere privilegi o persistenza. L’AD è particolarmente ambito dai criminali informatici perché al suo interno sono contenuti una miriade di preziosi dati aziendali, anche dei dipendenti. Prendere di mira e penetrare nell’AD garantisce agli aggressori la ricchezza di informazioni necessaria per accedere ai dati sensibili, distribuire ransomware e tutta una serie di altre attività nefaste. In questo articolo analizziamo gli aspetti fondamentali che devono essere considerati per comprendere quanto sia estremamente importante non lasciare al caso alcun dettaglio.

Di seguito i migliori consigli per predisporre un piano strategico volto a mettere in sicurezza l’AD, alcune best practices che possono essere intraprese e le regole fondamentali per mitigare i rischi.

Mai trascurare le regole fondamentali

Molto spesso le organizzazioni non hanno ancora la piena consapevolezza di cosa significhi avere l’AD con zone esposte oppure avere il controllo costante di tutte le utenze. Sono diversi i casi in cui vengono intrapresi provvedimenti insufficienti o vengono sottovalutati numerosi aspetti. Più di una volta, infatti, si verificano gli attacchi e ciò che è sconcertante è con quanta facilità i malintenzionati sono riusciti a far breccia nei sistemi vitali di un’azienda. Solitamente l’attacco inizia in modo silenzioso con gli aggressori che per prima cosa utilizzano strumenti per il furto delle credenziali (ad esempio attraverso una e-mail). Una volta penetrati, utilizzano uno degli account amministratore di dominio dell’azienda per creare un altro account nascosto, mediante il quale gli aggressori riescono ad entrare nel gruppo di amministratori del dominio. Fin qui la “procedura” può essere definita da manuale. Com’è possibile che si possa verificare un processo così semplice ma fortemente devastante? Se gli aggressori sono riusciti a infiltrarsi, il o i perché sono da ricercarsi nel fatto che con assoluta certezza sono state trascurate alcune regole fondamentali di sicurezza. Ad esempio, uno dei casi più ricorrenti e che rappresenta un bersaglio perfetto per gli aggressori è un computer che è stato configurato con una delega senza restrizioni. Un altro motivo ricorrente è che vi è stata la configurazione di diverse autorizzazioni rischiose a livello di dominio. Ancora più semplicemente le password degli account di amministrazione (che sovente risultano sempre troppi) non vengono mai modificate con frequente regolarità. Quelle appena elencati sono soltanto alcune delle cause più frequenti che impongono la verifica e il rispetto delle norme per la sicurezza di Active Directory.

Implementare le best practices e non lasciare nulla al caso

Quanto descritto al paragrafo precedente impone di rivedere tutte le impostazioni che riguardano l’AD e che per mille motivi una volta effettuate anni addietro non si ha più avuto modo di modificare. Senz’altro questa operazione richiede un notevole investimento di tempo e risorse ma che è assolutamente necessario se si pensa alle conseguenze ben peggiori derivanti dalla presenza di estranei nell’AD. Tanto per cominciare occorre lo screening completo di tutti gli account, sia quelli attivi che quelli inattivi. Rimuovere gli utenti inattivi non sono più necessari, rappresenta un’operazione particolarmente importante. Mediamente circa il 10% degli account utente presenti in un AD viene rilevato come inattivo e ciò rappresenta un rischio significativo per la sicurezza, in quanto le minacce esterne potrebbero utilizzare questi account per infiltrarsi.

Tornando al discorso delle password, aggiornare regolarmente gli account di servizio con chiavi solide e casuali contribuisce a ridurre la minaccia di possibili violazioni degli ambienti AD. Inoltre l’implementazione della Local Administrator Password Solution (LAPS), rende più difficile il salto da una workstation all’altra attraverso la stessa password di amministratore, poiché verrà generata una password unica e randomizzata per ogni account di amministratore locale. Anche questo è particolarmente fondamentale perché in questo modo non solo gli utenti idonei potranno leggerle o richiederne la reimpostazione ma verrà impedito il cosiddetto movimento trasversale effettuato dagli aggressori una volta penetrati nell’AD. Tuttavia per le password non è tutto: va tenuto conto che ogni forest AD ha un account KRBTGT associato che serve a criptare e firmare tutti i ticket Kerberos emessi all’interno del dominio. Nel momento in cui un utente si autentica in un dominio, gli viene fornito un Ticket Granting Ticket (TGT) allo scopo di avere la possibilità di richiedere un service ticket dal Kerberos Key Distribution Center per poter accedere a un certo servizio come ad esempio un file server). Il TGT rappresenta la prova di identità per ottenere l’accesso ad altri servizi sulla rete ogni qualvolta che un utente si registra e fornisce dettagli sulla propria identità come anche in quali gruppi è presente. I TGT hanno validità limitata nel tempo, ma ciò comunque va considerato come un possibile rischio poiché nel caso dell’ottenimento fraudolento del controllo dell’account KRBTGT, è possibile creare TGT fake per accedere a qualsiasi risorsa. In questo caso si tratterebbe di un attacco Golden Ticket che può essere prevenuto con lo stesso metodo utilizzato per le altre password, ossia reimpostando quella dell’account KRBTGT in ogni dominio con regolare frequenza.

La gestione dei gruppi di appartenenza, i privilegi e i domain controller

Gli aggressori solitamente, una volta penetrati nell’AD, tentano di acquisire tutti i privilegi possibili attraverso gli account. Logicamente questi account fanno parte dei gruppi privilegiati che sono quelli a cui sono concesse le più ampie facoltà e permessi che consentono l’esecuzione di quasi tutte le azioni all’interno dell’AD. Come buona regola dovrebbe esistere soltanto un ristrettissimo gruppo di amministratori di dominio che risultino gli unici responsabili di ogni azione eseguita nell’AD e ciò è ovvio, poiché più account privilegiati ci sono, più aumenta l’esposizione con una superficie di attacco più ampia, con il rischio che soltanto uno di questi account possa essere utilizzato malevolmente. A fronte di questa regola occorre applicare il principio del minimo privilegio, impostando i diritti di accesso degli utenti soltanto a quelli strettamente necessari per eseguire le mansioni. Di conseguenza, una volta effettuata la scrematura e riduzione del numero di account privilegiati, occorre utilizzare account amministrativi che abbiano nomi separati affinché tutto ciò che è presente nel registro di controllo sia inoltrato ad un preciso utente anziché a più utenti che appartengono ad un account. L’adozione di uno schema amministrativo multilivello rappresenta un’altra accortezza per prevenire l’escalation dei privilegi, limitando il controllo e i punti di accesso. Inoltre, con il crescere delle applicazioni in cloud, è importante comprendere la tipologia di infrastruttura a valle che supporta l’ambiente AD. La maggior parte delle organizzazioni opera in cloud pertanto viene eseguito l’AD attraverso domain controller virtuali. In questo caso gli amministratori dell’hypervisor hanno potere di chiudere, cancellare, modificare i domain controller, e ciò significa massima attenzione verso chi detiene i diritti di amministrazione per gli stessi motivi che riguardano account privilegiati. Proseguendo il discorso riguardo ai domain controller, si deve considerare che le relative impostazioni predefinite non essendo protette comportano diverse vie di escalation dei privilegi da parte dell’amministratore di dominio. Le impostazioni predefinite inoltre consentono ai domain controller l’esecuzione di altre operazioni come ad esempio il Print Spooler. Con questo servizio anche un qualsiasi utente autenticato può connettersi in remoto ed effettuare varie richieste. Anche per i domain controller è preferibile disabilitare un servizio come lo Spooler eliminando così il rischio di lasciare esposte le credenziali dell’account; a qualunque livello nell’AD, occorre sempre ricordare che qualsiasi superficie, seppur ristretta, può rappresentare un punto di accesso per gli aggressori.

E se tutto ciò non bastasse…

Sebbene la gestione di tutte le impostazioni di un AD sia fondamentale per ridurre al minimo il rischio di un attacco, bisogna tenere conto che l’eventualità non sarà mai pari allo zero%. È fondamentale quindi prepararsi anche a rispondere e difendersi una volta che all’interno dell’AD si rilevano “presenze non gradite”. Innanzitutto, è necessario il continuo monitoraggio in modo tale da rilevare per tempo qualsiasi attività insolita e bloccarne l’avanzata. Si può ricorrere a una soluzione di gestione delle informazioni e degli eventi di sicurezza (SIEM) che analizza il comportamento degli utenti e delle entità, con la quale è possibile avere la situazione di ogni attività su tutta l’infrastruttura IT. Questo consentirà di individuare qualsiasi cambiamento, ad esempio, sull’appartenenza di un account, di un gruppo privilegiato o se vengono modificati i privilegi stessi su un account. In conclusione, occorre anche considerare il processo di recovery, poiché va effettuato un ripristino completo che comprenda anche il recupero dell’intero sistema di Active Directory e per fare ciò occorre fare backup con regolare frequenza. Infatti, quando è in corso un attacco, le operazioni di ricostruzione di un’Active Directory richiedono tempo prezioso, lasciando sia gli aggressori nelle condizioni di perfezionare l’attacco, sia l’azienda in stallo. Il ripristino dovrà quindi riportare la situazione esattamente a come era prima dell’attacco, ristabilendo tutte le impostazioni precedenti e avendo la certezza che il backup stesso non sia infetto. Per poter predisporre un backup sicuro è meglio in un ambiente sandbox completamente isolato.

calendar_month

a cura di Loris Cantarelli