DCSync utilizando MSOL

Laboratorio solo disponible en el CURSO DE PENTESTING CONTRA LA NUBE DE AZURE Y OFFICE365

Para llevar tu aprendizaje al siguiente nivel y practicar estas técnicas de manera segura y efectiva, te invitamos a adquirir acceso premium a nuestro material de curso. No pierdas esta oportunidad de profundizar tus conocimientos. Para más información y adquirir tu acceso, visita nuestro canal de ventas: https://wa.link/ej3kiu. ¡Te esperamos para empezar este viaje juntos!

Este ataque no se dirige realmente a Azure AD, sino que explota una de sus características para escalar privilegios en el dominio de Active Directory local con el que se sincroniza. Azure AD Connect crea una cuenta de sincronización en el Active Directory local. Como es el encargado de enviar los hashes de las contraseñas de los usuarios a la nube, este usuario tiene privilegios de replicación sobre el dominio:

Puede que no lo sepas, pero si alguna vez has utilizado la función lsadump::dcsync de mimikatz, has utilizado un conjunto específico de derechos en Active Directory llamado Replicación de cambios en el directorio. Puede que hayas pensado que mimikatz era capaz de obtener la información sólo porque estabas utilizando una cuenta de administrador de dominio o una cuenta del grupo de administradores integrado. En realidad, fue porque la cuenta que utilizó tenía dos de los tres derechos especiales posibles: Replicar Cambios de Directorio y Replicar Cambios de Directorio - Todos. Además de estos dos, hay una tercera opción, Replicar cambios de directorio en conjunto filtrado.

A menudo no se entiende cómo funcionan estos diferentes derechos, ni las potenciales implicaciones de seguridad de todos ellos.

Esta cuenta es capaz de replicar los hashes de todos los usuarios del dominio, lo que la convierte en un objetivo muy interesante para los atacantes. Veamos cómo podemos recuperar su contraseña.

El primer paso consiste en encontrar el servidor donde está instalado Azure AD Connect. Microsoft nos ha facilitado la tarea, incluyendo el nombre del servidor de sincronización y el tenant de Azure AD correspondiente a la descripción LDAP del usuario MSOL.

Para este escenario tenemos instalado el Azure AD Connect en el DC, pero en muchas organizaciones normalmente instalan este software en otro servidor aislado.

Al acceder a Azure AD Connect podemos revisar su configuración e identificar el nombre del usuario MSOL.

En la siguiente evidencia, podemos apreciar que el PHS se encuentra habilitado y también el nombre de la base de datos local con la que trabaja este software:

Para validar la existencia del SQL Server y la instancia podemos ejecutar el siguiente comando:

La configuración predeterminada de Azure AD Connect utiliza una base de datos SQL Server Express, pero también se puede utilizar un SQL Server totalmente desplegado.

Es posible desencriptar la contraseñar del usuario MSOL y para ello se requiere privilegios de administrador local sobre el servidor que tiene instalado el Azure AD Connect.

Para este proceso, vamos a utilizar el siguiente script en powershell:

https://gist.github.com/xpn/f12b145dba16c2eebdd1c6829267b90c

En el script de powershell, debemos realizar algunos cambios en la siguiente línea de código en donde se especifica el nombre de la base de datos y la instancia:

Es importante señalar que esta técnica es bastante sigilosa y no es identificada por Windows Defender como un comportamiento malicioso en el 2022.

Teniendo una cuenta de administrador local en el servidor, también sería posible recuperar la contraseña MSOL en la memoria del proceso lsass.exe. Esta operación, sin embargo, es mucho más sospechosa y sería fácilmente detectada por un blue team experimentado.

Como ejemplo, utilicé mimikatz para extraer la contraseña MSOL de la memoria de lsass:

Utilizando la cuenta MSOL recién obtenida, ahora es posible realizar un ataque DCSync y replicar todos los hashes de contraseñas de los usuarios del dominio:

DCSync es una técnica que se utiliza para pedir las claves de cualquier usuario a un controlador del dominio a través del protocolo de replicación (DRSUAPI). Para ello es necesario disponer de los permisos DS-Replication-Get-Changes-All y DS-Replication-Get-Changes sobre el objeto del dominio, por lo que esta técnica se suele utilizar una vez ya se ha logrado elevar privilegios en el Directorio Activo.

Uno de los usos más habituales de este ataque es la obtención de las claves de la cuenta KRBTGT para el forjado de Golden Tickets, lo que sirve como mecanismo de persistencia a nivel de privilegios de usuario.