Az - Cloud Kerberos Trust

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

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.

Visión General de la Relación de Confianza de Kerberos

Cloud Kerberos Trust (Entra ID -> AD) – Esta función (parte de Windows Hello for Business) establece una confianza unidireccional donde el AD local confía en Entra ID para emitir tickets de Kerberos para AD. Habilitarlo crea un objeto de computadora AzureADKerberos$ en AD (apareciendo como un Controlador de Dominio de Solo Lectura) y una cuenta vinculada krbtgt_AzureAD (un KRBTGT secundario). Entra ID posee las claves para estas cuentas y puede emitir TGTs de Kerberos “parciales” para usuarios de AD. Los controladores de dominio de AD honrarán estos tickets, pero con restricciones similares a RODC: por defecto, los grupos de alto privilegio (Domain Admins, Enterprise Admins, etc.) están denegados y se permiten usuarios ordinarios. Esto impide que Entra ID autentique a los administradores de dominio a través de la confianza en condiciones normales. Sin embargo, como veremos, un atacante con suficientes privilegios de Entra ID puede abusar de este diseño de confianza.

Pivotando de Entra ID a AD Local

Escenario: La organización objetivo tiene Cloud Kerberos Trust habilitado para autenticación sin contraseña. Un atacante ha obtenido privilegios de Global Administrator en Entra ID (Azure AD) pero no controla aún el AD local. El atacante también tiene un punto de apoyo con acceso a la red a un Controlador de Dominio (a través de VPN o una VM de Azure en una red híbrida). Usando la confianza en la nube, el atacante puede aprovechar el control de Azure AD para obtener un punto de apoyo a nivel de Domain Admin en AD.

Requisitos Previos:

  • Cloud Kerberos Trust está configurado en el entorno híbrido (indicador: existe una cuenta RODC AzureADKerberos$ en AD).

  • El atacante tiene derechos de Global Admin (o Hybrid Identity Admin) en el inquilino de Entra ID (estos roles pueden usar la API de sincronización de AD Connect para modificar usuarios de Azure AD).

  • Al menos una cuenta de usuario híbrida (existe tanto en AD como en AAD) en la que el atacante pueda autenticarse. Esto podría obtenerse conociendo o restableciendo sus credenciales o asignando un método sin contraseña (por ejemplo, un Temporary Access Pass) para generar un Primary Refresh Token (PRT) para ella.

  • Una cuenta objetivo de AD local con altos privilegios que no esté en la política de “denegación” predeterminada de RODC. En la práctica, un gran objetivo es la cuenta de sincronización de AD Connect (a menudo llamada MSOL_*), que tiene derechos de DCSync (replicación) en AD pero generalmente no es miembro de grupos de administración integrados. Esta cuenta típicamente no se sincroniza con Entra ID, lo que hace que su SID esté disponible para suplantar sin conflicto.

Pasos del Ataque:

  1. Obtener acceso a la API de sincronización de Azure AD: Usando la cuenta de Global Admin, adquirir un token de acceso para la API de Provisioning (sincronización) de Azure AD. Esto se puede hacer con herramientas como ROADtools o AADInternals. Por ejemplo, con ROADtools (roadtx):
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Alternativamente, se puede usar Connect-AADInt de AADInternals para autenticar como Administrador Global.)

  1. Modificar los atributos on-prem de un usuario híbrido: Aprovechar la API de sincronización de Azure AD para establecer el Identificador de Seguridad (SID) y el SAMAccountName onPremises de un usuario híbrido elegido para que coincidan con la cuenta AD de destino. Esto le indica efectivamente a Azure AD que el usuario en la nube corresponde a la cuenta on-prem que queremos suplantar. Usando el kit de herramientas de código abierto ROADtools Hybrid:
# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>

Se necesita el sourceAnchor (ID inmutable) del usuario para identificar el objeto de Azure AD que se va a modificar. La herramienta establece el SID local del usuario híbrido y el nombre de cuenta SAM a los valores del objetivo (por ejemplo, el SID y SAM de la cuenta MSOL_xxxx). Azure AD normalmente no permite alterar estos atributos a través de Graph (son de solo lectura), pero la API del servicio de sincronización lo permite y los administradores globales pueden invocar esta funcionalidad de sincronización.

  1. Obtener un TGT parcial de Azure AD: Después de la modificación, autentíquese como el usuario híbrido en Azure AD (por ejemplo, obteniendo un PRT en un dispositivo o usando sus credenciales). Cuando el usuario inicia sesión (especialmente en un dispositivo con dominio unido o unido a Entra), Azure AD emitirá un TGT Kerberos parcial (TGTAD) para esa cuenta porque Cloud Kerberos Trust está habilitado. Este TGT parcial está cifrado con la clave RODC de AzureADKerberos$ e incluye el SID objetivo que configuramos. Podemos simular esto solicitando un PRT para el usuario a través de ROADtools:
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

Esto genera un archivo .prt que contiene el TGT parcial y la clave de sesión. Si la cuenta era solo de nube, Azure AD aún incluye un TGT_AD en la respuesta PRT.

  1. Intercambiar TGT Parcial por TGT Completo (en AD): El TGT parcial ahora se puede presentar al Controlador de Dominio local para obtener un TGT completo para la cuenta objetivo. Hacemos esto realizando una solicitud TGS para el servicio krbtgt (el servicio TGT principal del dominio) – esencialmente actualizando el ticket a un TGT normal con un PAC completo. Hay herramientas disponibles para automatizar este intercambio. Por ejemplo, utilizando el script de ROADtools Hybrid:
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash

Este script (o equivalentes de Impacket) contactará al Controlador de Dominio y recuperará un TGT válido para la cuenta AD objetivo, incluyendo el hash NTLM de la cuenta si se utiliza la extensión Kerberos especial. La extensión KERB-KEY-LIST-REQ se incluye automáticamente para pedir al DC que devuelva el hash NTLM de la cuenta objetivo en la respuesta encriptada. El resultado es un caché de credenciales (full_tgt.ccache) para la cuenta objetivo o el hash de contraseña NTLM recuperado.

  1. Impersonar al objetivo y elevar a administrador de dominio: Ahora el atacante efectivamente controla la cuenta AD objetivo. Por ejemplo, si el objetivo era la cuenta MSOL de AD Connect, tiene derechos de replicación en el directorio. El atacante puede realizar un ataque DCSync utilizando las credenciales de esa cuenta o el TGT de Kerberos para volcar los hashes de contraseñas de AD (incluyendo la cuenta KRBTGT del dominio). Por ejemplo:
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

Esto volcará todos los hashes de contraseñas de usuarios de AD, dando al atacante el hash de KRBTGT (permitiéndoles falsificar tickets de Kerberos de dominio a voluntad) y efectivamente privilegios de Domain Admin sobre AD. Si la cuenta objetivo fuera otro usuario privilegiado, el atacante podría usar el TGT completo para acceder a cualquier recurso de dominio como ese usuario.

  1. Limpieza: Opcionalmente, el atacante puede restaurar el onPremisesSAMAccountName y SID originales del usuario de Azure AD modificado a través de la misma API o simplemente eliminar cualquier usuario temporal creado. En muchos casos, el próximo ciclo de sincronización de Azure AD Connect revertirá automáticamente los cambios no autorizados en los atributos sincronizados. (Sin embargo, para este punto, el daño ya está hecho: el atacante tiene privilegios de DA.)

Warning

Al abusar del mecanismo de confianza y sincronización en la nube, un Global Admin de Azure AD puede suplantar casi cualquier cuenta de AD que no esté explícitamente protegida por la política de RODC, incluso si esa cuenta nunca fue sincronizada en la nube. En una configuración predeterminada, esto establece una confianza completa desde la compromisión de Azure AD hasta la compromisión de AD local.

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks