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
Gdy 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 drugie konto krbtgt o nazwie krbtgt_AzureAD. To konto zawiera klucze Kerberos używane do tworzenia biletów, które tworzy Azure AD.
Dlatego, jeśli to konto zostanie skompromitowane, możliwe będzie podszywanie się pod dowolnego użytkownika... choć nie jest to prawdą, ponieważ to konto jest zabezpieczone przed tworzeniem biletów dla jakiejkolwiek zwykłej uprzywilejowanej grupy AD, takiej jak Domain Admins, Enterprise Admins, Administrators...
Jednak w rzeczywistym scenariuszu będą istnieć uprzywilejowani użytkownicy, którzy nie należą do tych grup. Dlatego nowe konto krbtgt, jeśli zostanie skompromitowane, może być używane do podszywania się pod nich.
Kerberos TGT
Ponadto, gdy użytkownik uwierzytelnia się w systemie Windows przy użyciu hybrydowego tożsamości Azure AD, Azure AD wydaje 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).
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 przy użyciu drugiego klucza krbtgt, zawierającego pole KERB-KEY-LIST-REQ w części PADATA żądania, a następnie uzyskanie pełnego TGT podpisanego przy użyciu głównego klucza krbtgt, zawierającego skrót NT w odpowiedzi.
Wykorzystanie zaufania Cloud Kerberos do uzyskania uprawnień Domain Admin
Gdy AzureAD generuje częściowy TGT, używa informacji, które posiada o użytkowniku. Dlatego, jeśli Global Admin może zmodyfikować dane takie jak identyfikator zabezpieczeń i nazwa użytkownika w AzureAD, podczas żądania TGT dla tego użytkownika identyfikator zabezpieczeń będzie inny.
Nie jest to możliwe za pomocą Microsoft Graph ani Azure AD Graph, ale można to zrobić za pomocą API Active Directory Connect, które używa Global Admins do tworzenia i aktualizowania zsynchronizowanych użytkowników, co pozwala na modyfikację nazwy SAM i SID dowolnego hybrydowego użytkownika, a następnie, jeśli uwierzytelnimy się, otrzymamy częściowy TGT zawierający zmodyfikowany SID.
Należy zauważyć, że można to zrobić za pomocą narzędzia AADInternals i aktualizacji zsynchronizowanych 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:
Kluczowe jest posiadanie możliwości modyfikacji kont za pomocą interfejsu API synchronizacji. Można to osiągnąć, posiadając rolę Global Admin lub posiadając konto synchronizacji AD Connect. Alternatywnie, wystarczy mieć rolę Hybrid Identity Administrator, która umożliwia zarządzanie AD Connect i tworzenie nowych kont synchronizacji.
Istotne jest posiadanie konta hybrydowego. To konto musi być podatne na modyfikację z wykorzystaniem danych konta ofiary i powinno być również dostępne do uwierzytelniania.
Konieczne jest zidentyfikowanie docelowego konta ofiary w Active Directory. Chociaż atak można przeprowadzić na dowolnym już zsynchronizowanym koncie, dzierżawca Azure AD nie może mieć zreplikowanych identyfikatorów zabezpieczeń z lokalnego AD, co wymaga modyfikacji niesynchronizowanego konta w celu uzyskania biletu.
Ponadto, to konto powinno posiadać uprawnienia równoważne uprawnieniom Domain Admin, ale nie powinno być członkiem typowych grup administratorów AD, aby uniknąć generowania nieprawidłowych TGT przez AzureAD RODC.
Najodpowiedniejszym 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 celowym, a samo konto posiada uprawnienia równoważne uprawnieniom Domain Admin ze względu na swoją rolę w synchronizacji skrótów haseł (o ile aktywna jest synchronizacja skrótów haseł). Dla domen z instalacją express, to konto ma prefiks MSOL_. W innych przypadkach, konto można zlokalizować, wyliczając wszystkie konta posiadające uprawnienia replikacji katalogowej dla obiektu domeny.
Pełny atak </
Last updated