Az - Cloud Kerberos Trust
Esta publicación es un resumen de https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ que se puede consultar para obtener más información sobre el ataque. Esta técnica también se comenta en https://www.youtube.com/watch?v=AFay_58QubY.
Información Básica
Confianza
Cuando se establece una confianza con Azure AD, se crea un Controlador de Dominio de Solo Lectura (RODC) en el AD. La cuenta de computadora RODC, llamada AzureADKerberos$. Además, una cuenta secundaria krbtgt llamada krbtgt_AzureAD. Esta cuenta contiene las claves de Kerberos utilizadas para los tickets que crea Azure AD.
Por lo tanto, si esta cuenta se ve comprometida, podría ser posible suplantar a cualquier usuario... aunque esto no es cierto porque esta cuenta está impedida de crear tickets para cualquier grupo privilegiado común de AD como Administradores de Dominio, Administradores Empresariales, Administradores...
Sin embargo, en un escenario real habrá usuarios privilegiados que no están en esos grupos. Así que la nueva cuenta krbtgt, si se ve comprometida, podría usarse para suplantarlos.
Kerberos TGT
Además, cuando un usuario se autentica en Windows utilizando una identidad híbrida, Azure AD emitirá un ticket Kerberos parcial junto con el PRT. El TGT es parcial porque AzureAD tiene información limitada del usuario en el AD local (como el identificador de seguridad (SID) y el nombre).
Windows puede entonces intercambiar este TGT parcial por un TGT completo solicitando un ticket de servicio para el servicio krbtgt.
NTLM
Como podría haber servicios que no admiten autenticación kerberos sino NTLM, es posible solicitar un TGT parcial firmado utilizando una clave secundaria krbtgt incluyendo el campo KERB-KEY-LIST-REQ en la parte PADATA de la solicitud y luego obtener un TGT completo firmado con la clave primaria krbtgt incluyendo el hash NT en la respuesta.
Abusando de la Confianza de Kerberos en la Nube para obtener Administrador de Dominio
Cuando AzureAD genera un TGT parcial, lo hará utilizando los detalles que tiene sobre el usuario. Por lo tanto, si un Administrador Global pudiera modificar datos como el identificador de seguridad y el nombre del usuario en AzureAD, al solicitar un TGT para ese usuario, el identificador de seguridad sería uno diferente.
No es posible hacer eso a través de Microsoft Graph o Azure AD Graph, pero es posible utilizar la API que utiliza Active Directory Connect para crear y actualizar usuarios sincronizados, que puede ser utilizada por los Administradores Globales para modificar el nombre SAM y el SID de cualquier usuario híbrido, y luego, si nos autenticamos, obtenemos un TGT parcial que contiene el SID modificado.
Tenga en cuenta que podemos hacer esto con AADInternals y actualizar a usuarios sincronizados a través del cmdlet Set-AADIntAzureADObject.
Prerrequisitos del ataque
El éxito del ataque y la obtención de privilegios de Administrador de Dominio dependen de cumplir ciertos prerrequisitos:
La capacidad de alterar cuentas a través de la API de Sincronización es crucial. Esto se puede lograr teniendo el rol de Administrador Global o poseyendo una cuenta de sincronización de AD Connect. Alternativamente, el rol de Administrador de Identidad Híbrida sería suficiente, ya que otorga la capacidad de gestionar AD Connect y establecer nuevas cuentas de sincronización.
La presencia de una cuenta híbrida es esencial. Esta cuenta debe ser susceptible a modificación con los detalles de la cuenta de la víctima y también debe ser accesible para la autenticación.
La identificación de una cuenta de víctima objetivo dentro de Active Directory es una necesidad. Aunque el ataque se puede ejecutar en cualquier cuenta ya sincronizada, el inquilino de Azure AD no debe haber replicado identificadores de seguridad locales, lo que requiere la modificación de una cuenta no sincronizada para obtener el ticket.
Además, esta cuenta debe poseer privilegios equivalentes a administrador de dominio, pero no debe ser miembro de grupos típicos de administradores de AD para evitar la generación de TGTs inválidos por el RODC de AzureAD.
El objetivo más adecuado es la cuenta de Active Directory utilizada por el servicio de sincronización de AD Connect. Esta cuenta no está sincronizada con Azure AD, dejando su SID como un objetivo viable, y posee inherentemente privilegios equivalentes a Administrador de Dominio debido a su papel en la sincronización de hashes de contraseñas (suponiendo que la Sincronización de Hash de Contraseña esté activa). Para dominios con instalación expresa, esta cuenta está prefijada con MSOL_. Para otros casos, la cuenta se puede identificar enumerando todas las cuentas dotadas de privilegios de Replicación de Directorio en el objeto de dominio.
El ataque completo
Consúltalo en la publicación original: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated
