audit AD dei privilegi sensibili: errori e successi

Che cos'è l'audit AD dei privilegi sensibili?

L'audit AD dei privilegi sensibili è una verifica della visibilità a livello di host: Windows registra le richieste di privilegi sensibili su ogni controller di dominio, server membro o workstation compresa nel perimetro? Un'esportazione delle GPO del dominio può suggerire una risposta, ma le prove necessarie per chiudere la revisione sono i criteri di controllo riportati dall'host di destinazione e gli eventi che raggiungono la piattaforma di monitoraggio.

Questa guida è stata verificata il 4 ottobre 2026 sulla base di Microsoft Learn e del commit del codice sorgente di etc-collector 20268a321609c193b79c5da6764f3f56950449cb. Il punto di partenza è un limite specifico: il controllo EtcSec AUDIT_PRIVILEGE_USE_DISABLED accetta il solo Failure. Un risultato senza rilievi conteggiati non dimostra quindi che siano abilitati sia Success sia Failure.

Microsoft raccomanda entrambi gli esiti per questa sottocategoria su controller di dominio, server membri e workstation. Success registra i tentativi riusciti; Failure registra quelli non riusciti. Consultare la raccomandazione Microsoft per Sensitive Privilege Use. Esaminare la configurazione di riferimento approvata e documentare le eccezioni, senza considerare la soglia del prodotto come il requisito completo dei criteri.

Come funziona la verifica

Iniziare dai computer che si intende coprire. Elencare i controller di dominio, i server membri pertinenti e le workstation privilegiate, insieme al responsabile dei criteri per ciascun insieme di sistemi. Una query riuscita su un DC non dimostra lo stato di un altro DC o di un server membro. Registrare l'identità dell'host e l'ora di osservazione accanto a ogni risultato.

La distinzione tra configurazione e stato dell'host è illustrata nella nostra guida alla verifica della configurazione di controllo delle GPO rispetto alle impostazioni effettive degli host. Quell'articolo si concentra su Account Logon, Account Management e Policy Change. Qui la decisione riguarda il bit Success di Sensitive Privilege Use e la telemetria che ne deriva.

La verifica comprende tre passaggi di validazione. Primo, identificare la configurazione di riferimento attesa e le eventuali eccezioni approvate. Secondo, interrogare i criteri di controllo del sistema sull'host reale. Terzo, associare gli eventi locali pertinenti alle rispettive copie centrali e verificare i campi necessari a un analista. Chiudere ogni passaggio con le proprie prove: l'approvazione di un'eccezione non sostituisce una verifica di raccolta non riuscita, e un registro eventi popolato non sostituisce la query sui criteri.

Quando le prove non concordano, conservare la discrepanza. Ad esempio, una GPO raccolta può contenere solo Failure mentre un host riporta entrambi gli esiti. Il passo successivo utile è identificare come viene gestito quell'host e se lo stato è duraturo. Modificare una GPO solo per rendere coerente un'esportazione può rimuovere un'impostazione locale legittima o lasciare irrisolto il problema di configurazione effettivo.

Rilevamento: leggere i criteri su ogni host

Eseguire la seguente query in sola lettura su ogni destinazione, utilizzando un account autorizzato a leggerne i criteri di controllo. Questi comandi applicano la sintassi per nome o GUID documentata nella guida Microsoft di auditpol get; sono stati verificati sulla base di quella guida, senza essere eseguiti in un ambiente AD per questo articolo.

auditpol /get /subcategory:"Sensitive Privilege Use"

Sugli host con una lingua di visualizzazione diversa, usare il GUID di Sensitive Privilege Use documentato da Microsoft, utilizzato anche dal collector:

auditpol /get /subcategory:"{0cce9228-69ae-11d9-bed3-505054503030}" /r

Senza /user, auditpol interroga i criteri del sistema. Conservare l'output, l'host, il timestamp, il comando e gli eventuali errori. Un errore di autorizzazione è un risultato sconosciuto che richiede un accesso autorizzato; non indica che i criteri siano disabilitati. Esaminare separatamente i criteri per utente quando sono pertinenti per un account specifico o un esito di evento inatteso.

Tenere separato il risultato dei criteri dal campione di eventi. Gli eventi precedenti possono rimanere dopo una modifica dei criteri, quindi un evento osservato prima della query non prova l'impostazione attuale. Viceversa, una finestra di osservazione senza attività può non contenere alcuna operazione pertinente. Registrare la finestra e l'attività prevista prima di decidere se l'assenza di eventi indica un problema di generazione o di raccolta.

Rilevamento: validare 4673/4674 lungo la catena di raccolta

Microsoft documenta 4673 come una chiamata a un servizio privilegiato e 4674 come un tentativo di operazione su un oggetto privilegiato. Entrambi possono appartenere anche a Non Sensitive Privilege Use. Esaminare il privilegio e il contesto dell'operazione; il solo numero di evento non identifica la sottocategoria sensibile.

Usare questa query locale del registro Security per esaminare l'XML. Applica le opzioni di query, ordine inverso e formato dell'output della guida Microsoft di wevtutil:

wevtutil qe Security /q:"*[System[(EventID=4673 or EventID=4674)]]" /rd:true /f:xml

Scegliere una finestra di osservazione delimitata e adatta alla revisione quando si eseguono ricerche nel sistema centrale. Associare i record locali alle rispettive copie ricevute usando l'identità dell'host, l'ora, l'ID evento e l'ID record, se conservato. Verificare la normalizzazione dell'esito del controllo e dei nomi dei privilegi effettuata dal connettore rispetto all'XML originale, soprattutto quando la vista centrale unisce campi o elimina valori vuoti.

La guida complementare alla raccolta centrale degli eventi e alla validazione dei parser supporta questo lavoro sul trasporto e sulla mappatura dei campi. Conservare un esempio di ogni tipo di evento pertinente effettivamente osservato. Se un esempio richiesto non è disponibile, documentare il caso non testato invece di dichiarare una copertura completa.

Questa distinzione è esplicita nella documentazione Microsoft di 4672. Usare 4672 per il contesto di accesso, mantenendo separate le verifiche di generazione e inoltro di 4673/4674. Valutare account, privilegi e processi inattesi rispetto all'attività amministrativa approvata prima di segnalare un evento come possibile abuso.

Correzione: verificare Failure e Success dopo il rilascio (Remediation)

1. Correggere la sottocategoria gestita

Quando la configurazione di riferimento approvata richiede entrambi gli esiti, configurare Audit Sensitive Privilege Use in Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use. Selezionare Success e Failure nella GPO o nel sistema di configurazione che gestisce effettivamente l'insieme di host di destinazione.

Documentare il responsabile della modifica, gli host di destinazione, l'elenco delle eccezioni, la configurazione precedente e la decisione di rollback. Sperimentare la modifica su computer rappresentativi prima di estenderla al resto del perimetro. Il rilascio deve seguire l'insieme di host e i confini di gestione identificati, senza supporre che tutti i computer pertinenti siano controllati dagli stessi criteri predefiniti.

2. Verificare la precedenza sui criteri legacy e rileggere lo stato degli host

Esaminare Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Microsoft raccomanda di lasciare abilitata questa impostazione e documenta SCENoApplyLegacyAuditPolicy come meccanismo che impedisce l'applicazione dei criteri a livello di categoria. Consultare la guida Microsoft ai criteri di precedenza sull'audit legacy nel riconciliare le impostazioni di controllo di base e avanzate.

Dopo che la modifica gestita ha raggiunto ogni host, ripetere la query auditpol basata sul GUID riportata sopra. Confrontare gli output prima e dopo. Se un host presenta ancora differenze, esaminare la fonte di gestione applicabile e l'elaborazione dei criteri; non dichiarare completata la correzione sulla sola base dell'editor delle GPO.

3. Mantenere Backup/Restore come decisione separata

Il controllo dell'uso dei privilegi Backup e Restore dipende inoltre da Audit: Audit the use of Backup and Restore privilege. Microsoft sconsiglia di abilitare questa impostazione separata perché può produrre un volume considerevole di eventi. Non abilitarla ovunque come scorciatoia per chiudere questa revisione. Registrare la visibilità richiesta, il carico di lavoro, la capacità operativa e la decisione del responsabile per ogni eccezione a tale raccomandazione.

4. Confermare la ricezione prima di chiudere la revisione

Dopo il rilascio, ricontrollare la generazione locale e il parsing centrale tramite un'attività approvata e controllata, pertinente al privilegio previsto. Concordare l'evento atteso con il responsabile del monitoraggio prima del test. Un'azione amministrativa generica non garantisce che compaiano entrambi gli ID evento o entrambi gli esiti.

Se gli eventi locali esistono ma mancano le copie centrali, esaminare la sottoscrizione di inoltro, i filtri dell'agente, gli errori di acquisizione e la configurazione del parser. Se mancano gli eventi locali, verificare prima l'operazione, l'impostazione di controllo e la finestra di osservazione. Sono problemi diversi con responsabili diversi. Fissare una data di follow-up per i casi irrisolti e ricontrollare dopo la ricostruzione degli host o le modifiche ai criteri che li gestiscono.

Come EtcSec rileva questo problema

Nel commit del codice sorgente esaminato qui, AUDIT_PRIVILEGE_USE_DISABLED legge advancedAuditLevel. Questa funzione ausiliaria usa una mappa selezionata delle GPO di controllo avanzato oppure ricorre ai dati EventAudit legacy. Con un valore noto inferiore a 2, il rilevatore emette un rilievo di gravità Medium con Count 1. Il valore 2 indica solo Failure e il valore 3 indica Success e Failure: entrambi superano la sua soglia. Questo rilevatore non richiede Success.

Quando nessuna delle due fonti selezionate fornisce l'impostazione, ok=false restituisce Count 0, conserva la gravità Medium inizializzata e include dettagli che spiegano che l'impostazione non è configurata tramite GPO. I criteri effettivi dell'host rimangono sconosciuti; questo non prova né la conformità né la disabilitazione del controllo.

La selezione delle fonti presenta ulteriori limiti:

• La selezione del controllo avanzato preferisce Default Domain Controllers Policy, poi Default Domain Policy, infine la prima voce disponibile nella mappa. La selezione di EventAudit legacy preferisce Default Domain Policy, poi Default Domain Controllers Policy, infine la prima voce disponibile. Questi ordini di precedenza differiscono.
• L'assenza di una sottocategoria nella mappa avanzata selezionata non attiva una ricerca nelle altre mappe avanzate. La funzione ausiliaria può invece ricorrere alla categoria legacy selezionata.
• Il provider SMB ignora gli errori di lettura di GptTmpl.inf e audit.csv durante la raccolta dei criteri. Una sezione EventAudit contenente un altro campo può lasciare il campo Privilege Use mancante al valore zero.
• Il parser di audit.csv estrae coppie GUID/valore; non attesta che un criterio sia stato applicato a un host e non conserva un registro completo della provenienza dell'applicazione.

Questo percorso non calcola il Windows Resultant Set of Policy e non tiene pienamente conto di SCENoApplyLegacyAuditPolicy. Non dimostra neppure la generazione, l'inoltro o il parsing degli eventi. Usare il rilievo per dare priorità all'indagine, poi chiudere la revisione con l'output auditpol di ogni host e le prove di raccolta.

Registro di revisione

Conservare la decisione sulla configurazione di riferimento, l'inventario degli host nel perimetro, l'output dei criteri per host, le eccezioni approvate, il confronto prima/dopo e i campioni di eventi locali associati alle copie centrali. Assegnare un responsabile a ogni risultato sconosciuto. La revisione è completa quando ogni host nel perimetro ha un esito documentato e la telemetria richiesta è stata verificata, con ogni eccezione rimanente esplicitamente accettata dal relativo responsabile.