Az - Cloud Kerberos Trust
This post is a summary of https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ which can be checked for further information about the attack. This technique is also commented in https://www.youtube.com/watch?v=AFay_58QubY.
Basic Information
Trust
When a trust is stablished with Azure AD, a Read Only Domain Controller (RODC) is created in the AD. The RODC computer account, named AzureADKerberos$. Also, a secondary krbtgt account named krbtgt_AzureAD. This account contains the Kerberos keys used for tickets that Azure AD creates.
Therefore, if this account is compromised it could be possible to impersonate any user... although this is not true because this account is prevented from creating tickets for any common privileged AD group like Domain Admins, Enterprise Admins, Administrators...
However, in a real scenario there are going to be privileged users that aren't in those groups. So the new krbtgt account, if compromised, could be used to impersonate them.
Kerberos TGT
Moreover, when a user authenticates on Windows using a hybrid identity Azure AD will issue partial Kerberos ticket along with the PRT. The TGT is partial because AzureAD has limited information of the user in the on-prem AD (like the security identifier (SID) and the name).
Windows can then exchange this partial TGT for a full TGT by requesting a service ticket for the krbtgt service.
NTLM
As there could be services that doesn't support kerberos authentication but NTLM, it's possible to request a partial TGT signed using a secondary krbtgt key including the KERB-KEY-LIST-REQ field in the PADATA part of the request and then get a full TGT signed with the primary krbtgt key including the NT hash in the response.
Abusing Cloud Kerberos Trust to obtain Domain Admin
When AzureAD generates a partial TGT it will be using the details it has about the user. Therefore, if a Global Admin could modify data like the security identifier and name of the user in AzureAD, when requesting a TGT for that user the security identifier would be a different one.
It's not possible to do that through the Microsoft Graph or the Azure AD Graph, but it's possible to use the API Active Directory Connect uses to create and update synced users, which can be used by the Global Admins to modify the SAM name and SID of any hybrid user, and then if we authenticate, we get a partial TGT containing the modified SID.
Note that we can do this with AADInternals and update to synced users via the Set-AADIntAzureADObject cmdlet.
Attack prerequisites
The success of the attack and attainment of Domain Admin privileges hinge on meeting certain prerequisites:
The capability to alter accounts via the Synchronization API is crucial. This can be achieved by having the role of Global Admin or possessing an AD Connect sync account. Alternatively, the Hybrid Identity Administrator role would suffice, as it grants the ability to manage AD Connect and establish new sync accounts.
Presence of a hybrid account is essential. This account must be amenable to modification with the victim account's details and should also be accessible for authentication.
Identification of a target victim account within Active Directory is a necessity. Although the attack can be executed on any account already synchronized, the Azure AD tenant must not have replicated on-premises security identifiers, necessitating the modification of an unsynchronized account to procure the ticket.
Additionally, this account should possess domain admin equivalent privileges but must not be a member of typical AD administrator groups to avoid the generation of invalid TGTs by the AzureAD RODC.
The most suitable target is the Active Directory account utilized by the AD Connect Sync service. This account is not synchronized with Azure AD, leaving its SID as a viable target, and it inherently holds Domain Admin equivalent privileges due to its role in synchronizing password hashes (assuming Password Hash Sync is active). For domains with express installation, this account is prefixed with MSOL_. For other instances, the account can be pinpointed by enumerating all accounts endowed with Directory Replication privileges on the domain object.
The full attack
Check it in the original post: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated