Az - Cloud Kerberos Trust
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ten post jest podsumowaniem https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ który można sprawdzić w celu uzyskania dalszych informacji na temat ataku. Ta technika jest również omówiona w https://www.youtube.com/watch?v=AFay_58QubY.
Gdy zaufanie jest ustanowione z Azure AD, tworzony jest kontroler domeny tylko do odczytu (RODC) w AD. Konto komputera RODC, nazwane AzureADKerberos$
. Ponadto, drugie konto krbtgt
nazwane krbtgt_AzureAD
. To konto zawiera klucze Kerberos używane do biletów, które tworzy Azure AD.
Dlatego, jeśli to konto zostanie skompromitowane, możliwe byłoby podszywanie się pod dowolnego użytkownika... chociaż to nie jest prawda, ponieważ to konto jest zapobiegane w tworzeniu biletów dla jakiejkolwiek wspólnej uprzywilejowanej grupy AD, takiej jak Administratorzy Domeny, Administratorzy Enterprise, Administratorzy...
Jednak w rzeczywistym scenariuszu będą uprzywilejowani użytkownicy, którzy nie są w tych grupach. Tak więc nowe konto krbtgt, jeśli zostanie skompromitowane, mogłoby być użyte do podszywania się pod nich.
Ponadto, gdy użytkownik uwierzytelnia się w systemie Windows, używając tożsamości hybrydowej, Azure AD wyda częściowy bilet Kerberos wraz z PRT. TGT jest częściowy, ponieważ AzureAD ma ograniczone informacje o użytkowniku w lokalnym AD (takie jak identyfikator zabezpieczeń (SID) i nazwa).
Windows może następnie wymienić ten częściowy TGT na pełne TGT, żądając biletu usługi dla usługi krbtgt
.
Ponieważ mogą istnieć usługi, które nie obsługują uwierzytelniania Kerberos, ale NTLM, możliwe jest zażądanie częściowego TGT podpisanego przy użyciu drugiego klucza krbtgt
, w tym pola KERB-KEY-LIST-REQ
w części PADATA żądania, a następnie uzyskanie pełnego TGT podpisanego kluczem głównym krbtgt
, w tym hasz NT w odpowiedzi.
Gdy AzureAD generuje częściowe TGT, będzie używać szczegółów, które ma o użytkowniku. Dlatego, jeśli Globalny Administrator mógłby zmodyfikować dane, takie jak identyfikator zabezpieczeń i nazwa użytkownika w AzureAD, podczas żądania TGT dla tego użytkownika identyfikator zabezpieczeń byłby inny.
Nie jest możliwe zrobienie tego przez Microsoft Graph lub Azure AD Graph, ale możliwe jest użycie API, które używa Active Directory Connect do tworzenia i aktualizowania synchronizowanych użytkowników, co może być użyte przez Globalnych Administratorów do zmiany nazwy SAM i SID dowolnego użytkownika hybrydowego, a następnie, jeśli się uwierzytelniamy, otrzymujemy częściowe TGT zawierające zmodyfikowany SID.
Zauważ, że możemy to zrobić z AADInternals i zaktualizować synchronizowanych użytkowników za pomocą polecenia Set-AADIntAzureADObject.
Sukces ataku i uzyskanie uprawnień administratora domeny zależy od spełnienia określonych wymagań wstępnych:
Zdolność do zmiany kont za pomocą API Synchronizacji jest kluczowa. Można to osiągnąć, mając rolę Globalnego Administratora lub posiadając konto synchronizacji AD Connect. Alternatywnie, rola Administratora Tożsamości Hybrydowej byłaby wystarczająca, ponieważ daje możliwość zarządzania AD Connect i tworzenia nowych kont synchronizacji.
Obecność konta hybrydowego jest niezbędna. To konto musi być podatne na modyfikację danymi ofiary i powinno być również dostępne do uwierzytelnienia.
Identyfikacja docelowego konta ofiary w Active Directory jest koniecznością. Chociaż atak można przeprowadzić na dowolnym koncie już zsynchronizowanym, tenant Azure AD nie może mieć zreplikowanych identyfikatorów zabezpieczeń lokalnych, co wymaga modyfikacji konta niesynchronizowanego, aby uzyskać bilet.
Dodatkowo, to konto powinno posiadać uprawnienia równoważne administratorowi domeny, ale nie powinno być członkiem typowych grup administratorów AD, aby uniknąć generowania nieprawidłowych TGT przez RODC AzureAD.
Najlepszym celem jest konto Active Directory używane przez usługę synchronizacji AD Connect. To konto nie jest synchronizowane z Azure AD, co czyni jego SID odpowiednim celem, a z racji swojej roli w synchronizacji haszy haseł (zakładając, że synchronizacja haszy haseł jest aktywna) ma z natury uprawnienia równoważne administratorowi domeny. W przypadku domen z ekspresową instalacją, to konto jest poprzedzone MSOL_. W innych przypadkach konto można zidentyfikować, enumerując wszystkie konta obdarzone uprawnieniami replikacji katalogu na obiekcie domeny.
Sprawdź to w oryginalnym poście: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)