¡Muy buenas a todos!
En el primer artículo vimos como activar los logs de un Controlador de Dominio para registrar los cambios que se realicen sobre las GPOs. En esta segunda parte, vamos a aprovechar una mala configuración de una de estas GPOs para ganar acceso como administrador sobre uno de los equipos afectados. Para ello, nuestro laboratorio constará de los siguientes elementos:
- Un Controlador de Dominio (DC-01).
- Una unidad organizativa (OU) llamada Servidores_Web.
- Un servidor web enrolado en el dominio (WEB-01) y perteneciente a la unidad organizativa Servidores_Web.
- Un usuario de dominio sin acceso al servidor web (Pitágoras).
- Una GPO que afecta a los equipos que forman parte de la unidad organizativa Servidores_Web y sobre la que Pitágoras tiene permisos de edición.
Creando la GPO vulnerable
En nuestro Controlador de Dominio crearemos la unidad organizativa Servidores_Web y, dentro, la GPO (GPO_Vulnerable).
Fig 1: Creando la GPO. |
Fig 2: Añadiendo a Pitágoras como editor de la GPO. |
Por último, añadiremos el servidor web WEB-01 a la unidad organizativa Servidores_Web para que dicha GPO le aplique.
Fig 3: WEB-01 es miembro del OU Servidores_Web |
Con esta configuración, el usuario Pitágoras tiene permisos de edición sobre la GPO GPO_Vulnerable que aplica a los miembros de la unidad organizativa Servidores_Web o, lo que es lo mismo, el equipo WEB-01.
Localizando GPO vulnerables
Imaginemos que tenemos una sesión en el equipo WKSTN-01 (equipo en dominio) como Pitágoras y hemos conseguido cargar Powerview, ¿cómo localizamos GPO vulnerables?
Para ello empleamos el siguiente comando: Invoke-ACLScanner -ResolveGUIDs| ? {$_.IdentityReferenceName -eq "Pitagoras"}
. Con él podremos identificar todas las ACL interesantes del dominio que aplican a nuestro usuario Pitágoras.
Fig 4: ACL interesantes. |
Como podemos observar en la imagen anterior, Pitágoras tiene permisos de lectura y escritura sobre cierta política. Para saber qué política es y sobre quién aplica, podemos emplear los siguientes comandos:
Get-DomainGPO -Identity '{E2FE8993-F346-41F9-8C27-B1CC4E8C9D40}' | select DisplayName
Get-DomainOU -GPLink "{E2FE8993-F346-41F9-8C27-B1CC4E8C9D40}" -Properties DistinguishedName
Get-DomainComputer | where { $_.DistinguishedName -match "Servidores_web" } |select DnsHostName
Fig 5: Enumerando la GPO. |
Realizando estos pasos, hemos obtenido la siguiente información: Pitágoras tiene permisos para modificar la GPO GPO_Vulnerable que aplica al equipo WEB-01 que es miembro de la unidad Servidores_Web. Enumeración completada.
Atacando la GPO
Para abusar de la configuración errónea de la GPO, vamos a emplear la herramienta SharpGPOAbuse con la que, con un simple comando, podremos añadir nuestro usuario Pitágoras como Administrador Local de WEB-01. Primero, veamos que no tenemos permisos para obtener una sesión remota desde WKSTN-01 en WEB-01.
Fig 6: Comprobando que no tenemos acceso a WEB-01. |
Sin embargo, si abusamos de la GPO con SharpGPOAbuse y esperamos a que se actualice la configuración de directivas de grupo, tendremos acceso como Administrador Local.
Fig 7: Convirtiéndonos en Administrador de WEB-01. |
Nota: de media, la actualización de las directivas ocurre cada 90 minutos, por lo que, en este caso, hemos forzado una actualización mediante el comando gpupdate /force
en el equipo WEB-01.
Fig 8: Gpupdate /force es mejor que esperar. |
En el próximo artículo, analizaremos los logs que tenemos disponibles e intentaremos evidenciar el ataque que acabamos de realizar.
Happy Juancking!
No hay comentarios:
Publicar un comentario