In un precedente articolo – Microsoft Sentinel + Azure Arc: attivare la raccolta degli audit log – abbiamo visto come attivare la cattura log tramite Azure Arc. Oggi andremo un po’ più nel dettaglio, vedendo come poter analizzare correttamente i log di accesso provenienti dai Domain Controller.
Prima di poter cominciare, è necessario aver già effettuato le seguenti operazioni:
- Installare Azure Arc sui Domain Controller
- Creare una Data Rule Collections legata ai server in questione e capace di recuperare i Security Log (Success e Failure)
- Attivare i log sui Domain Controller – How to enable Audit Active Directory objects – Windows Server | Microsoft Learn
Analisi
Passate un po’ di ore dall’attivazione della DCR, sarà possibile eseguire le query tipo la seguente:
SecurityEvent | where EventID == 4624 and TargetUserName contains “silvio.dibenedetto” and Computer contains “it00swadds” | where TimeGenerated >= ago(4h)
Ricordate di modificare la variabile TargetUserName con l’utente che volete cercare e quella Computer con la naming convention che racchiude i vostri Domain Controller, così da filtrare solo gli accessi necessari.
Come faccio a vedere solo le colonne che mi interessano? Dopo aver eseguito la vostra query, potrete usare il comando Project per scegliere le colonne che intendete visualizzare. Ad esempio potete usare questa query: SecurityEvent | where EventID == 4624 and Computer contains “it00swadds” | where TimeGenerated >= ago(5h) | project TimeGenerated, TargetUserName, EventID, IpAddress, LogonTypeName
Advanced Security Information Model
Questo è il primo modo per analizzare i dati. Ne esiste un secondo che utilizza gli Advanced Security Information Model, ovvero dei normalizzatori dei log salvati e che consentono di fare query in altro modo, avendo una visualizzazione a volte più chiara, oltre che poter fare incroci tra sorgenti. Questi template sono disponibili al seguente link – Azure-Sentinel/ASIM at master · Azure/Azure-Sentinel · GitHub.
I template, oltre ad una nuova sintassi di query, integrano degli Azure Workbook già pronti, che aiutano ad effettuare le analisi desiderate. In questo caso, lo schema si chiama Authentication, mentre il workbook prende il nome di Identity & Access.
Un altro vantaggio di questi “normalizzatori” è dato dalla possibilità di interrogare più fonti in modo facile. Un esempio è dato da questa query: imAuthentication(targetusername_has=’silvio.dibenedetto’, starttime = ago(5h), endtime=now()) – dove vengono uniti i log di Security con quelli di Defender for Endpoint.
Mi piace una query ma la voglio modificare con alcune informazioni, come faccio? Editando il workbook è possibile modificare le varie aree visualizzate per poter copiare il codice.
La query è fatta in Kusto Query Language, dove si può notare l’integrazione tra le varie classi ma soprattutto la modifica estetica, e va ad unire i log provenienti dalla parte Security e quelli di Defender for Endpoint. Se volete approfondire l’uso delle KQL, potete leggere questo articolo – Azure Monitor workbook grid visualizations – Azure Monitor | Microsoft Learn.
Integrazione con Microsoft Defender for Endpoint
Non tutti sanno che l’integrazione tra Microsoft Defender for Endpoint e Microsoft Sentinel porta in dote anche i log di accesso, e non solo, come mostrato nell’immagine precedente. Questo offre ancora più funzionalità in fase di analisi. Per attivare l’integrazione è necessario configurare il Data Connectors di Defender XDR, scegliendo i connettori preposti a controllare il DeviceLogonEvents.
NB: questa operazione può aumentare il numero dei log acquisiti e quindi il costo del Log Analytics Workspace.
Eseguite questa query per verificare il funzionamento: imAuthentication(targetusername_has=’silvio.dibenedetto’, starttime = ago(6h), endtime=now()) | where EventProduct contains “M365” and EventOriginalType_string == “RemoteInteractive”
In questo caso si sta usando il normalizzatore per eseguire una query, recuperando gli eventi generati dal prodotto “M365 Defender for EndPoint”; nel dettaglio, l’interrogazione va a recuperare un logon remoto, dato che l’utente in questione sta provando ad accedere ad una VM tramite Azure Virtual Desktop – quindi in RDP.
Integrazione con Microsoft Defender for Identity
Non finisce certo qui! L’integrazione si può ampliare anche a Microsoft Defender for Identity per avere non solo i log di accesso, ma anche le attività svolte all’interno di Active Directory, come la creazione di un utente o di un gruppo, per fare dei veloci esempi. Anche in questo caso, l’attivazione passa da Microsoft Sentinel, così come per MDE, a cui si aggiunge l’attivazione di User and Entity Behavior Analytics.
Perchè UEBA? Poiché Microsoft Sentinel raccoglie log e avvisi da tutte le origini dati connesse, usando un’ampia gamma di tecniche e funzionalità di Machine Learning li analizza e crea profili comportamentali di base delle entità dell’organizzazione (ad esempio utenti, host, indirizzi IP e applicazioni) nel tempo e nell’orizzonte del gruppo peer. Se siete interessati ad approfondire l’argomento, ecco link all’articolo – Identificare le minacce avanzate con Analisi del comportamento dell’utente e dell’entità (UEBA) in Microsoft Sentinel | Microsoft Learn.
Una query utile per l’analisi può essere quella di capire il cambio di appartenenza ai gruppi, utile per monitorare il movimento laterale: IdentityDirectoryEvents | where ActionType == “Group Membership changed” | extend ToGroup = tostring(AdditionalFields.[“TO.GROUP”]) | extend FromGroup = tostring(AdditionalFields.[“FROM.GROUP”]) | project TimeGenerated, Actor=AccountName, UserAdded=TargetAccountUpn, ToGroup, FromGroup
Conclusioni
Azure Arc, integrato con Microsoft Defender XDR, è sicuramente la soluzione ideale per il monitoraggio delle attività degli utenti all’interno di Active Directory. L’utilizzo avanzato di KQL aiuta gli IT Admin a tenere sotto controllo tutte le operazioni eseguite dagli utenti ma anche da coloro che hanno privilegi particolari dentro AD.