# Az - Cloud Kerberos Trust

{{#include ../../../banners/hacktricks-training.md}}

**Hierdie pos is 'n opsomming van** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **wat nagegaan kan word vir verdere inligting oor die aanval. Hierdie tegniek word ook bespreek in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**

## Kerberos Trust Relationship Oorsig

**Cloud Kerberos Trust (Entra ID -> AD)** -- Hierdie funksie (deel van Windows Hello for Business) vestig 'n eenrigting vertroue waar on-prem AD **vertrou Entra ID** om Kerberos kaartjies vir AD uit te reik. Om dit in te skakel, skep dit 'n **AzureADKerberos$** rekenaarobjek in AD (wat as 'n Lees-Alleen Domeinbeheerder verskyn) en 'n gekoppelde **`krbtgt_AzureAD`** rekening (n sekondêre KRBTGT). Entra ID hou die sleutels vir hierdie rekeninge en kan "gedeeltelike" Kerberos TGTs vir AD gebruikers uitreik. AD domeinbeheerder sal hierdie kaartjies eer, maar met RODC-agtige beperkings: per standaard, **hoë-privilege groepe (Domein Administrators, Enterprise Administrators, ens.) is *weggesluit*** en gewone gebruikers word toegelaat. Dit voorkom dat Entra ID domein administrateurs onder normale omstandighede via die vertroue kan autentiseer. Maar soos ons sal sien, kan 'n aanvaller met voldoende Entra ID voorregte hierdie vertrou ontwerp misbruik.

## Pivoting van Entra ID na On-Prem AD

**Scenario:** Die teikenorganisasie het **Cloud Kerberos Trust** geaktiveer vir wagwoordlose autentisering. 'n Aanvaller het **Global Administrator** voorregte in Entra ID (Azure AD) verkry, maar het **nog nie** die on-prem AD onder beheer nie. Die aanvaller het ook 'n voet aan die grond met netwerktoegang tot 'n Domeinbeheerder (via VPN of 'n Azure VM in 'n hibriede netwerk). Deur die wolkvertroue te gebruik, kan die aanvaller Azure AD beheer benut om 'n **Domein Admin**-vlak voet aan die grond in AD te verkry.

**Vereistes:**

-   **Cloud Kerberos Trust** is geconfigureer in die hibriede omgewing (aanwyser: 'n `AzureADKerberos$` RODC rekening bestaan in AD).

-   Die aanvaller het **Global Admin (of Hybrid Identity Admin)** regte in die Entra ID tenant (hierdie rolle kan die AD Connect **synchronisasie API** gebruik om Azure AD gebruikers te wysig).

-   Ten minste een **hibriede gebruikersrekening** (bestaande in beide AD en AAD) wat die aanvaller kan autentiseer as. Dit kan verkry word deur die akkurate inligting te ken of te herstel of 'n wagwoordlose metode (bv. 'n Tydelike Toegangspas) toe te ken om 'n Primêre Vernuwings Token (PRT) vir dit te genereer.

-   'n **on-prem AD teikenrekening** met hoë voorregte wat *nie* in die standaard RODC "weier" beleid is nie. In praktyk is 'n goeie teiken die **AD Connect sink rekening** (dikwels genoem **MSOL_***), wat DCSync (replicasie) regte in AD het, maar gewoonlik nie 'n lid van ingeboude administratiewe groepe is nie. Hierdie rekening word tipies nie gesinkroniseer na Entra ID nie, wat sy SID beskikbaar maak om te verteenwoordig sonder konflik.

**Aanvalstappe:**

1.  **Verkry Azure AD sink API Toegang:** Gebruik die Global Admin rekening, verkry 'n toegangstoken vir die Azure AD **Provisioning (sink) API**. Dit kan gedoen word met gereedskap soos **ROADtools** of **AADInternals**. Byvoorbeeld, met ROADtools (roadtx):
```bash
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
```
*(Alternatiewelik kan AADInternals se `Connect-AADInt` gebruik word om as Global Admin te autentiseer.)*

2.  **Wysig 'n Hibrid Gebruiker se On-Prem Kenmerke:** Maak gebruik van die Azure AD **synchronisasie API** om 'n gekose hibrid gebruiker se **onPremises Security Identifier (SID)** en **onPremises SAMAccountName** in te stel om met die teiken AD rekening te ooreen te kom. Dit vertel effektief aan Azure AD dat die wolk gebruiker ooreenstem met die on-prem rekening wat ons wil naboots. Gebruik die open-source **ROADtools Hybrid** toolkit:
```bash
# 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>
```
> Die `sourceAnchor` (onveranderlike ID) van die gebruiker is nodig om die Azure AD objek te identifiseer wat gewysig moet word. Die hulpmiddel stel die hibriede gebruiker se on-prem SID en SAM rekeningnaam in op die waardes van die teiken (bv. die MSOL_xxxx rekening se SID en SAM). Azure AD verbied normaalweg om hierdie eienskappe via Graph te verander (hulle is slegs lees), maar die sink diens API laat dit toe en Global Admins kan hierdie sink funksionaliteit aanroep.

3.  **Verkry 'n Gedeeltelike TGT van Azure AD:** Na die wysiging, autentiseer as die hibriede gebruiker by Azure AD (byvoorbeeld, deur 'n PRT op 'n toestel te verkry of hul akrediteer te gebruik). Wanneer die gebruiker aanmeld (veral op 'n domein-verbonden of Entra-verbonden Windows toestel), sal Azure AD 'n **gedeeltelike Kerberos TGT (TGT**<sub>**AD**</sub>) vir daardie rekening uitreik omdat Cloud Kerberos Trust geaktiveer is. Hierdie gedeeltelike TGT is versleuteld met die AzureADKerberos$ RODC sleutel en sluit die **teiken SID** in wat ons gestel het. Ons kan dit simuleer deur 'n PRT vir die gebruiker aan te vra via ROADtools:
```bash
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
```
Dit lewer 'n `.prt` lêer op wat die gedeeltelike TGT en sessiesleutel bevat. As die rekening slegs 'n wolk-wagwoord was, sluit Azure AD steeds 'n TGT_AD in die PRT-antwoord in.

4.  **Ruil Gedeeltelike TGT vir Volledige TGT (op AD):** Die gedeeltelike TGT kan nou aan die on-prem Domeinbeheerder voorgelê word om 'n **volledige TGT** vir die teikenrekening te verkry. Ons doen dit deur 'n TGS-versoek vir die `krbtgt` diens (die domein se primêre TGT-diens) te doen -- essensieel om die kaartjie op te gradeer na 'n normale TGT met 'n volledige PAC. Gereedskap is beskikbaar om hierdie ruil te outomatiseer. Byvoorbeeld, deur ROADtools Hybrid se skrif te gebruik:
```bash
# 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
```
Hierdie skrip (of Impacket ekwivalente) sal die Domeinbeheerder kontak en 'n geldige TGT vir die teiken AD-rekening verkry, insluitend die NTLM-hash van die rekening as die spesiale Kerberos-uitbreiding gebruik word. Die **`KERB-KEY-LIST-REQ`** uitbreiding word outomaties ingesluit om die DC te vra om die teikenrekening se NTLM-hash in die versleutelde antwoord terug te stuur. Die resultaat is 'n geloofwaardigheid kas (`full_tgt.ccache`) vir die teikenrekening *of* die herwin NTLM-wagwoordhash.

5.  **Impersonate Target and Elevate to Domain Admin:** Nou beheer die aanvaller effektief die **teiken AD-rekening**. Byvoorbeeld, as die teiken die AD Connect **MSOL rekening** was, het dit replikasie regte op die gids. Die aanvaller kan 'n **DCSync** aanval uitvoer met daardie rekening se geloofsbriewe of Kerberos TGT om wagwoordhashes uit AD te dump (insluitend die domein KRBTGT rekening). Byvoorbeeld:
```bash
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
```
Dit dump al AD gebruikerswagwoord hashes, wat die aanvaller die KRBTGT hash gee (wat hulle in staat stel om domein Kerberos kaartjies na willekeur te vervals) en effektief **Domein Admin** regte oor AD. As die teikenrekening 'n ander bevoorregte gebruiker was, kon die aanvaller die volle TGT gebruik om enige domein hulpbron as daardie gebruiker te benader.

6.  **Skoonmaak:** Opsioneel kan die aanvaller die gemodifiseerde Azure AD gebruiker se oorspronklike `onPremisesSAMAccountName` en SID via dieselfde API herstel of eenvoudig enige tydelike gebruiker wat geskep is, verwyder. In baie gevalle sal die volgende Azure AD Connect sink siklus outomaties ongeoorloofde veranderinge op gesinkroniseerde eienskappe terugdra. (Tog, teen hierdie punt is die skade gedoen -- die aanvaller het DA regte.)

> [!WARNING]
> Deur die wolkvertroue en sinkmeganisme te misbruik, kan 'n Global Admin van Azure AD byna *enige* AD rekening naboots wat nie eksplisiet deur die RODC-beleid beskerm word nie, selfs al is daardie rekening nooit wolk-gesinkroniseer nie. In 'n standaardkonfigurasie, **verbind dit 'n volledige vertroue van Azure AD kompromie na on-prem AD kompromie**.


## References

- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)



{{#include ../../../banners/hacktricks-training.md}}
