Lacune nella configurazione dei criteri di controllo di Active Directory: le categorie che nessuno attiva finché non servono i log

Cosa sono le lacune nella configurazione dei criteri di controllo di Active Directory

La maggior parte dei team Active Directory presume che se il registro eventi Security si sta riempiendo, l'ambiente sia "sotto controllo". Non è così — non nel modo che conta per rilevare un attacco. Le lacune nella configurazione dei criteri di controllo di Active Directory sono le sottocategorie che Windows fornisce disattivate, configurate solo a metà, o silenziosamente sovrascritte, per cui gli eventi di cui un investigatore avrebbe bisogno in seguito non sono mai stati generati. Windows organizza ciò che viene registrato in una Configurazione Avanzata dei Criteri di Controllo composta da 10 categorie suddivise in decine di sottocategorie — passate dalle 9 categorie di base originali a 53 sottocategorie granulari a partire da Windows Vista e Windows Server 2008 (il numero è cresciuto ulteriormente da allora, poiché le versioni successive di Windows hanno aggiunto sottocategorie come Group Membership e PNP Activity), come descritto nella storia ufficiale Microsoft delle politiche di controllo avanzate di Windows Server. Ogni sottocategoria è un interruttore indipendente. Lasciane una disattivata, e ogni evento che avrebbe generato semplicemente non esiste mai — nessun log da rivedere in seguito, nessuna lacuna da notare in una revisione dell'incidente, nulla.

In pratica, quattro punti ciechi ricorrono continuamente negli ambienti AD la cui politica di controllo non è mai stata deliberatamente rivista, e corrispondono direttamente a ciò che cercano i nostri controlli di audit di sicurezza Active Directory:

• Account Management lasciato ai valori predefiniti di Windows invece di essere pienamente abilitato (successo e fallimento), per cui le modifiche a utenti, computer e gruppi restano parzialmente o del tutto non registrate.
• Account Logon (la categoria che copre realmente l'autenticazione Kerberos sui controller di dominio) completamente disattivata — questa è disattivata per impostazione predefinita anche sui server.
• Policy Change che non copre le sottocategorie che contano oltre a quella che Windows registra già automaticamente.
• Nessun account honeypot o esca in nessun punto della directory, quindi nessun trigger a falsi positivi quasi nulli per l'enumerazione o l'abuso di credenziali.

Ciascuna è piccola da sola. Insieme, significano che le categorie che rileverebbero la creazione di privilegi, l'abuso di credenziali e un attaccante che copre le proprie tracce sono proprio quelle con minore probabilità di registrare qualcosa. Queste lacune si affiancano alle altre priorità di hardening trattate in Mettere in Sicurezza Active Directory: Cosa Bloccare per Primo — i criteri di controllo raramente ricevono la stessa attenzione delle ACL o dell'isolamento del Tier 0, proprio perché un log mancante non si annuncia da solo. A differenza di un'ACL pericolosa o di un gruppo con privilegi eccessivi, una sottocategoria di controllo disattivata non produce alcun artefatto su cui imbattersi durante una revisione di routine — l'unico modo per scoprirla è andare a verificare direttamente la politica effettiva, sul controller di dominio, invece di presumere che l'editor GPO racconti tutta la storia.

Come Funziona Davvero la Politica di Controllo di Windows — E Dove Fallisce Silenziosamente

Microsoft pubblica una tabella di raccomandazioni di riferimento proprio per questo motivo: la politica predefinita di Windows Server lascia disattivate diverse sottocategorie rilevanti per l'identità, e solo un sottoinsieme delle sottocategorie di Account Management registra i fallimenti di default. Due impostazioni predefinite spiccano specificamente per AD:

• Audit Credential Validation (la sottocategoria sotto Account Logon che governa la convalida delle password NTLM e Kerberos) viene fornita come No | No — completamente disattivata — sia su Windows Client che su Windows Server. La raccomandazione di riferimento Microsoft la porta a Yes | Yes sui server (i controller di dominio di cui tratta questo articolo) e a Yes | No sui client, e le altre tre sottocategorie di Account Logon (Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events) non hanno alcun valore predefinito.
• Audit Policy Change (sotto Policy Change) è predefinito su Yes | No — solo successo. Il riferimento Microsoft raccomanda Yes | Yes.

Questo secondo punto conta per un dettaglio che Microsoft documenta direttamente sull'evento stesso: l'Event ID 4719 ("System audit policy was changed") "viene sempre registrato indipendentemente dall'impostazione della sottocategoria Audit Policy Change". Questo è rassicurante per l'evento che gli amministratori di solito già conoscono — ma Authentication Policy Change e Authorization Policy Change sono sottocategorie separate, attivate in modo indipendente, all'interno della stessa categoria Policy Change, e nessuna delle due riceve lo stesso lasciapassare gratuito. Se non sono esplicitamente abilitate, un attaccante che allenta silenziosamente le impostazioni di delega Kerberos o un'assegnazione di privilegi non lascia nulla dietro di sé.

La Trappola della Sovrascrittura Legacy-vs-Avanzata

Esiste una seconda trappola, più operativa, ed è la stessa categoria di problema delle configurazioni errate delle GPO che trasformano Group Policy in un vettore di attacco: anche quando una GPO abilita correttamente una sottocategoria avanzata, quell'impostazione può essere silenziosamente sovrascritta dalla Politica di Sicurezza Locale legacy a 9 categorie, a meno che il dominio non abiliti anche "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" — il valore di registro SCENoApplyLegacyAuditPolicy sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa, secondo la documentazione Microsoft per questa politica. Saltalo, e la GPMC può mostrare ogni sottocategoria correttamente configurata mentre il controller di dominio continua silenziosamente ad applicare la vecchia politica a livello di categoria.

Questo articolo tratta deliberatamente il tema se queste categorie siano anche solo attivate. Cosa fare una volta che lo sono — quali event ID specifici monitorare e come costruire la logica di rilevamento — è trattato in Monitoraggio Active Directory: Gli Event ID di Sicurezza che Contano.

Rilevamento: Verificare Cosa È Realmente Attivato, Non Cosa Dichiara la GPO

Verificare la Politica Effettiva con auditpol

Non fidarti solo della Group Policy Management Console. Esegui auditpol direttamente su un controller di dominio per vedere la politica effettiva:

# Politica di controllo effettiva completa su questo DC
auditpol /get /category:*

# Solo le categorie trattate in questo articolo
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Policy Change"

# Conferma che l'impostazione GPO di sovrascrittura legacy sia stata effettivamente applicata
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

Se una sottocategoria mostra "No Auditing", gli eventi nella tabella seguente non vengono generati su quella macchina — punto, nulla da cercare in seguito:

Perché un Account Honeypot Chiude il Cerchio

Un honey user è un account AD esca senza privilegi reali, posizionato in modo che gli strumenti di enumerazione (BloodHound, password sprayer, script di Kerberoasting) lo trovino e lo provino come qualsiasi altro obiettivo. Poiché un utente o servizio legittimo non lo tocca mai, qualsiasi 4768/4769/4624 contro quell'account è un segnale con una confidenza vicina al 100% — l'opposto del problema di affaticamento da falsi allarmi che le altre tre categorie possono creare una volta attivate. Le esche efficaci richiedono metadati e posizionamento realistici, non un nome ovvio come honeypot-admin-01, secondo le linee guida sulla tecnologia di inganno in questo ambito. Lo stesso principio è alla base del rilevamento dell'abuso di ACL e dei percorsi DCSync: una richiesta di replica proveniente da un account che non ha motivo di replicare è esattamente il tipo di segnale a basso rumore e alta confidenza che queste categorie di controllo esistono per rivelare.

Da verificare anche: gli attaccanti che riescono a disattivare la registrazione stanno eseguendo MITRE ATT&CK T1562.002 — Impair Defenses: Disable Windows Event Logging, una tecnica di evasione delle difese che punta specificamente ai criteri di controllo trattati in questo articolo. Un ambiente che non ha mai attivato queste categorie fin dall'inizio regala a questa tecnica una vittoria gratuita che altrimenti non avrebbe.

Rimedio: Colmare le Quattro Lacune

Correggere Prima Account Logon e Account Management

1. Abilita Account Logon completamente, successo e fallimento, tramite Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Account Logon: Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events.
2. Porta Account Management al livello di riferimento Microsoft (successo e fallimento) per User Account Management, Security Group Management, Computer Account Management e Other Account Management Events — non solo il valore predefinito di solo successo.

Completare Policy Change e Bloccare la Sovrascrittura GPO

3. Completa Policy Change: abilita Authentication Policy Change e Authorization Policy Change insieme alla sottocategoria Audit Policy Change già parzialmente attiva, così che la manomissione della politica Kerberos e delle assegnazioni di privilegi generi realmente eventi.
4. Imposta la sovrascrittura legacy della GPO ("Audit: Force audit policy subcategory settings...") a livello di dominio, quindi riesegui la verifica auditpol /get sopra descritta su un DC dopo un gpupdate /force — verifica la politica effettiva, non fidarti solo dell'editor GPO.

Distribuire un Account Esca e Segnalare l'Evento 4719

5. Distribuisci almeno un account honeypot per dominio, con attributi e posizionamento nei gruppi realistici, e segnala qualsiasi evento di autenticazione contro di esso.
6. Inoltra tutto quanto sopra a un SIEM e segnala incondizionatamente l'Event ID 4719 — la stessa indicazione Microsoft è di trattare qualsiasi modifica non pianificata della politica di controllo come un trigger di indagine ad alta priorità, poiché gli attaccanti disattivano il controllo specificamente per operare senza lasciare prove.

Considera questo come un controllo ricorrente, non un progetto una tantum: la ricostruzione di un controller di dominio, una nuova GPO che ripristina l'impostazione di sovrascrittura legacy, o una migrazione verso una nuova foresta possono silenziosamente reintrodurre una qualsiasi di queste quattro lacune, e nessuna di esse comparirà come un allarme — compariranno semplicemente come un'assenza, mesi dopo, in un incidente in cui i log necessari non sono mai stati scritti. Integrare questo controllo in un flusso di audit AD ricorrente è l'unico modo affidabile per individuare la deriva prima che diventi un problema.

Come EtcSec Rileva Questo

EtcSec verifica gli oggetti Group Policy di Active Directory a ogni audit esattamente per queste lacune: AUDIT_POLICY_WEAK segnala le sottocategorie al di sotto del riferimento Microsoft, DC_AUDIT_POLICY_INCOMPLETE segnala i controller di dominio in cui la politica effettiva non corrisponde a quanto dichiarato dalla GPO, ANSSI_R38_ADVANCED_AUDIT_NOT_ENABLED verifica la conformità alla raccomandazione ANSSI R38 per la copertura dei criteri di controllo avanzati, e NO_HONEYPOT_ACCOUNTS segnala le directory senza alcun account esca in tutto il perimetro.