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 equipo RODC, llamada AzureADKerberos$. Además, se crea 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 AD privilegiado común como Administradores de Dominio, Administradores de Empresa, Administradores...
Sin embargo, en un escenario real habrá usuarios privilegiados que no estén en esos grupos. Por lo tanto, la nueva cuenta krbtgt, si se ve comprometida, podría usarse para suplantarlos.
TGT de Kerberos
Además, cuando un usuario se autentica en Windows utilizando una identidad híbrida de Azure AD, Azure AD emitirá un ticket de 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 luego intercambiar este TGT parcial por un TGT completo solicitando un ticket de servicio para el servicio krbtgt.
NTLM
Dado que puede haber servicios que no admiten autenticación kerberos sino NTLM, es posible solicitar un TGT parcial firmado usando una clave krbtgt secundaria que incluya el campo KERB-KEY-LIST-REQ en la parte de PADATA de la solicitud y luego obtener un TGT completo firmado con la clave krbtgt primaria incluyendo el hash NT en la respuesta.
Abuso de la Confianza en Kerberos en la Nube para obtener Administrador de Dominio
Cuando AzureAD genera un TGT parcial estará utilizando los detalles que tiene sobre el usuario. Por lo tanto, si un Administrador Global pudiera modificar datos como el identificador de seguridad y nombre del usuario en AzureAD, al solicitar un TGT para ese usuario el identificador de seguridad sería diferente.
No es posible hacerlo 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, lo cual puede ser utilizado por los Administradores Globales para modificar el nombre SAM y SID de cualquier usuario híbrido, y luego, si nos autenticamos, obtenemos un TGT parcial que contiene el SID modificado.
Ten en cuenta que podemos hacer esto con AADInternals y actualizar usuarios sincronizados a través del cmdlet Set-AADIntAzureADObject.
Requisitos previos del ataque
El éxito del ataque y la obtención de privilegios de Administrador de Dominio dependen de cumplir con ciertos requisitos previos:
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 administrar AD Connect y establecer nuevas cuentas de sincronización.
Es esencial la presencia de una cuenta híbrida. Esta cuenta debe ser modificable con los detalles de la cuenta víctima y también debe ser accesible para la autenticación.
Es necesaria la identificación de una cuenta víctima objetivo dentro de Active Directory. 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 los de un administrador de dominio pero no debe ser miembro de grupos administrativos AD típicos para evitar la generación de TGT 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 se sincroniza con Azure AD, dejando su SID como un objetivo viable, y posee inherentemente privilegios equivalentes a los de un Administrador de Dominio debido a su función en la sincronización de hash de contraseñas (asumiendo que la Sincronización de Hash de Contraseñas está activa). Para dominios con instalación express, esta cuenta tiene el prefijo MSOL_. Para otras instancias, 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
Revísalo en la publicación original: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Última actualización