Az - Cloud Kerberos Trust

Reading time: 8 minutes

Huu ni muhtasari wa https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ ambayo inaweza kuangaliwa kwa maelezo zaidi kuhusu shambulio. Mbinu hii pia imejadiliwa katika https://www.youtube.com/watch?v=AFay_58QubY.

Muhtasari wa Uhusiano wa Kerberos Trust

Cloud Kerberos Trust (Entra ID -> AD) -- Kipengele hiki (sehemu ya Windows Hello for Business) kinaanzisha uaminifu wa upande mmoja ambapo AD ya ndani inaamini Entra ID kutoa tiketi za Kerberos kwa AD. Kuwawezesha kunaunda kitu cha kompyuta AzureADKerberos$ katika AD (kinachonekana kama Kidhibiti cha Kikoa cha Kusoma tu) na akaunti iliyounganishwa krbtgt_AzureAD (KRBTGT ya pili). Entra ID inashikilia funguo za akaunti hizi na inaweza kutoa "sehemu" za Kerberos TGT kwa watumiaji wa AD. Wajibu wa kudhibiti kikoa cha AD wataheshimu tiketi hizi, lakini kwa vizuizi kama vya RODC: kwa kawaida, makundi yenye mamlaka ya juu (Domain Admins, Enterprise Admins, nk.) yanakataliwa na watumiaji wa kawaida wanaruhusiwa. Hii inazuia Entra ID kuthibitisha wasimamizi wa kikoa kupitia uaminifu chini ya hali za kawaida. Hata hivyo, kama tutakavyoona, mshambuliaji mwenye mamlaka ya kutosha ya Entra ID anaweza kutumia muundo huu wa uaminifu.

Kuhamasisha kutoka Entra ID hadi On-Prem AD

Hali: Shirika lengwa lina Cloud Kerberos Trust iliyowezeshwa kwa uthibitisho usio na nenosiri. Mshambuliaji amepata mamlaka ya Global Administrator katika Entra ID (Azure AD) lakini bado hajadhibiti AD ya ndani. Mshambuliaji pia ana mguu na ufikiaji wa mtandao kwa Kidhibiti cha Kikoa (kupitia VPN au VM ya Azure katika mtandao wa mseto). Kwa kutumia uaminifu wa wingu, mshambuliaji anaweza kutumia udhibiti wa Azure AD kupata mguu wa kiwango cha Domain Admin katika AD.

Mahitaji:

• Cloud Kerberos Trust imewekwa katika mazingira ya mseto (kiashiria: akaunti ya AzureADKerberos$ RODC inapatikana katika AD).

• Mshambuliaji ana haki za Global Admin (au Hybrid Identity Admin) katika mpangilio wa Entra ID (majukumu haya yanaweza kutumia synchronization API ya AD Connect kubadilisha watumiaji wa Azure AD).

• Angalau akaunti moja ya mtumiaji wa mseto (inapatikana katika AD na AAD) ambayo mshambuliaji anaweza kuthibitisha kama. Hii inaweza kupatikana kwa kujua au kurekebisha akidi zake au kupewa njia isiyo na nenosiri (mfano, Pass ya Ufikiaji wa Muda) ili kuunda Tokeni ya Kurejesha Kwanza (PRT) kwa ajili yake.

• Akaunti ya lengo la AD ya ndani yenye mamlaka ya juu ambayo siyo katika sera ya "kukataa" ya RODC ya kawaida. Katika mazoezi, lengo bora ni akaunti ya AD Connect sync (mara nyingi inaitwa MSOL_*), ambayo ina haki za DCSync (kurudi) katika AD lakini kwa kawaida si mwanachama wa makundi ya usimamizi yaliyojengwa. Akaunti hii kwa kawaida haiunganishwi na Entra ID, na kufanya SID yake ipatikane kwa ajili ya kujifanya bila mgongano.

Hatua za Shambulio:

1. Pata Ufikiaji wa Azure AD sync API: Kwa kutumia akaunti ya Global Admin, pata tokeni ya ufikiaji kwa Azure AD Provisioning (sync) API. Hii inaweza kufanywa kwa kutumia zana kama ROADtools au AADInternals. Kwa mfano, kwa kutumia ROADtools (roadtx):

# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Badala yake, Connect-AADInt ya AADInternals inaweza kutumika kuthibitisha kama Global Admin.)

2. Badilisha Sifa za Mtumiaji wa Hybrid za On-Prem: Tumia Azure AD synchronization API kuweka onPremises Security Identifier (SID) na onPremises SAMAccountName za mtumiaji wa hybrid uliochaguliwa ili ziendane na akaunti ya AD inayolengwa. Hii kwa ufanisi inamwambia Azure AD kwamba mtumiaji wa wingu anahusiana na akaunti ya on-prem ambayo tunataka kuiga. Tumia zana za wazi za 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>

sourceAnchor (ID isiyobadilika) ya mtumiaji inahitajika ili kubaini kitu cha Azure AD kinachohitaji kubadilishwa. Chombo kinaweka SID ya mtumiaji wa hybrid na jina la akaunti ya SAM kwa thamani za lengo (kwa mfano, SID na SAM ya akaunti ya MSOL_xxxx). Azure AD kwa kawaida hairuhusu kubadilisha sifa hizi kupitia Graph (zinakuwa za kusoma tu), lakini API ya huduma ya usawazishaji inaruhusu na Wasimamizi wa Global wanaweza kuitumia kazi hii ya usawazishaji.

3. Pata TGT ya Sehemu kutoka Azure AD: Baada ya kubadilisha, thibitisha kama mtumiaji wa hybrid kwa Azure AD (kwa mfano, kwa kupata PRT kwenye kifaa au kutumia akidi zao). Wakati mtumiaji anapoingia (hasa kwenye kifaa kilichounganishwa na domain au kilichounganishwa na Entra), Azure AD itatoa TGT ya sehemu ya Kerberos (TGT_AD) kwa akaunti hiyo kwa sababu Cloud Kerberos Trust imewezeshwa. TGT hii ya sehemu imefungwa kwa funguo ya AzureADKerberos$ RODC na inajumuisha target SID tuliyoipanga. Tunaweza kuiga hii kwa kuomba PRT kwa mtumiaji kupitia ROADtools:

roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

Hii inatoa faili la .prt linalojumuisha TGT ya sehemu na ufunguo wa kikao. Ikiwa akaunti ilikuwa na nenosiri la wingu pekee, Azure AD bado inajumuisha TGT_AD katika jibu la PRT.

4. Badilisha TGT ya Sehemu kwa TGT Kamili (katika AD): TGT ya sehemu sasa inaweza kuwasilishwa kwa Kichapisho cha Kikoa cha ndani ili kupata TGT kamili kwa akaunti lengwa. Tunaifanya hii kwa kutekeleza ombi la TGS kwa huduma ya krbtgt (huduma kuu ya TGT ya kikoa) -- kimsingi kuboresha tiketi kuwa TGT ya kawaida yenye PAC kamili. Zana zinapatikana kujiandaa kubadilishana hii. Kwa mfano, kutumia skripti ya 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

Hii script (au sawa na Impacket) itawasiliana na Domain Controller na kupata TGT halali kwa akaunti ya AD ya lengo, ikiwa ni pamoja na NTLM hash ya akaunti ikiwa kiendelezi maalum cha Kerberos kinatumika. Kiendelezi cha KERB-KEY-LIST-REQ kinajumuishwa kiotomatiki ili kuomba DC irejeshe NTLM hash ya akaunti ya lengo katika jibu lililofichwa. Matokeo ni cache ya akidi (full_tgt.ccache) kwa akaunti ya lengo au NTLM password hash iliyopatikana.

5. Jifanya kama Lengo na Pandisha hadi Domain Admin: Sasa mshambuliaji kwa ufanisi anadhibiti akaunti ya AD ya lengo. Kwa mfano, ikiwa lengo lilikuwa akaunti ya AD Connect MSOL, ina haki za kuiga kwenye directory. Mshambuliaji anaweza kufanya shambulio la DCSync akitumia akidi za akaunti hiyo au Kerberos TGT ili kutupa password hashes kutoka AD (ikiwemo akaunti ya domain KRBTGT). Kwa mfano:

# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

Hii inatoa hash za nywila za watumiaji wote wa AD, ikimpa mshambuliaji hash ya KRBTGT (ikimruhusu kuunda tiketi za Kerberos za eneo kwa hiari) na kwa ufanisi Domain Admin haki juu ya AD. Ikiwa akaunti ya lengo ilikuwa mtumiaji mwingine mwenye mamlaka, mshambuliaji angeweza kutumia TGT kamili kupata rasilimali yoyote ya eneo kama mtumiaji huyo.

6. Usafishaji: Kwa hiari, mshambuliaji anaweza kurejesha onPremisesSAMAccountName na SID za mtumiaji wa Azure AD zilizobadilishwa kupitia API hiyo hiyo au kwa kuondoa tu mtumiaji wa muda aliyeundwa. Katika kesi nyingi, mzunguko ujao wa usawazishaji wa Azure AD Connect utaondoa kiotomatiki mabadiliko yasiyoruhusiwa kwenye sifa zilizounganishwa. (Hata hivyo, kwa hatua hii uharibifu umefanyika -- mshambuliaji ana haki za DA.)

References

• Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust