Az - Cloud Kerberos Trust
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.
Basiese Inligting
Vertroue
Wanneer 'n vertroue met Azure AD tot stand gebring word, word 'n Read Only Domain Controller (RODC) in die AD geskep. Die RODC-rekenaarrekening, genaamd AzureADKerberos$. Daarbenewens word 'n sekondêre krbtgt-rekening genaamd krbtgt_AzureAD geskep. Hierdie rekening bevat die Kerberos-sleutels wat gebruik word vir kaartjies wat Azure AD skep.
Daarom, as hierdie rekening gekompromitteer word, kan dit moontlik wees om enige gebruiker voor te gee... alhoewel dit nie waar is nie, omdat hierdie rekening verhoed word om kaartjies vir enige algemene bevoorregte AD-groep soos Domain Admins, Enterprise Admins, Administrators... te skep.
Nietemin, in 'n werklike scenario gaan daar bevoorregte gebruikers wees wat nie in daardie groepe is nie. Dus kan die nuwe krbtgt-rekening, as dit gekompromitteer word, gebruik word om hulle voor te gee.
Kerberos TGT
Verder, wanneer 'n gebruiker op Windows geverifieer word deur 'n hibriede identiteit Azure AD, sal dit 'n gedeeltelike Kerberos-kaartjie saam met die PRT uitreik. Die TGT is gedeeltelik omdat AzureAD beperkte inligting van die gebruiker in die plaaslike AD het (soos die sekuriteitsidentifiseerder (SID) en die naam).
Windows kan hierdie gedeeltelike TGT dan ruil vir 'n volledige TGT deur 'n dienskaartjie vir die krbtgt-diens aan te vra.
NTLM
Aangesien daar dienste kan wees wat nie Kerberos-verifikasie ondersteun nie, maar NTLM, is dit moontlik om 'n gedeeltelike TGT aan te vra wat onderteken is met 'n sekondêre krbtgt-sleutel wat die KERB-KEY-LIST-REQ-veld in die PADATA-gedeelte van die versoek insluit, en dan 'n volledige TGT te kry wat onderteken is met die primêre krbtgt-sleutel wat die NT-hash in die antwoord insluit.
Misbruik van Wolkkuberberos-Vertroue om Domein Admin te verkry
Wanneer AzureAD 'n gedeeltelike TGT genereer, sal dit die besonderhede wat dit oor die gebruiker het, gebruik. Daarom, as 'n Globale Admin data soos die sekuriteitsidentifiseerder en naam van die gebruiker in AzureAD kan wysig, sal die sekuriteitsidentifiseerder 'n ander een wees wanneer 'n TGT vir daardie gebruiker aangevra word.
Dit is nie moontlik om dit te doen deur die Microsoft Graph of die Azure AD Graph nie, maar dit is moontlik om die API Active Directory Connect te gebruik wat deur die Globale Admins gebruik word om gesinkroniseerde gebruikers te skep en op te dateer, wat gebruik kan word om die SAM-naam en SID van enige hibriede gebruiker te wysig, en dan as ons geverifieer word, 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.
Aanvalsvoorvereistes
Die sukses van die aanval en die verkryging van Domein Admin-voorregte hang af van die nakoming van sekere voorvereistes:
Die vermoë om rekeninge te wysig via die Synchronisatie-API is van kritieke belang. Dit kan bereik word deur die rol van Globale Admin te hê of in besit te wees van 'n AD Connect-sinkronisasie-rekening. Alternatiewelik sal die rol van die Hibriede Identiteit-administrateur voldoende wees, aangesien dit die vermoë gee om AD Connect te bestuur en nuwe sinkronisasie-rekeninge te skep.
Teenwoordigheid van 'n hibriede rekening is noodsaaklik. Hierdie rekening moet vatbaar wees vir wysiging met die besonderhede van die slagofferrekening en moet ook toeganklik wees vir verifikasie.
Identifikasie van 'n teikenslagofferrekening binne die Aktiewe Gids is 'n noodsaaklikheid. Alhoewel die aanval op enige rekening wat reeds gesinkroniseer is, uitgevoer kan word, mag die Azure AD-huurder nie plaaslike sekuriteitsidentifiseerders gerepliseer hê nie, wat die wysiging van 'n nie-gesinkroniseerde rekening vereis om die kaartjie te bekom.
Hierbenewens moet hierdie rekening domein-admin-ekwivalente voorregte hê, maar nie 'n lid van tipiese AD-administratorsgroepe wees nie om die skepping van ongeldige TGT's deur die AzureAD RODC te voorkom.
Die mees geskikte teiken is die Aktiewe Gids-rekening wat deur die AD Connect Sync-diens gebruik word. Hierdie rekening word nie met Azure AD gesinkroniseer nie, wat sy SID as 'n lewensvatbare teiken laat, en dit besit inherent Domein Admin-ekwivalente voorregte as gevolg van sy rol in die sinkronisering van wagwoordhasings (onder die aanname dat Wagwoordhas-sinkronisasie aktief is). Vir domeine met uitdruklike installasie, word hierdie rekening voorafgegaan deur MSOL_. Vir ander gevalle kan die rekening geïdentifiseer word deur alle rekeninge op te som wat toeger
Last updated