Az - Cloud Kerberos Trust
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Hierdie pos is 'n opsomming van 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.
Wanneer 'n vertroue met Azure AD gevestig word, 'n Read Only Domain Controller (RODC) word in die AD geskep. Die RODC rekenaarrekening, genaamd AzureADKerberos$
. Ook, 'n sekondêre krbtgt
rekening genaamd krbtgt_AzureAD
. Hierdie rekening bevat die Kerberos sleutels wat gebruik word vir kaartjies wat Azure AD skep.
Daarom, as hierdie rekening gecompromitteer word, kan dit moontlik wees om enige gebruiker na te boots... alhoewel dit nie waar is nie omdat hierdie rekening verhinder word om kaartjies vir enige algemene bevoorregte AD-groep soos Domain Admins, Enterprise Admins, Administrators... te skep.
Egter, in 'n werklike scenario gaan daar bevoorregte gebruikers wees wat nie in daardie groepe is nie. So die nuwe krbtgt rekening, as gecompromitteer, kan gebruik word om hulle na te boots.
Boonop, wanneer 'n gebruiker op Windows outentiseer met 'n hibriede identiteit, sal Azure AD 'n gedeeltelike Kerberos kaartjie saam met die PRT uitreik. Die TGT is gedeeltelik omdat AzureAD beperkte inligting van die gebruiker in die on-prem AD het (soos die sekuriteitsidentifiseerder (SID) en die naam).
Windows kan dan hierdie gedeeltelike TGT vir 'n volle TGT ruil deur 'n dienskaartjie vir die krbtgt
diens aan te vra.
Aangesien daar dienste kan wees wat nie Kerberos outentisering ondersteun nie maar NTLM, is dit moontlik om 'n gedeeltelike TGT te vra wat met 'n sekondêre krbtgt
sleutel onderteken is, insluitend die KERB-KEY-LIST-REQ
veld in die PADATA deel van die versoek en dan 'n volle TGT te kry wat met die primêre krbtgt
sleutel onderteken is wat die NT-hash in die antwoord insluit.
Wanneer AzureAD 'n gedeeltelike TGT genereer, sal dit die besonderhede wat dit oor die gebruiker het, gebruik. Daarom, as 'n Global Admin data soos die sekuriteitsidentifiseerder en naam van die gebruiker in AzureAD kan wysig, wanneer 'n TGT vir daardie gebruiker aangevra word, sal die sekuriteitsidentifiseerder 'n ander een wees.
Dit is nie moontlik om dit deur die Microsoft Graph of die Azure AD Graph te doen nie, maar dit is moontlik om die API Active Directory Connect te gebruik wat gebruik word om gesinkroniseerde gebruikers te skep en op te dateer, wat deur die Global Admins gebruik kan word om die SAM naam en SID van enige hibriede gebruiker te wysig, en dan as ons outentiseer, kry ons 'n gedeeltelike TGT wat die gewysigde SID bevat.
Let daarop dat ons dit met AADInternals kan doen en gesinkroniseerde gebruikers kan opdateer via die Set-AADIntAzureADObject cmdlet.
Die sukses van die aanval en verkryging van Domain Admin voorregte hang af van die nakoming van sekere vereistes:
Die vermoë om rekeninge via die Synchronization API te verander is van kardinale belang. Dit kan bereik word deur die rol van Global Admin te hê of 'n AD Connect sink rekening te besit. Alternatiewelik, die Hybrid Identity Administrator rol sal voldoende wees, aangesien dit die vermoë bied om AD Connect te bestuur en nuwe sink rekeninge te vestig.
Teenwoordigheid van 'n hibriede rekening is noodsaaklik. Hierdie rekening moet ontvanklik wees vir wysiging met die slagoffer rekening se besonderhede en moet ook toeganklik wees vir outentisering.
Identifikasie van 'n teiken slagoffer rekening binne Active Directory is 'n noodsaaklikheid. Alhoewel die aanval op enige rekening wat reeds gesinkroniseer is, uitgevoer kan word, moet die Azure AD tenant nie on-premises sekuriteitsidentifiseerders gerepliceer het nie, wat die wysiging van 'n nie-gesinkroniseerde rekening vereis om die kaartjie te verkry.
Boonop moet hierdie rekening domein admin gelyke voorregte hê, maar mag nie 'n lid van tipiese AD administrateur groepe wees nie om die generasie van ongeldige TGTs deur die AzureAD RODC te vermy.
Die mees geskikte teiken is die Active Directory rekening wat deur die AD Connect Sync diens gebruik word. Hierdie rekening is nie gesinkroniseer met Azure AD nie, wat sy SID as 'n lewensvatbare teiken laat, en dit het inherent Domein Admin gelyke voorregte as gevolg van sy rol in die sinkronisering van wagwoord hashes (aangesien Password Hash Sync aktief is). Vir domeine met uitdruklike installasie, word hierdie rekening voorafgegaan met MSOL_. Vir ander gevalle kan die rekening geïdentifiseer word deur alle rekeninge met Directory Replication voorregte op die domein objek te tel.
Kyk dit in die oorspronklike pos: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)