Punti ciechi monitoraggio Active Directory: Display Specifiers, RODC, manomissione Default Domain Policy e PAM Shadow Principals

Punti ciechi monitoraggio Active Directory: Display Specifiers, RODC e altri due

I punti ciechi del monitoraggio Active Directory — display specifiers, cache delle credenziali RODC, manomissione della Default Domain Policy e PAM shadow principals — raramente emergono in una revisione di sicurezza standard, anche se tutti e quattro sono meccanismi documentati da Microsoft che possono garantire a un attaccante persistenza o accesso privilegiato mentre le dashboard abituali (appartenenza a Domain Admins, diritti DCSync, modifiche ACL sugli oggetti Tier 0) restano verdi. Sono punti ciechi perché nessuno punta una SACL o una query verso di essi, non perché siano nascosti.

Questo articolo tratta ciascuno di essi a turno: cos'è realmente l'oggetto o il meccanismo, come viene abusato o come deriva, cosa osservare per rilevarlo, e come rimediare.

Display Specifiers: un punto di estensione dell'interfaccia trasformato in backdoor di persistenza

Il meccanismo

I display specifiers sono oggetti di classe displaySpecifier, memorizzati in contenitori specifici per locale sotto CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> — ad esempio CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration. Poiché risiedono nel naming context Configuration, si replicano su tutti i domain controller della foresta. Il loro scopo documentato, secondo il riferimento di programmazione Win32 AD di Microsoft, è del tutto legittimo: memorizzano i dati dietro le property sheet, i menu contestuali, le icone e le procedure guidate di creazione negli strumenti basati su MMC come Active Directory Users and Computers (ADUC).

Gli attributi che rendono questo interessante dal punto di vista della sicurezza sono adminContextMenu e adminPropertyPages (snap-in amministrativi) e i loro equivalenti non amministrativi contextMenu/shellContextMenu — tutti documentati nella specifica di protocollo [MS-ADTS] di Microsoft e nel riferimento della classe di schema Display-Specifier. Ciascuno può registrare un oggetto COM o un'applicazione da eseguire quando un amministratore interagisce con un oggetto tramite ADUC. I ricercatori di sicurezza di Semperis e SDM Software hanno documentato direttamente questo caso di abuso: un attaccante con accesso in scrittura a un display specifier può aggiungere una voce di menu contestuale fasulla — che sembra un'azione normale (ad esempio un'opzione di reset password) — che in realtà avvia uno script quando un amministratore dell'helpdesk fa clic destro su un oggetto utente.

Rilevamento

Le modifiche agli oggetti della directory generano l'Event ID di sicurezza Windows 5136 ("A directory service object was modified"), ma solo se sono soddisfatte entrambe le condizioni: il DC ha abilitato la sottocategoria di controllo avanzato "Audit Directory Service Changes", e l'oggetto target porta una SACL per gli attributi rilevanti. Nessuna delle due è attiva per impostazione predefinita per il contenitore DisplaySpecifiers — motivo per cui questo punto cieco esiste. Una volta attivato l'audit, monitorate gli eventi 5136 in cui la classe dell'oggetto è displaySpecifier e l'attributo modificato è adminContextMenu, adminPropertyPages, contextMenu o shellContextMenu. Vedi Monitoraggio sicurezza AD: gli Event ID che contano per la base di policy di audit più ampia che questi controlli presuppongono.

# Enumera tutti gli oggetti display specifier e i loro attributi di menu/property page
Get-ADObject -SearchBase "CN=DisplaySpecifiers,CN=Configuration,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'displaySpecifier'" `
  -Properties adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu |
  Where-Object { $_.adminContextMenu -or $_.adminPropertyPages -or $_.contextMenu -or $_.shellContextMenu } |
  Select-Object Name, adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu

Una baseline pulita per questa query è un result set vuoto sulla maggior parte dei domini — qualsiasi riscontro merita una revisione manuale del CLSID COM o del percorso applicativo referenziato.

Manomissione della Default Domain Policy: cambiamenti silenziosi nella baseline di sicurezza del dominio

Il meccanismo

La Default Domain Policy porta un GUID noto e indipendente dalla foresta — {31B2F340-016D-11D2-945F-00C04FB984F9} — e applica la baseline di policy di account, password, Kerberos e lockout a livello di dominio, salvo che venga sovrascritta da una GPO più specifica. Poiché quel GUID è hardcoded e prevedibile, e poiché quella GPO è abbastanza datata da far sì che la maggior parte dei team abbia smesso di rivederla dopo l'hardening iniziale, le modifiche apportate tendono a passare inosservate. MITRE ATT&CK classifica la manomissione delle GPO come sotto-tecnica T1484.001 (Domain or Tenant Policy Modification: Group Policy Modification) — gli avversari alterano le GPO per indebolire le soglie di lockout dell'account, disattivare la complessità delle password, o distribuire un'attività pianificata/script di logon a ogni computer che applica la policy.

Rilevamento

Due Event ID distinti coprono livelli diversi di una modifica GPO, e confonderli è un errore comune:

• Event ID 5136 ("A directory service object was modified") si attiva sull'oggetto AD groupPolicyContainer stesso quando la sottocategoria "Audit Directory Service Changes" e una SACL sull'oggetto sono entrambe presenti. Sia la ricerca di detection di Splunk sia le linee guida di detection di MITRE indicano specificamente di monitorare gli attributi gPCFileSysPath, gPCMachineExtensionNames e versionNumber — un incremento di versione senza una corrispondente richiesta di modifica SYSVOL è di per sé un segnale da segnalare.
• Event ID 4739 ("Domain Policy was changed") si attiva quando la policy di account effettiva — soglia di lockout, policy delle password, policy Kerberos — cambia realmente, sia che il cambiamento provenga da Group Policy sia da Local Security Policy. È l'evento a segnale più alto per capire "se la baseline di sicurezza stessa si è mossa", ma non indica quale GPO o quale amministratore ha effettuato la modifica — abbinatelo al 5136 per l'attribuzione.

# Bozza di detection in stile Splunk: modifica dell'oggetto Default Domain Policy
index=wineventlog EventCode=5136 ObjectDN="*CN=Policies,CN=System,DC=*"
| search ObjectDN="*{31B2F340-016D-11D2-945F-00C04FB984F9}*"
| table _time, SubjectUserName, AttributeLDAPDisplayName, AttributeValue, OperationType

PAM Shadow Principals: accesso admin effimero che le query standard non rilevano

Il meccanismo

La funzionalità Privileged Access Management (PAM) di Windows Server, costruita su Microsoft Identity Manager, concede accesso privilegiato limitato nel tempo senza mai aggiungere un account a un gruppo permanente come Domain Admins. La stessa documentazione PAM di Microsoft descrive il meccanismo: uno shadow principal — un oggetto di classe msDS-ShadowPrincipal, creato solo all'interno del contenitore predefinito CN=Shadow Principal Configuration sotto CN=Services nel NC Configuration di una foresta bastione — porta un attributo msDS-ShadowPrincipalSid che lo mappa a un SID di gruppo privilegiato nella foresta di produzione (ad esempio Domain Admins). L'appartenenza a quello shadow principal viene concessa con un time-to-live (TTL) tramite la funzionalità AD Expiring Links (Windows Server 2016+): il KDC limita qualsiasi ticket Kerberos che emette al TTL residuo sul link, cosicché l'accesso scade davvero invece di dipendere dal fatto che qualcuno si ricordi di rimuoverlo.

Il punto cieco: i link di gruppo con scadenza sono memorizzati come normali valori dell'attributo member con un flag di TTL, ma quel TTL è visibile solo a una query che passa esplicitamente il controllo esteso LDAP_SERVER_LINK_TTL (OID 1.2.840.113556.1.4.2309), come documentato dalla ricerca di DSInternals sul funzionamento reale degli Expiring Links. Una query di routine "chi è in questo gruppo" che non passa quel controllo vede un'appartenenza dall'aspetto normale — nessuna scadenza, nessun flag di limite temporale evidente — il che significa che un amministratore che esegue una scansione dei gruppi shadow principal con strumenti di audit AD generici può non notare che l'accesso è effimero per progettazione, o può non rilevare del tutto aggiunte di appartenenza di breve durata se l'intervallo di scansione è più lungo del TTL.

Rilevamento

I gruppi shadow principal restano comunque oggetti di classe gruppo di sicurezza, quindi le aggiunte di appartenenza generano gli stessi eventi AD standard di appartenenza a gruppo di qualsiasi altro gruppo, in base al tipo di gruppo: 4728 (membro aggiunto a un gruppo di sicurezza globale), 4732 (dominio locale), 4756 (universale). Filtrate questi eventi specificamente per gli oggetti all'interno di CN=Shadow Principal Configuration,CN=Services,CN=<config-NC> per isolare le attivazioni PAM dall'amministrazione di gruppo di routine.

# Elenca gli shadow principal attuali e il loro SID della foresta di produzione mappato
Get-ADObject -SearchBase "CN=Shadow Principal Configuration,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'msDS-ShadowPrincipal'" `
  -Properties 'msDS-ShadowPrincipalSid', member |
  Select-Object Name, 'msDS-ShadowPrincipalSid', @{N='MemberCount';E={$_.member.Count}}

Cache delle credenziali RODC, in breve

I Read-Only Domain Controller (RODC) vengono distribuiti specificamente per siti a bassa fiducia — filiali, sedi fisicamente esposte — nell'assunto che, se uno viene compromesso, il raggio d'impatto sia limitato alle password degli account che era autorizzato a mettere in cache. Quel confine è imposto da due appartenenze a gruppo: l'Allowed RODC Password Replication Group (vuoto per impostazione predefinita — un RODC non mette in cache nulla finché non è esplicitamente consentito) e il Denied RODC Password Replication Group, corrispondenti agli attributi msDS-RevealOnDemandGroup e msDS-NeverRevealGroup documentati da Microsoft. Ciò che è stato effettivamente messo in cache è visibile tramite msDS-RevealedList; chi si è autenticato tramite il RODC è in msDS-AuthenticatedToAccountlist.

Questo è l'unico punto cieco di questo articolo in cui la soluzione è soprattutto una questione di policy, non una lacuna di monitoraggio che la maggior parte dei team ignora — EtcSec ha già trattato il percorso completo di rilevamento e remediation per la cache privilegiata su RODC, incluse le esatte configurazioni errate della Password Replication Policy che permettono a una credenziale Tier 0 di finire replicata dove non dovrebbe mai esserlo. Vedi RODC cache delle credenziali privilegiate: il controller di dominio in sola lettura che detiene gli hash di Domain Admin per l'approfondimento; il riepilogo qui è volutamente breve per evitare di duplicarlo.

Punti ciechi monitoraggio Active Directory: cosa osservare davvero

Nessuno di questi controlli richiede una nuova pipeline di logging — servono solo SACL posizionate su oggetti che non le hanno per impostazione predefinita, e qualcuno che interroghi attributi che gli script standard di health-check AD non toccano.

Remediation

Passo dopo passo

1. Display specifiers. Posizionate una SACL "Write all properties" (o, più specificamente, sugli attributi di menu/property page rilevanti) su CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> e i suoi figli. Stabilite ora una baseline dei valori attuali di adminContextMenu/adminPropertyPages, poiché una backdoor compromessa potrebbe già essere presente.
2. Default Domain Policy. Applicate una SACL all'oggetto groupPolicyContainer della Default Domain Policy e alla sua cartella SYSVOL (\\<domain>\SYSVOL\<domain>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}). Generate un alert su qualsiasi coppia 5136/4739 che non corrisponda a un ticket di modifica tracciato.
3. PAM shadow principals. Se PAM/MIM non è distribuito intenzionalmente, confermate che il contenitore CN=Shadow Principal Configuration sia vuoto e che rimanga tale. Se è distribuito, rivedete l'appartenenza agli shadow principal con una cadenza che tenga conto di TTL più brevi del vostro intervallo di revisione — un link scaduto tra due scansioni settimanali non compare in nessuna delle due a meno che non confrontiate gli eventi 4728/4732/4756, non solo istantanee puntuali dell'appartenenza.
4. Cache delle credenziali RODC. Confermate che l'Allowed RODC Password Replication Group non contenga alcun principal Tier 0, direttamente o tramite appartenenza a gruppo annidata — vedi l'articolo dedicato collegato sopra per il percorso completo di remediation, inclusi i controlli precisi della policy di replica.
5. Inviate tutti e cinque gli Event ID sopra citati (5136, 4739, 4728, 4732, 4756) al SIEM che già ingerisce la vostra baseline di policy di audit Active Directory — questa è un'estensione dell'audit esistente di Account Management e Policy Change, non una nuova categoria di logging, e si integra naturalmente con i processi esistenti di monitoraggio GPO e revisione degli accessi privilegiati.

Come EtcSec rileva questo

I detector Advanced e Computers di EtcSec segnalano automaticamente tutti e quattro questi punti ciechi durante ogni audit AD: DISPLAY_SPECIFIER_CHANGES rileva le modifiche recenti agli oggetti display specifier, DEFAULT_DOMAIN_POLICY_CHANGED segnala le modifiche alla policy di sicurezza baseline del dominio, EPHEMERAL_ADMINS_PAM fa emergere l'attività degli shadow principal PAM (incluse le appartenenze a TTL breve che uno snapshot manuale non rileverebbe), e RODC_PRIVILEGED_CACHING — classificato Critico — rileva le credenziali Tier 0 replicate su un RODC.