Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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 se impide que esta cuenta cree 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.
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.
Dado que 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.
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 pueden ser utilizados 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.
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 tiene 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.
Consúltalo en la publicación original: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
