Monitoraggio Sicurezza AD: Event ID e SIEM

Cos'è il monitoraggio di Active Directory?

Il monitoraggio di Active Directory è la combinazione di criteri di audit, raccolta di eventi, correlazione e analisi di baseline necessaria per rilevare attacchi all'identità contro i controller di dominio e gli account privilegiati. Molti ambienti AD generano eventi di Windows Security, ma molti meno generano gli eventi giusti e li instradano verso rilevamenti che un analista possa effettivamente utilizzare.

Il monitoraggio in AD non è solo conservazione dei log. È la disciplina di scegliere le sottocategorie che contano, dimostrare che gli eventi sono presenti sui controller di dominio e costruire rilevamenti basati sul comportamento dell'attaccante piuttosto che sul volume grezzo.

Un programma di monitoraggio AD utile parte dai percorsi di attacco che i difensori devono davvero poter vedere: abuso di ticket Kerberos, DCSync, modifiche ai gruppi privilegiati, scritture su oggetti della directory, autenticazione NTLM, emissione di certificati e movimento laterale verso server sensibili.

Come funziona il monitoraggio di Active Directory

L'audit di sicurezza di Windows è controllato dai Criteri di Controllo Avanzati e produce dati utili solo se vengono abilitate le sottocategorie corrette.

Una pipeline di monitoraggio pratica è strutturata così:

1. i Criteri di Controllo Avanzati abilitano gli eventi necessari
2. il Registro eventi di Windows memorizza localmente gli eventi Security
3. WEF o un agente inoltra gli eventi a una piattaforma centrale
4. la correlazione SIEM trasforma questi eventi in rilevamenti e indagini

Il fallimento più comune resta il primo passaggio: il collector e il SIEM esistono, ma le sottocategorie AD chiave non sono mai state abilitate sui controller di dominio che contano.

La documentazione di Microsoft Defender for Identity rafforza questo punto elencando gli eventi Windows richiesti per i sensori e l'infrastruttura correlata. L'elenco include eventi di identità fondamentali come 4662, 4728, 4732, 4756 e 4776. Se i controller di dominio non generano e non inoltrano questi eventi, la logica di rilevamento a valle non può recuperare le prove mancanti.

La catena di attacco senza monitoraggio

DCSync - Nessun audit di accesso al servizio di directory

Senza Audit Directory Service Access, l'evento 4662 non offre ai difensori la visibilità attesa sull'abuso dei diritti di replica. L'evento 4662 viene generato quando viene eseguita un'operazione su un oggetto Active Directory, ma la configurazione dell'audit degli oggetti e della SACL restano determinanti per una copertura utile.

Kerberoasting - Nessuna visibilità sui ticket Kerberos

Senza la raccolta e la revisione di 4769, le richieste insolite di ticket di servizio si confondono nel traffico normale e le richieste con cifratura RC4 sono facili da perdere. Microsoft documenta l'evento 4769 come un evento di richiesta TGS generato sui controller di dominio. Gli aggiornamenti Windows più recenti espongono campi Kerberos aggiuntivi, che possono migliorare le indagini quando disponibili.

Abuso di gruppo privilegiato - Nessun avviso sui cambi di appartenenza

Senza copertura per 4728, 4732 e 4756, un attaccante può aggiungere un account backdoor a un gruppo privilegiato e contare sul fatto che gli amministratori se ne accorgano solo a posteriori. Questi eventi corrispondono ai cambiamenti di appartenenza dei gruppi di sicurezza globali, locali e universali.

Abuso di delega o GPO - Nessuna visibilità sui cambiamenti

Senza 5136 e il relativo audit delle modifiche, le modifiche alla directory ad alto impatto possono avvenire con pochissimo contesto investigativo. L'evento 5136 viene generato quando un oggetto del servizio di directory viene modificato, e diventa più utile se abbinato all'attributo modificato e al contesto dell'oggetto.

Rilevamento

Configurazione essenziale dei criteri di audit

Distribuire tramite GPO: Configurazione Computer > Impostazioni di Windows > Impostazioni di Sicurezza > Configurazione Criteri di Controllo Avanzati

Riferimento agli Event ID critici

Query di rilevamento SIEM (Elastic KQL)

Rilevamento DCSync:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$")

Rilevamento Kerberoasting:

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

Cambio di gruppo privilegiato:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: ("Domain Admins" OR "Enterprise Admins" OR "Schema Admins")

Consiglio: iniziate con un piccolo insieme di rilevamenti ad alta confidenza che il team esaminerà davvero. DCSync, i cambi di gruppo privilegiato e l'abuso di ticket di servizio di solito offrono molto più valore di un ampio set di regole non mantenuto.

Mapping dei campi e validazione del parser

Prima di scrivere una logica di rilevamento complessa, convalidate il mapping dei campi per il vostro SIEM. Lo stesso evento Windows può arrivare con nomi di campo diversi a seconda del connettore, dell'agente o del livello di normalizzazione. Per ogni rilevamento critico, verificate che:

• l'Event ID venga analizzato in modo coerente
• i campi account separino gli account utente, dominio e macchina
• i campi della workstation di origine e dell'indirizzo client vengano conservati
• i campi di cifratura del ticket siano presenti per i rilevamenti Kerberos
• i campi di oggetto e attributo della directory vengano conservati per 4662 e 5136
• i campi di richiesta e template del certificato vengano conservati per gli eventi AD CS

Una regola che funziona in laboratorio ma perde il campo critico in produzione non è copertura.

Remediation

Azione rapida: abilitate Directory Service Access, Directory Service Changes e le sottocategorie Kerberos su tutti i controller di dominio prima di ottimizzare qualsiasi altra cosa.

1. Distribuire i criteri di controllo avanzati tramite GPO

auditpol /get /category:*

auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

2. Aumentare la capacità del log Security

La dimensione predefinita del log Security è spesso troppo piccola per controller di dominio molto attivi.

wevtutil sl Security /ms:1073741824 /rt:false /ab:true

La capacità del log deve essere dimensionata in base al volume reale di eventi. I domini con molto traffico Kerberos e i DC molto attivi possono sovrascrivere rapidamente le prove se i log Security restano ai valori predefiniti, troppo piccoli.

3. Inoltrare centralmente gli eventi dei controller di dominio

winrm quickconfig
wecutil cs subscription.xml
gpupdate /force

L'inoltro deve preservare l'XML dell'evento o i campi normalizzati richiesti per il rilevamento. Se il vostro collector scarta Properties, ObjectDN, TicketEncryptionType o i campi della workstation di origine, le regole ad alto valore degenerano in avvisi generici.

4. Stabilire baseline prima di regolare le soglie

Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
    Group-Object {$_.TimeCreated.Hour} |
    Select-Object Name, Count |
    Sort-Object Name

Usate queste baseline per comprendere il volume normale di traffico Kerberos e di accesso prima di introdurre soglie di anomalia.

5. Collegare i rilevamenti ai percorsi di attacco

Non monitorate gli Event ID in modo isolato. Collegate ogni rilevamento al percorso di attacco che supporta:

• il DCSync richiede gli eventi sui diritti di replica e le modifiche privilegiate alla directory
• il Kerberoasting richiede visibilità sui ticket di servizio, contesto di cifratura e inventario degli account di servizio
• l'abuso di delega richiede visibilità sulle modifiche degli attributi e autenticazione insolita degli account macchina
• il relay NTLM richiede convalida NTLM, accessi target e azioni successive specifiche del servizio
• l'abuso AD CS richiede il contesto di richiesta, emissione e template del certificato

Questo mapping evita che il programma di monitoraggio diventi un elenco di eventi scollegati.

Come EtcSec rileva questo

EtcSec verifica la copertura dei criteri di audit necessaria ai difensori per indagare sui principali percorsi di attacco AD emersi altrove nel report.

I risultati relativi al monitoraggio evidenziano sottocategorie di audit mancanti, retention insufficiente e altre lacune che lascerebbero un abuso di identità ad alto valore invisibile o difficile da ricostruire.

Rilevamenti da implementare per primi

Se il team di monitoraggio può inizialmente distribuire solo poche regole ad alto valore, iniziate dagli attacchi che sono sia comuni sia verificabili operativamente:

• abuso dei diritti di replica e tentativi di DCSync
• cambi di appartenenza ai gruppi privilegiati
• richieste sospette di ticket di servizio associate al Kerberoasting
• modifiche di oggetti della directory ad alto impatto, come scritture su GPO o delega
• attività di emissione di certificati per ambienti con ADCS abilitato
• pattern di convalida NTLM e accesso di rete per indagini su relay o movimento laterale

Questi rilevamenti creano una base utile senza sommergere gli analisti con avvisi di scarsa qualità.

Revisione di retention e copertura

Il monitoraggio di Active Directory deve includere anche una revisione della retention. Un controller di dominio può produrre grandi volumi di eventi Kerberos, di accesso e di gestione account, e un log Security locale piccolo può sovrascrivere esattamente le prove necessarie durante la risposta a un incidente. Rivedete insieme la dimensione massima del log Security, la latenza di inoltro, i fallimenti di ingestione del SIEM e la retention in hot storage. Se il SIEM conserva 90 giorni di dati ricercabili ma il collector scarta silenziosamente Event ID ad alto volume durante i periodi di picco, la retention apparente non corrisponde alla reale copertura investigativa.

Per le prove Tier-0, definite quali eventi devono restare ricercabili per tutta la finestra di risposta. I cambi di gruppi privilegiati, le modifiche di oggetti della directory, l'emissione di certificati, l'accesso agli oggetti rilevante per il DCSync e gli eventi Kerberos ad alto valore non devono essere trattati come telemetria di debug scartabile. Sono la prova che permette ai difensori di ricostruire cosa è cambiato, chi lo ha cambiato e se lo stesso percorso è stato riutilizzato dopo la remediation.

Validazione dopo le modifiche ai criteri di audit

Dopo aver modificato i criteri di audit, confermate che la catena di monitoraggio funzioni end-to-end:

• verificate che gli eventi attesi compaiano sui controller di dominio in ambito
• confermate che quegli stessi eventi raggiungano il vostro collector o SIEM senza ritardi eccessivi o perdite silenziose
• testate almeno un'azione amministrativa controllata e un'azione Kerberos benigna per validare il parsing e il mapping dei campi
• rivedete la retention per assicurarvi che le prove critiche siano ancora presenti quando gli investigatori ne hanno bisogno
• confermate che 4662 e 5136 includano il contesto di oggetto e attributo necessario per le indagini sulla directory
• confermate che 4769 includa le informazioni di cifratura e servizio necessarie per le indagini Kerberos
• confermate che gli eventi AD CS siano presenti se nell'ambiente esistono servizi di certificazione

Controlli correlati

Questo articolo si accompagna naturalmente a Sicurezza delle Password in Active Directory: Errori Critici, NTLM Relay: Rilevamento e Prevenzione, Configurazioni Errate GPO come Vettore di Attacco, Account Obsoleti e Sovraprivilegiati: Il Rischio Nascosto in Active Directory, e Attacchi Delega Kerberos: Non Vincolata a RBCD. Un buon monitoraggio è ciò che permette ai team di dimostrare che questi problemi sono stati risolti e di rilevare se si ripresentano.

Riferimenti principali

• Panoramica sulla raccolta eventi di Defender for Identity
• Configurare l'audit degli eventi Windows per Defender for Identity
• 4662: è stata eseguita un'operazione su un oggetto
• 4769: è stato richiesto un ticket di servizio Kerberos
• 5136: un oggetto del servizio di directory è stato modificato
• Controllo della gestione dei gruppi di sicurezza