Quattro sfide nel monitoraggio della sicurezza di Active Directory

Con gli aggressori che sviluppano costantemente nuove tattiche per compromettere le credenziali e i dati, è sempre più importante monitorare sistemi critici come Active Directory (AD) per segni di attività malevole.

Molte organizzazioni si rivolgono ai prodotti di security information and event management (SIEM) per ottenere aiuto. Tuttavia, sebbene queste soluzioni possano essere estremamente potenti, dipendono in ultima analisi dai log degli eventi di Windows — i quali sono complicati da gestire e non forniscono le informazioni necessarie per monitorare diversi vettori di attacco chiave di AD.

Questo blog esplora quattro delle principali sfide nella sicurezza di Active Directory e spiega le limitazioni dell'uso dei log degli eventi per affrontarle.

Sfida 1. Monitoraggio delle modifiche all'appartenenza di gruppo

I gruppi di sicurezza di Active Directory sono il modo principale in cui agli utenti viene concesso l'accesso alle risorse IT, inclusi dati, macchine e applicazioni. Man mano che gli attaccanti si muovono lateralmente nel tuo ambiente, spesso aggiungono gli account che hanno compromesso a nuovi gruppi di sicurezza per ottenere privilegi aggiuntivi, quindi è fondamentale monitorare le modifiche all'appartenenza ai gruppi di sicurezza.

Il tracciamento delle modifiche ai gruppi che forniscono accesso privilegiato è particolarmente importante. Ciò include gruppi predefiniti come Domain Admins, Enterprise Admins e Schema Admins, così come qualsiasi gruppo di sicurezza creato dalla tua organizzazione che fornisce diritti di accesso elevati.

Cosa registra il Log degli Eventi — e i suoi limiti

Active Directory registra le modifiche ai gruppi di sicurezza nel registro eventi. Ad esempio, se un utente viene aggiunto al gruppo Domain Admins, AD genererà un evento come quello mostrato di seguito, che include i seguenti dettagli chiave:

• L'ID dell'utente che ha effettuato la modifica
• Il DN e la classe dell'oggetto che è stato modificato
• Il tipo di modifica (in questo caso, che un membro è stato aggiunto)

Figura 1. Esempio di evento che mostra che un gruppo di sicurezza è stato modificato

Tuttavia, il registro eventi presenta diverse limitazioni importanti:

• · Nessuna registrazione dell'origine della modifica — I log degli eventi non registrano la fonte di una modifica all'appartenenza di un gruppo. Sebbene una modifica al gruppo Domain Admins da un jump server o domain controller (DC) possa essere normale, una modifica proveniente da una postazione di lavoro non amministrativa o da un'altra macchina esposta a Internet può essere un chiaro segnale di un attacco. Senza dettagli sull'origine della modifica, è impossibile allertare su modifiche provenienti da località anormali.
• · Nessun monitoraggio dell'appartenenza effettiva al gruppo — Active Directory registra solo le modifiche all'appartenenza diretta di un gruppo. Tuttavia, i gruppi possono contenere altri gruppi come membri. Pertanto, per monitorare veramente le modifiche all'appartenenza di un gruppo, è necessario monitorare il gruppo stesso e ogni gruppo annidato al suo interno.
• · Incoerenze tra gli eventi — Gli eventi registrati saranno diversi a seconda del modo in cui è stato modificato un gruppo. Ad esempio, se un utente viene aggiunto a un gruppo utilizzando le Active Directory Service Interfaces (ADSI), il registro eventi mostrerà un evento di rimozione per ogni membro esistente del gruppo, seguito da un evento che aggiunge nuovamente ogni membro del gruppo, seguito da un evento che aggiunge il nuovo utente; quindi, aggiungere un utente a un gruppo con 50 membri genererà 101 voci nel registro eventi. E se la modifica è stata effettuata utilizzando LDAP, potrebbe essere elencato il GUID dell'oggetto invece del suo nome distinto. Queste incoerenze possono causare confusione e disinformazione nei prodotti SIEM e rendere estremamente difficile costruire regole efficaci per agire sui dati raccolti.

Sfida 2. Monitoraggio delle modifiche alla Group Policy

Le impostazioni dei criteri di gruppo influenzano gli utenti e i computer in tutto il Active Directory domain, incluso, ad esempio, chi ha accesso amministrativo ai sistemi. Una singola modifica a un oggetto Group Policy object (GPO) può avere gravi impatti sulla sicurezza o causare interruzioni della produzione, quindi è fondamentale monitorare tali modifiche.

Cosa registra il Log degli Eventi — e i suoi limiti

Quando viene modificata una Direttiva di Gruppo, verrà registrato un evento come quello mostrato nella Figura 2. Questo evento fornisce informazioni utili, come chi ha effettuato la modifica e l'identificatore del GPO.

Figura 2. Evento registrato per una modifica alla Group Policy

Tuttavia, a questi eventi mancano le seguenti informazioni critiche:

• · Dettagli di quale impostazione è stata modificata e i suoi valori prima e dopo — I GPO supportano centinaia di impostazioni predefinite e personalizzate. Una modifica potrebbe modificare la homepage del browser predefinito per gli utenti o fornire a tutti gli utenti il controllo amministrativo di una macchina critica. Tuttavia, il registro eventi non cattura l'impostazione modificata e in cosa è stata cambiata.
• · Origine della modifica — Come per le modifiche ai gruppi di sicurezza, gli eventi che registrano le modifiche ai Criteri di Gruppo non indicano la provenienza della modifica. La maggior parte delle modifiche ai GPO dovrebbe provenire da poche località selezionate, ed essere in grado di identificare le modifiche che provengono da località anormali è fondamentale per rilevare gli attacchi rapidamente.

Sfida 3. Monitoraggio delle letture di Directory

Un altro compito fondamentale per garantire la sicurezza del vostro Active Directory è monitorare come gli account utente leggono ed enumerano gli oggetti AD. Gli aggressori che cercano di ottenere un punto d'appoggio nella vostra rete spesso enumerano account critici, gruppi e server al fine di scoprire percorsi di attacco che portano a privilegi elevati e, in ultima analisi, a dati sensibili. Monitorando gli eventi di lettura sospetti, potete rilevare questa attività di ricognizione e fermare un attacco prima che sia troppo tardi.

Cosa registra il Log degli Eventi — e i suoi limiti

Per aiutarvi a capire chi sta esplorando Active Directory, il registro eventi cattura l'attività di lettura. L'evento mostra dettagli riguardo l'account utente, l'oggetto che viene letto e il tipo di operazione che viene eseguita, come illustrato nella Figura 3:

Figura 3. Un evento che mostra che una proprietà di Domain Admins è stata letta

Tuttavia, cercare di utilizzare questi eventi per monitorare attività sospette presenta diversi svantaggi:

• Troppo rumore — Registrare gli eventi di lettura produce così tanto rumore nel registro eventi che è quasi impossibile trovare informazioni di valore. Infatti, una singola istanza di un utente che guarda un gruppo può generare decine o addirittura centinaia di eventi nel registro, il che rende quasi impossibile individuare attività sospette tra tutti gli eventi legittimi.
• Nessun registro dell'origine della lettura — Inoltre, non c'è modo di sapere da dove proviene l'evento di lettura. Come abbiamo visto con le modifiche sia ai gruppi di sicurezza che ai GPO, sapere da quale computer proviene un evento di lettura è un'informazione cruciale per determinare se si tratta di una lettura innocua o di un atto di ricognizione malevolo.
• Troppi eventi di accesso negato — È altrettanto fondamentale individuare gli utenti che tentano di accedere a informazioni per le quali non possiedono i diritti. Ad esempio, Active Directory può memorizzare password in chiaro per account amministrativi negli attributi dei computer, quindi un account utente che prova a leggere questi attributi potrebbe tentare di compromettere credenziali privilegiate. Sfortunatamente, ogni volta che un account visualizza un oggetto per qualsiasi motivo, l'azione genera eventi di fallimento di accesso per tutti gli attributi che non ha il diritto di leggere, anche se non aveva intenzione di leggere quegli attributi. Semplicemente non è una strategia praticabile cercare di trovare eventi di accesso fallito veramente sospetti tra l'oceano di eventi innocenti.
• Nessun modo semplice per monitorare le query LDAP — Le query LDAP sono comunemente utilizzate per esplorare Active Directory al fine di scoprire utenti, gruppi e computer. Sfortunatamente, Microsoft non offre un modo semplice per monitorare le query LDAP per vedere la query emessa e da dove proviene. A causa di questo problema, anche attivare il monitoraggio LDAP a livello diagnostico offre poco valore; infatti, non è consigliato da Microsoft, poiché genererebbe una quantità enorme di rumore nei log degli eventi.

Sfida 4. Tracciamento degli eventi di autenticazione

Con il recente aumento degli attacchi basati su credenziali, monitorare i modelli di autenticazione è fondamentale per identificare account compromessi, segni di pass-the-hash e pass-the-ticket attacks, forged Kerberos tickets, o altri exploit utilizzati per ottenere privilegi e accedere a dati sensibili.

Cosa registra il Log degli Eventi — e i suoi limiti

Active Directory registra eventi per monitorare l'attività di accesso e autenticazione degli utenti sui controller di dominio, sui server membri e sulle postazioni di lavoro, inclusi quelli elencati nella tabella seguente:

Anche se questi eventi catturano alcune informazioni utili, non offrono un modo efficace per individuare attacchi basati sull'autenticazione a causa delle seguenti carenze:

• Troppo rumore — Gli eventi vengono creati ogni volta che un utente effettua l'accesso a un computer, il che tipicamente rappresenta una quantità enorme di attività. Molti altri eventi vengono generati dietro le quinte. Ad esempio, quando un utente accede a un server membro collegato a un dominio AD, il server inizia una connessione con un DC che recupera le informazioni di Group Policy, il che comporta la comparsa di eventi di accesso/disconnessione nel registro eventi del DC. Non esiste un modo per disabilitare la registrazione dell'attività di login normale degli utenti senza ignorare l'attività di login critica ai vostri domain controllers.
• Nessun record del tipo di accesso sui DC — I log non tracciano il tipo di accesso per gli eventi di accesso sui DC, un contesto prezioso per determinare se gli account vengono utilizzati in modo appropriato. Ad esempio, non c'è un modo semplice per differenziare tra un utente che si collega tramite Desktop Remoto e un accesso di rete tramite un'unità di rete mappata; è necessario raccogliere i log da ogni server membro e tentare di correlarli con i log dei DC.
• Mancanza di dettagli specifici del protocollo — Gli eventi mancano anche di altri dettagli preziosi. Ad esempio, gli eventi di autenticazione Kerberos non registrano i timestamp della durata e del rinnovo del ticket, che sono indicatori preziosi di ticket falsificati utilizzati nell'exploit Golden Ticket. Allo stesso modo, i log NTLM non specificano la versione di NTLM utilizzata, informazione che è preziosa per determinare se è possibile disabilitare le versioni più vecchie di NTLM a favore di protocolli più sicuri.

Come Netwrix può aiutare

Come abbiamo visto, i log degli eventi non sono adeguati per rilevare tempestivamente gli attacchi e rispondere in modo efficace. Per una protezione completa, prendi in considerazione la soluzione di sicurezza Netwrix Active Directory. Ti aiuterà a:

• Identificate proattivamente le lacune di sicurezza attraverso una valutazione del rischio approfondita.
• Minimizza i costosi tempi di inattività e le interruzioni aziendali.
• Rilevate tempestivamente anche le minacce avanzate e rispondete rapidamente.