Anidamiento de Grupos AD: Rutas Ocultas a DA

¿Qué es el anidamiento peligroso de grupos?

El anidamiento peligroso de grupos ocurre cuando las cadenas de pertenencia a grupos de Active Directory crean privilegios efectivos que los revisores no pretendían conceder. Un usuario, una cuenta de servicio o un grupo operativo puede no ser miembro directo de Domain Admins, Enterprise Admins, Schema Admins u otro grupo sensible. Pero si está anidado a través de uno o más grupos intermedios, la cuenta puede heredar igualmente el contexto de autorización resultante.

Los grupos de seguridad de Active Directory son objetos de autorización. Pueden colocarse en listas de control de acceso, recibir derechos y añadirse a otros grupos. Ese anidamiento es útil para la administración, pero también dificulta la revisión de privilegios. La pertenencia directa solo responde a una pregunta: ¿quién es miembro explícito de este grupo? La pertenencia efectiva responde a la pregunta más importante: ¿quién recibe este privilegio una vez resueltas todas las pertenencias anidadas?

El problema es habitual en dominios de larga vida. Los grupos sobreviven migraciones, reorganizaciones, fusiones, reconstrucciones de aplicaciones, cambios de emergencia y cambios de propietario. Un grupo creado para la administración de servidores en 2016 puede seguir anidado en una ruta protegida en 2026, aunque nadie en el equipo actual recuerde por qué.

Cómo el anidamiento de grupos crea privilegios ocultos

Cuando el Grupo A es miembro del Grupo B, los miembros del Grupo A heredan los permisos efectivos del Grupo B. Si el Grupo B es a su vez miembro de un grupo Tier 0, los miembros del Grupo A ahora tienen una ruta Tier 0, aunque ninguna de esas cuentas aparezca como miembro directo del grupo privilegiado final.

Ese es el riesgo central: las rutas anidadas ocultan el privilegio en medio de la cadena. Una revisión directa de Domain Admins puede mostrar solo uno o dos grupos. Pero cada uno de esos grupos puede contener otros grupos, cuentas de servicio, usuarios obsoletos o identidades operativas compartidas.

Microsoft documenta las cuentas y grupos protegidos en Active Directory, incluidos grupos como Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators y otros. Esos grupos merecen una revisión especial porque la pertenencia puede otorgar una capacidad administrativa poderosa o activar un comportamiento de cuenta protegida a través de AdminSDHolder.

Pertenencia directa vs pertenencia efectiva

Una revisión útil separa tres vistas:

Solo la tercera vista ofrece un plan de remediación. Si un usuario de helpdesk se resuelve en Domain Admins a través de cinco grupos, eliminar al usuario del último grupo no es la solución porque no está directamente allí. Hay que eliminar o rediseñar la arista de grupo que crea la ruta.

Dónde suelen ocultarse las rutas Tier 0 ocultas

Los problemas de anidamiento peligroso suelen provenir de patrones predecibles:

• grupos de migración conservados tras una consolidación de directorio
• grupos de administración de servidores anidados hacia arriba para resolución de problemas temporal
• cuentas de backup, despliegue o monitorización con acceso amplio otorgado durante una interrupción
• grupos operativos compartidos usados por varios equipos sin propietario actual
• grupos de soporte de aplicaciones que heredaron derechos de grupos admin heredados
• grupos creados para una región o unidad de negocio y luego reutilizados en otro lugar
• grupos de proyectos antiguos que aún contienen exempleados o cuentas de servicio

Una revisión práctica empieza en la parte superior de la frontera de privilegio y desciende. Empiece por los grupos Tier 0 y demuestre quién puede alcanzarlos de forma transitiva. Revisar los grupos alfabéticamente desperdicia tiempo y suele pasar por alto la ruta que importa.

La cadena de ataque

Paso 1 - Encontrar la ruta anidada

El atacante o evaluador mapea la pertenencia recursiva desde los grupos privilegiados. El objetivo es encontrar una cuenta más fácil de comprometer que un Domain Admin directo, pero que aun así se resuelva en una ruta privilegiada.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Select-Object SamAccountName, ObjectClass, DistinguishedName

Paso 2 - Identificar el eslabón más débil

El eslabón más débil rara vez es un administrador con nombre. Puede ser una cuenta de servicio con un SPN, una cuenta de usuario obsoleta, una cuenta de operador compartida o un gran grupo de soporte. La ruta anidada convierte a esa identidad más débil en un objetivo de escalada significativo.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Where-Object {$_.objectClass -eq 'user'} |
  Get-ADUser -Properties Enabled, PasswordLastSet, ServicePrincipalName, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName

Paso 3 - Usar la autorización existente

Si la identidad comprometida ya hereda los derechos requeridos, el atacante no necesita una nueva vulnerabilidad en Active Directory. El directorio ya concede el acceso. Por eso el anidamiento peligroso es un problema de ruta de ataque, no solo de higiene.

Detección

Event IDs de Windows

Supervise los cambios de grupos de seguridad en los controladores de dominio. Microsoft documenta las familias de eventos clave bajo Audit Security Group Management, y la lista de eventos requeridos de Microsoft Defender for Identity también incluye las variantes de "miembro añadido" de estos eventos (4728, 4732, 4756).

No alerte solo sobre adiciones directas a Domain Admins. Alerte también sobre cambios en grupos uno o dos saltos por debajo de Tier 0, porque ahí es donde suelen crearse las rutas ocultas.

Controles prácticos de revisión

Use controles recurrentes en lugar de una limpieza puntual:

• exportar la pertenencia recursiva de los grupos protegidos
• comparar la pertenencia directa con la efectiva
• marcar cuentas de servicio, cuentas compartidas, usuarios deshabilitados y obsoletos en rutas recursivas
• identificar grupos sin propietario, sin descripción o sin fecha de revisión reciente
• verificar si los cambios de grupo fueron aprobados y esperados
• monitorizar si la misma arista de grupo se recrea tras la limpieza

Remediación

El objetivo no es aplanar todos los grupos. El objetivo es eliminar la herencia oculta de Tier 0 y hacer que las rutas privilegiadas restantes sean explícitas, tengan propietario y sean revisables.

1. Auditar la pertenencia recursiva desde Tier 0 hacia abajo

Empiece por los grupos que definen la frontera de privilegio.

$tier0Groups = @('Domain Admins','Enterprise Admins','Schema Admins','Administrators','Backup Operators')
$results = foreach ($group in $tier0Groups) {
  Get-ADGroupMember -Identity $group -Recursive | ForEach-Object {
    [PSCustomObject]@{
      RootGroup = $group
      Account = $_.SamAccountName
      Type = $_.ObjectClass
      DistinguishedName = $_.DistinguishedName
    }
  }
}
$results | Export-Csv tier0-recursive-membership.csv -NoTypeInformation

2. Encontrar la arista de grupo que crea la ruta

Eliminar a un usuario del grupo equivocado no corrige el modelo. Encuentre la relación de grupo intermedia que otorga el privilegio y decida si sigue siendo necesaria. Si un grupo de admin de servidor está anidado en una ruta de domain admin, rediseñe el modelo administrativo en lugar de crear excepciones cuenta por cuenta.

3. Reconstruir explícitamente los límites de tier

El objetivo es evitar que los grupos de tier inferior hereden derechos de tier superior por anidamiento de conveniencia. Un grupo de helpdesk no debería volverse privilegiado solo porque se anidó en un grupo de admin de servidor que luego se anidó más arriba.

4. Asignar propiedad y cadencia de revisión

Todo grupo cercano a Tier 0 debería tener un propietario, un propósito y una cadencia de revisión. Si nadie puede explicar por qué un grupo está anidado en una ruta privilegiada, elimínelo o póngalo en cuarentena hasta que se demuestre la dependencia. Documente las excepciones como excepciones, no como arquitectura normal.

Qué no hacer

No remedie el anidamiento peligroso eliminando grupos a ciegas. Algunos grupos aún pueden dar soporte a la administración de aplicaciones, trabajos de backup o flujos operativos. La secuencia correcta es identificar la ruta exacta, confirmar la propiedad, eliminar las aristas innecesarias y probar el flujo dependiente. Evite también reemplazar el privilegio anidado por pertenencia de usuario directa en el mismo grupo protegido. Eso puede hacer la ruta más visible, pero no reduce el privilegio. El objetivo es reducir el privilegio efectivo y mejorar la rendición de cuentas, no solo acortar la lista de grupos.

Validación tras la limpieza

Después de la remediación, demuestre que la ruta ha desaparecido:

• volver a ejecutar las exportaciones de pertenencia recursiva para grupos protegidos
• confirmar que ninguna cuenta compartida, cuenta de servicio, cuenta deshabilitada o usuario obsoleto se resuelve ya en Tier 0
• revisar los eventos 4728, 4732, 4756, 4735, 4737 y 4755 durante y después de la remediación
• confirmar que los grupos anidados restantes tienen propietario y propósito documentado
• verificar que las alertas de monitorización se disparan ante cambios en grupos por debajo de la frontera privilegiada
• comparar los resultados del grafo antes y después de la limpieza para que la ruta eliminada quede clara

El objetivo de la validación es simple: el entorno no debería depender de una herencia de privilegio oculta que solo una consulta de grafo pueda explicar después de los hechos.

Cómo EtcSec detecta esto

EtcSec mapea el grafo de grupos efectivo en lugar de depender solo de la pertenencia directa. Eso hace que el hallazgo sea útil por dos razones: muestra la ruta de privilegio completa, y ayuda a los revisores a identificar qué objeto de la cadena es más fácil de comprometer para un atacante.

Lecturas relacionadas

Revise el anidamiento peligroso de grupos junto con Rutas de Ataque AD: Cómo se Encadenan hacia Domain Admin, Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin, Ataques de Confianza AD: Del Dominio Hijo a la Raíz del Bosque, Malas Configuraciones GPO: Cómo la Directiva de Grupo se Convierte en Vector de Ataque, y Cuentas Privilegiadas Obsoletas: Riesgo Oculto en Active Directory. El privilegio anidado suele importar porque se conecta con otra ruta de ataque.

Referencias principales

• Active Directory Security Groups
• Protected accounts and groups in Active Directory
• Audit Security Group Management
• 4732: A member was added to a security-enabled local group
• Configure Windows event auditing - Microsoft Defender for Identity