EntraGoat Escenario 3: Explotando la Propiedad de Grupo en Entra ID

Nota del editor

Este escenario forma parte de una serie de ejemplos que demuestran el uso de EntraGoat, nuestro entorno de simulación Entra ID. Puede leer una descripción general de EntraGoat y su valor aquí.

Miembro del grupoNaufragio en aguas de la administración

El Escenario 3 de EntraGoat demuestra cómo las características administrativas legítimas de Entra ID -propiedad de grupos, grupos asignables por rol y administración de servicios principales- pueden encadenarse en una ruta de escalamiento de privilegios no intencional desde un usuario con pocos privilegios hasta el Administrador Global.

El atacante comienza con una cuenta de soporte de TI comprometida que posee varios grupos, incluido uno que es asignable con el rol Application Administrator rol. Al añadirse a este grupo, el atacante hereda el rol y obtiene un amplio control sobre las aplicaciones y los principales de servicio en todo el tenant.

A partir de ahí, mediante la identificación de un principal de servicio de alto valor que sea miembro de otro grupo asignable de funciones que posea el Privileged Authentication Administrator el atacante le añade un secreto de cliente, se autentica como el principal privilegiado del servicio y restablece la contraseña del Administrador Global.

Este escenario pone de relieve cómo las funciones Entra ID legítimas individualmente, cuando se combinan con la propiedad de grupo mal configurada, pueden convertirse en una cadena de escalada de privilegios que eleva una cuenta de bajo nivel a una amenaza para todo el inquilino.

Visión general de la ruta de ataque

1. Historia del punto de apoyo inicial: El atacante se autentica como Michael Chen, un usuario especialista en soporte de TI comprometido que, según la descripción del escenario, "gestiona algunos grupos de seguridad".
2. Enumeración: El atacante descubre la propiedad de seis grupos, incluyendo un grupo asignable por roles llamado IT Application Managers que contiene el Application Administrator papel.
3. Escalada de privilegios: El atacante se añade al grupo de seguridad para heredar el rol privilegiado.
4. Objetivo principal del servicio: Con el Application Administrator el atacante identifica el Identity Management Portal principal de servicio como miembro de un grupo con el Privileged Authentication Administrator y le añade un secreto de cliente.
5. Pivoteo: El atacante se autentica a través del flujo OAuth2 de concesión de credenciales de cliente como el principal del servicio comprometido con el nuevo secreto añadido.
6. Compromiso de la cuenta: Utilizando los privilegios inherentes del principal del servicio, el atacante restablece la contraseña del Administrador Global, se autentica como GA y recupera la bandera del escenario.

Flujo de ataque

La figura 1 muestra el flujo de este ataque.

Por qué funciona este ataque

Este escenario encadena varias funciones legítimas de Entra ID que, cuando están mal configuradas, crean una ruta de escalada:

• Propiedad de grupo: El modelo de propiedad de grupos de Entra ID otorga un amplio control sobre la membresía y las propiedades. Aunque está pensado para delegar tareas administrativas, se vuelve arriesgado cuando se aplica a grupos con roles asignables o se concede a usuarios inapropiados, ya que un propietario puede añadirse directamente a sí mismo (o a cualquier cuenta controlada) al grupo y heredar sus roles asignados.
• Grupos con roles asignables: Los grupos de seguridad asignables a funciones permiten a los administradores asignar funciones de directorio a grupos en lugar de a usuarios individuales, lo que simplifica la gestión de funciones a escala haciendo que cualquier miembro del grupo reciba automáticamente las funciones asignadas. Cuando se combina con los permisos de propiedad de grupo, se crea una vía de escalada de privilegios en la que los propietarios de grupos pueden concederse a sí mismos las funciones asignadas a los grupos que controlan.
• Pertenencia al grupo principal del servicio: Los principales de servicio, al igual que los usuarios, pueden ser miembros de grupos de seguridad y heredar cualquier función asignada a esos grupos. Este diseño permite a los administradores gestionar los permisos de las aplicaciones a través de la pertenencia a grupos, en lugar de asignar funciones individuales. Sin embargo, los principales de servicio presentan superficies de ataque únicas que los usuarios regulares de Entra ID no tienen. Estos mecanismos adicionales crean más vectores potenciales para obtener acceso no autorizado a cualquier principal de servicio privilegiado que posea membresías de grupo privilegiadas.
  • Pueden verse comprometidos a través de las relaciones de propiedad (como se ve en el escenario 1).
  • Están sujetas a controles de gestión de aplicaciones-identidades con el Application Administrator o Cloud Application Administrator roles, roles personalizados que incluyen el microsoft.directory/applications/credentials/update o microsoft.directory/servicePrincipals/credentials/update acciones, o principales de servicio con el Application.ReadWrite.All que puede añadir o modificar las credenciales de la entidad de seguridad.
  • Pueden gestionarse mediante programación a través de API y flujos de trabajo de automatización.
  • A diferencia de las identidades de usuario, no pueden asignarse como elegibles para PIM; sólo pueden tener asignaciones de funciones activas (que pueden estar limitadas en el tiempo). Cuando una entidad de seguridad de servicio está en un grupo al que se le pueden asignar funciones, su acceso elude los controles de activación puntual de PIM, proporcionando una pertenencia a funciones siempre activa durante la ventana de asignación.
  • Pueden autenticarse en un contexto exclusivo de la aplicación (credenciales de cliente OAuth2) utilizando un secreto o certificado de cliente, lo que evita los controles centrados en el usuario, como la AMF interactiva y los requisitos de acceso condicional interactivo.
• Ámbito del administrador de aplicaciones: El rol proporciona un amplio control sobre los registros de aplicaciones y los principales de servicio, incluida la capacidad de añadir credenciales de autenticación (secretos y certificados) a las aplicaciones en el tenant, lo que crea oportunidades para que los atacantes accedan por la puerta trasera a los principales de servicio de alto valor que no están configurados con bloqueo de instancia de aplicación.

Cada una de estas características de Entra ID es legítima y necesaria para la delegación administrativa, pero en combinación, crean rutas de escalada de privilegios no intencionadas que pueden elevar una identidad con pocos privilegios hasta la de Administrador Global.

Cómo detectar y defenderse contra el uso indebido de la propiedad colectiva

Supervisar la propiedad de los grupos es un requisito de seguridad fundamental en cualquier entorno Entra ID.

Los propietarios pueden gestionar la pertenencia, cambiar las propiedades del grupo y controlar indirectamente cualquier función de directorio asignada a sus grupos. Sin una visibilidad clara de las relaciones de propiedad y las asignaciones de roles, las rutas de escalada de privilegios a través de grupos asignables a roles pueden permanecer ocultas tanto para los defensores como para los auditores.

Los defensores deben vigilar y correlacionar:

• ¿Qué grupos con asignación de funciones existen en el inquilino?
• ¿Qué funciones de directorio se asignan a estos grupos?
• ¿Quién es su propietario y qué justificación empresarial existe para ello?
• ¿Algún usuario sin privilegios posee grupos con asignaciones de funciones privilegiadas?
• ¿Qué principales de servicio son miembros de grupos asignables a roles?
• ¿Hay grupos no utilizados o huérfanos que puedan darse de baja?

Las soluciones de Semperis ayudan a colmar las lagunas en la comprensión de estas cuestiones con múltiples capas de defensa, empezando por los indicadores de exposición (IOE) y los indicadores de compromiso (IOC).

Estos indicadores detectan y alertan automáticamente sobre valores predeterminados y configuraciones erróneas peligrosas, como grupos asignables a funciones con propietarios inadecuados, principales de servicio con permisos peligrosos y líneas de base de gobernanza de grupos débiles que permiten la escalada de privilegios mediante la manipulación de la pertenencia a grupos.

Escenario en profundidad: Recorrido paso a paso de la solución

Puedes encontrar el tutorial completo y los comandos que lo acompañan en el repositorio EntraGoat GitHub bajo solutions/EntraGoat-Scenario3-Solution.ps1.

Paso 1: Afianzamiento inicial

Comenzamos el Escenario 3, como Figura 2 muestra, con acceso a un usuario poco privilegiado comprometido llamado Michael Chenespecialista en soporte informático. La historia de fondo nos dice que Michael posee varios grupos de seguridad, un error de configuración que prepara el terreno para la escalada.

Nos autenticamos con sus credenciales utilizando Connect-MgGraph y luego ejecute Get-MgContext para confirmar nuestro contexto de seguridad actual (Figura 3).

Paso 2: Enumeración

A continuación, ya que la pista nos indica esta dirección, enumeramos todos los grupos que posee el usuario actual(Figura 4).

Descubrimos que posee seis grupos en total. Para evaluar el potencial de escalada de privilegios, comprobamos si alguno de ellos es asignable a un rol y si realmente tiene roles asignados(Figura 5).

Un grupo destaca inmediatamente: IT Application Managersque mantiene el Application Administrator papel.

Este rol es poderoso ya que otorga control total sobre todos los registros de aplicaciones y service principals en el tenant, incluyendo la habilidad de agregar secretos o certificados a cualquier aplicación de terceros (en caso de que no estén configuradas con app instance lock). A continuación, el atacante puede utilizar la identidad del principal de servicio para autenticarse en el tenant a través del flujo de concesión de credenciales de cliente OAuth 2.0, operando en un contexto exclusivo de la aplicación que elude las protecciones centradas en el usuario.

Nota: Los pasos de enumeración anteriores pueden incluirse en funciones de ayuda específicas (por ejemplo, Get-GroupsOwnedBy para la propiedad y Get-GroupRoles para las funciones asignadas) para que el proceso sea más interactivo y prolijo, similar a la forma en que las herramientas de código abierto presentan los resultados.

Las figuras 6 y 7 muestran la aplicación.

La figura 8 muestra el aspecto de la llamativa salida cuando ejecutamos esta función de enumeración con el ID del usuario actual.

Aunque esto puede ser útil en entornos grandes, Microsoft Graph también proporciona un cmdlet mucho más eficiente: Get-MgUserOwnedObject (Figura 9).

Get-MgUserOwnedObject enumera todos los objetos de directorio propiedad de un usuarioeliminando la necesidad de consultar cada tipo de objeto (grupos, dispositivos, aplicaciones y principales de servicio) individualmente, a diferencia de nuestra implementación intencional. El comando se puede ajustar un poco con Sonnet para obtener una salida más agradable (Figura 10).

La orden Get-MgUserOwnedObject normalmente hace una solicitud API a https://graph.microsoft.com/v1.0/users/{userId}/ownedObjects (posiblemente añadiendo una o dos peticiones más, dependiendo de la paginación), con el resto gestionado por la lógica local de PowerShell para procesar, extraer y formatear la respuesta.

En comparación, el Get-GroupsOwnedBy función que hemos creado, que podría ser más interactiva y fácil de usar, hace que 100-1000x solicitudes APIaunque sólo comprueba un tipo de objeto de propiedad.

Al seleccionar herramientas de enumeración, siempre es una buena idea dar prioridad a la eficiencia. Menos llamadas a la API significan menos registros y una huella de detección más pequeña. Hay muchas herramientas de código abierto increíbles (y algunas menos increíbles) para enumerar entornos Entra ID. El punto clave es que aunque las herramientas pueden ser atajos útiles, nunca deben usarse como cajas negras. Si puede leer el código fuente, hágalo. Tómese el tiempo necesario para comprender cómo se construyen las consultas, qué puntos finales de la API se utilizan y qué datos se devuelven realmente. La eficacia de las herramientas depende de que el usuario conozca sus métodos y limitaciones.

Paso 3: Construir la cadena de ataque

Poseer un grupo con Application Administrator presenta un importante potencial de escalada de privilegios porque una vez que nos añadimos como miembro, podemos gestionar (== añadir un secreto de cliente a) cualquier principal de servicio en el inquilino, lo que abre múltiples rutas para comprometer al inquilino.

Pero añadirnos ahora mismo sería ruidoso e innecesario desde una perspectiva OPSEC. En primer lugar, deberíamos confirmar que existe un servicio privilegiado principal que podemos aprovechar para llegar a la siguiente cadena del ataque: el rol GA.

Es hora de buscar directores de servicios de alto valor.

Nota: En este tutorial, nos centraremos en la enumeración de los principales de servicio con funciones privilegiadas que pueden restablecer la contraseña de GA con sólo unos pasos:

• Administrador de funciones privilegiadas (ARP)
• Administrador de autenticación privilegiada (PAA)
• Administrador global (AG)

Dicho esto, en un inquilino real no querrás detenerte ahí. Es igual de importante enumerar los principales de servicio con otros roles y con potentes permisos de aplicación, ya que pueden abrir rutas de escalada igualmente peligrosas, como se ve en el Escenario 2.

Empezaremos utilizando la función Get-MgRoleManagementDirectoryRoleAssignment para comprobar si se han asignado directamente funciones privilegiadas a algún responsable de servicio (Figura 11).

¿Resultado? Ninguno. Ni un solo director de servicio tiene directamente GA, PRA o PAA en mi inquilino.

Pero ese no es el conjunto completo de principales de servicio que podrían tener roles privilegiados asignados. Entra ID permite grupos con roles asignables, y al igual que los usuarios, los principales de servicio pueden ser miembros de esos grupos. Si un grupo tiene GA, PRA, o PAA, entonces cualquier principal de servicio dentro de él hereda esos privilegios. Este es un vector de escalada que a menudo se pasa por alto.

A continuación, enumeramos todos los grupos a los que se pueden asignar funciones y comprobamos cuáles tienen funciones asignadas(Figura 12).

Ahora que tenemos una lista de grupos privilegiados, necesitamos inspeccionar sus miembros. Dado que la función Get-MgGroupMember funciona en la v1.0, no muestra las membresías principales del servicio. Para solucionarlo, haremos una llamada directa a la función /beta en una función auxiliar (Gráfico 13).

Ahora podemos utilizarlo para filtrar la pertenencia de las entidades de seguridad a los grupos privilegiados(Figura 14).

Ahora las cosas se ponen interesantes - descubrimos potenciales principales de servicio con roles privilegiados. Dependiendo de su entorno, puede tener muchos más.

Podemos elegir simplemente la primera ($targetSPs[0]), pero en aras de la coherencia (y para que todos los jugadores tengan el mismo camino sin arriesgar la estabilidad del inquilino), nos centraremos en el Identity Management Portalcomo Figura 15 muestra. Eso es parte del script de configuración y no romperá nada en caso de un cambio en la funcionalidad (crucemos los dedos).

En esta etapa, hemos trazado la cadena de ataque completa. Así es como nos moveremos desde el actual usuario con pocos privilegios hasta el Administrador Global:

1. Sumarnos a la IT Application Managers para heredar el grupo Application Administrator papel.
2. Utiliza ese rol para añadir un secreto de cliente al Identity Management Portal servicio principal.
3. Autentícate como la entidad de seguridad de ese servicio.
4. Utilice sus privilegios PAA heredados para restablecer la contraseña del administrador global.
5. Inicie sesión como administrador global con la nueva contraseña.
6. Recupera la bandera para demostrar el compromiso.

Paso 4: Ejecución de la ruta de ataque

En primer lugar, nos añadimos como miembros a la IT Application Managers grupo, como Figura 16 espectáculos.

Ya que los tokens no se actualizan automáticamente, podemos desconectarnos y reautenticarnos para obtener un token de acceso fresco con el nuevo rol asignado. Como se discutió en el Escenario 2, este paso no es obligatorio, ya que la mayoría de los puntos finales de Entra ID usualmente evalúan las asignaciones de roles dinámicamente.

Podemos utilizar el parse-JWTToken cmdlet de BARK para ver el rol de administrador de aplicación añadido (el wids dentro del token JWT que Figura 17 shows) asignados al usuario.

Con Application Administrator derechos en nuestras manos, podemos añadir acceso de puerta trasera al Identity Management Portal (Figura 18), como hicimos en Escenario 1.

Esto nos da un acceso persistente al servicio principal, independiente de cualquier cuenta de usuario. Podemos usarlo para autenticarnos como el principal de servicio a Entra ID, como muestra la Figura 19 .

El siguiente paso es encontrar el usuario GA objetivo y restablecer su contraseña(Figura 20).

Por último, podemos autenticarnos como el AG y recuperar la bandera (Figura 21). Utilizaremos Get-MSGraphTokenWithUsernamePassword para autenticarse desde la CLI (igual que en Escenario 2), pero también puede establecer un TAP (como en Escenario 1) e inicie sesión interactivamente desde el portal Azure o el centro de administración Entra ID.

¡Escenario 3 completado!

Paso 5: Limpieza

No olvide ejecutar el script de limpieza(Figura 22) para revertir el entorno del inquilino a su estado original.

Lecciones aprendidas

El escenario 3 revela cómo errores de configuración aparentemente menores en la propiedad de grupos pueden llevar en cascada a un compromiso total del inquilino. La cadena de ataque (desde el usuario con pocos privilegios hasta el Administrador Global) no requirió técnicas sofisticadas, sólo una comprensión del modelo de delegación de Entra ID, cómo funciona la herencia de roles y el plano de control de las identidades principales de servicio.

La clave: La propiedad de grupos es una delegación administrativa encubierta. Cuando los usuarios son propietarios de grupos asignables a funciones, controlan efectivamente cualquier función asignada a esos grupos. Los principales de servicio amplifican este riesgo porque pueden verse comprometidos a través de múltiples vías más allá del tradicional robo de credenciales: relaciones de propiedad, roles de gestión de aplicaciones y acceso programático.

El escenario muestra que en los entornos modernos de identidad en la nube, las rutas de escalada de privilegios rara vez son lineales. Se entretejen a través de relaciones de propiedad, pertenencia a grupos e identidades principales de servicio de maneras que requieren que los defensores piensen sistemáticamente en las relaciones de identidad en lugar de en los permisos individuales.

El especialista en soporte informático con menos privilegios no tenía que romper nada: la ruta de escalado estaba integrada en la configuración del inquilino desde el principio.

Acepta tu próximo reto EntraGoat

GitHub - Semperis/EntraGoat
¿Qué es EntraGoat? Un Entorno de Simulación Entra ID Deliberadamente Vulnerable
Comenzando con EntraGoat: Rompiendo Entra ID de Manera Inteligente
Escenario 1: Abuso de la Propiedad Principal de Servicio en Entra ID
Escenario 2: Explotación de Permisos Gráficos Exclusivos de Aplicaciones en el Entra ID
Escenario 6: Explotación de la Autenticación Basada en Certificados para Hacerse Pasar por el Administrador Global en el Entra ID

Nota final

1. https://github.com/BloodHoundAD/BARK

Descargo de responsabilidad

Este contenido se proporciona únicamente con fines educativos e informativos. Su objetivo es promover la concienciación y la corrección responsable de las vulnerabilidades de seguridad que puedan existir en los sistemas que usted posee o está autorizado a probar. El uso no autorizado de esta información con fines maliciosos, explotación o acceso ilegal está estrictamente prohibido. Semperis no respalda ni aprueba ninguna actividad ilegal y declina toda responsabilidad derivada del uso indebido del material. Además, Semperis no garantiza la exactitud o integridad del contenido y no asume ninguna responsabilidad por los daños derivados de su uso.