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óre 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 Read Only Domain Controller (RODC) w AD. Konto komputera RODC nosi nazwę AzureADKerberos$. Ponadto, istnieje drugie konto krbtgt o nazwie 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 Domain Admins, Enterprise Admins, Administrators...
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, korzystając z 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 za pomocą drugiego klucza krbtgt, w tym pola KERB-KEY-LIST-REQ w części PADATA żądania, a następnie uzyskanie pełnego TGT podpisanego głównym kluczem krbtgt, w tym hasha NT w odpowiedzi.
Gdy AzureAD generuje częściowe TGT, będzie korzystać z danych, które ma o użytkowniku. Dlatego, jeśli Global Admin 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 Global Adminó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ń Domain Admin zależy od spełnienia pewnych wymagań wstępnych:
Zdolność do zmiany kont za pomocą Synchronization API jest kluczowa. Można to osiągnąć, mając rolę Global Admin lub posiadając konto synchronizacji AD Connect. Alternatywnie, rola Hybrid Identity Administrator byłaby wystarczająca, ponieważ daje możliwość zarządzania AD Connect i ustanawiania nowych kont synchronizacji.
Obecność konta hybrydowego jest niezbędna. To konto musi być podatne na modyfikację danymi konta 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 lokalnych identyfikatorów zabezpieczeń, co wymaga modyfikacji niesynchronizowanego konta w celu uzyskania biletu.
Dodatkowo, to konto powinno posiadać uprawnienia równoważne uprawnieniom administratora domeny, ale nie powinno być członkiem typowych grup administratorów AD, aby uniknąć generowania nieprawidłowych TGT przez AzureAD RODC.
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 hashy haseł (zakładając, że synchronizacja hashy haseł jest aktywna) ma z natury uprawnienia równoważne uprawnieniom Domain Admin. W przypadku domen z ekspresową instalacją, to konto jest poprzedzone MSOL_. W innych przypadkach konto można zidentyfikować, enumerując wszystkie konta obdarzone uprawnieniami do 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)
