Az - Cloud Kerberos Trust
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.
Podstawowe informacje
Zaufanie
Gdy zaufanie jest ustanowione z Azure AD, tworzony jest Read Only Domain Controller (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 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.
Kerberos TGT
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.
NTLM
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 hasha NT w odpowiedzi.
Wykorzystywanie zaufania Cloud Kerberos do uzyskania uprawnień Domain Admin
Gdy AzureAD generuje częściowe TGT, będzie używać szczegółów, 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 aktualizacji 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.
Wymagania wstępne ataku
Sukces ataku i uzyskanie uprawnień Domain Admin zależy od spełnienia pewnych wymagań wstępnych:
Zdolność do zmiany kont za pomocą API Synchronizacji jest kluczowa. Można to osiągnąć, mając rolę Global Admin 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 ustanawiania 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 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. Dla 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.
Pełny atak
Sprawdź to w oryginalnym poście: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated
