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ć, aby uzyskać więcej informacji na temat ataku. Ta technika jest również omówiona w https://www.youtube.com/watch?v=AFay_58QubY.
Podstawowe informacje
Zaufanie
Kiedy nawiązywane jest zaufanie z Azure AD, w AD tworzony jest Read Only Domain Controller (RODC). Konto komputera RODC nosi nazwę AzureADKerberos$. Dodatkowo tworzone jest drugorzędne 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ż nie jest to prawdą, ponieważ to konto jest zabezpieczone przed tworzeniem biletów dla jakiejkolwiek powszechnej uprzywilejowanej grupy AD, takiej jak Administratorzy domeny, Administratorzy przedsiębiorstwa, Administratorzy...
Jednakże, w rzeczywistym scenariuszu będą uprzywilejowani użytkownicy, którzy nie należą do tych grup. Dlatego nowe konto krbtgt, jeśli zostanie skompromitowane, może być użyte do podszywania się pod nich.
Kerberos TGT
Ponadto, gdy użytkownik uwierzytelnia się w systemie Windows przy użyciu hybrydowej tożsamości Azure AD, Azure AD wyda częściowy bilet Kerberos wraz z PRT. TGT jest częściowy, ponieważ AzureAD ma ograniczoną wiedzę o użytkowniku w lokalnym AD (taką jak identyfikator zabezpieczeń (SID) i nazwa).
System Windows może następnie wymienić ten częściowy TGT na pełny 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 żądanie częściowego TGT podpisanego za pomocą drugorzędnego krbtgt klucza, włączając pole KERB-KEY-LIST-REQ w części PADATA żądania, a następnie uzyskanie pełnego TGT podpisanego kluczem głównym krbtgt zawierającego skrót NT w odpowiedzi.
Nadużywanie Zaufania Kerberos w Chmurze w celu uzyskania Administratora domeny
Kiedy AzureAD generuje częściowy TGT, używa szczegółów, jakie posiada 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 to możliwe za pomocą Microsoft Graph ani Azure AD Graph, ale można użyć API, którego używa Active Directory Connect do tworzenia i aktualizacji zsynchronizowanych użytkowników, co może być wykorzystane przez Globalnych Administratorów do modyfikacji nazwy SAM i SID dowolnego hybrydowego użytkownika, a następnie, jeśli się uwierzytelnią, otrzymają częściowy TGT zawierający zmodyfikowany SID.
Zauważ, że można to zrobić za pomocą AADInternals i zaktualizować zsynchronizowanych użytkowników za pomocą polecenia Set-AADIntAzureADObject.
Wymagania ataku
Sukces ataku i uzyskanie uprawnień Administratora domeny zależy od spełnienia określonych wymagań wstępnych:
Istotne jest posiadanie zdolności modyfikowania kont za pomocą interfejsu API synchronizacji. Można to osiągnąć, mając rolę Globalnego Administratora lub posiadając konto synchronizacji AD Connect. Alternatywnie wystarczyłaby rola Administratora Hybrydowej Tożsamości, ponieważ umożliwia zarządzanie AD Connect i tworzenie nowych kont synchronizacji.
Istnienie konta hybrydowego jest niezbędne. To konto musi być podatne na modyfikację z danymi konta ofiary i powinno być dostępne do uwierzytelniania.
Konieczne jest zidentyfikowanie konta ofiary docelowej w Active Directory. Chociaż atak można przeprowadzić na dowolnym już zsynchronizowanym koncie, najemnik Azure AD nie może mieć zreplikowanych identyfikatorów zabezpieczeń z lokalnych systemów, co wymaga modyfikacji niesynchronizowanego konta w celu uzyskania biletu.
Ponadto, 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 AzureAD RODC.
Najbardziej odpowiednim celem jest konto Active Directory używane przez usługę synchronizacji AD Connect. To konto nie jest zsynchronizowane z Azure AD, co pozostawia jego SID jako cel, a z natury posiada uprawnienia równoważne Administratorowi domeny ze względu na rolę w synchronizacji skrótów haseł (przy założeniu, że synchronizacja skrótów haseł jest aktywna). Dla domen z instalacją express, to konto jest poprzedzone MSOL_. W innych przypadkach konto można zlokalizować, wyliczając wszystkie konta obdarzone uprawnieniami replikacji katalogowej 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
