Az - Cloud Kerberos Trust

{{#include ../../../../banners/hacktricks-training.md}}

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.

Przegląd relacji zaufania Kerberos

Cloud Kerberos Trust (Entra ID -> AD) – Ta funkcja (część Windows Hello for Business) ustanawia jednostronne zaufanie, w którym lokalne AD ufa Entra ID w wydawaniu biletów Kerberos dla AD. Włączenie tej funkcji tworzy obiekt komputera AzureADKerberos$ w AD (pojawiający się jako kontroler domeny tylko do odczytu) oraz powiązane konto krbtgt_AzureAD (drugorzędny KRBTGT). Entra ID przechowuje klucze dla tych kont i może wydawać “częściowe” TGT Kerberos dla użytkowników AD. Kontrolery domeny AD będą honorować te bilety, ale z ograniczeniami podobnymi do RODC: domyślnie grupy o wysokich uprawnieniach (Domain Admins, Enterprise Admins itp.) są odrzucane, a zwykli użytkownicy są dozwoleni. To uniemożliwia Entra ID uwierzytelnianie administratorów domeny za pośrednictwem zaufania w normalnych warunkach. Jednak, jak zobaczymy, atakujący z wystarczającymi uprawnieniami Entra ID może nadużyć ten projekt zaufania.

Przechodzenie z Entra ID do lokalnego AD

Scenariusz: Docelowa organizacja ma włączone Cloud Kerberos Trust dla uwierzytelniania bezhasłowego. Atakujący uzyskał uprawnienia Global Administrator w Entra ID (Azure AD), ale jeszcze nie kontroluje lokalnego AD. Atakujący ma również dostęp do kontrolera domeny (poprzez VPN lub maszynę wirtualną Azure w sieci hybrydowej). Wykorzystując zaufanie w chmurze, atakujący może wykorzystać kontrolę Azure AD, aby uzyskać dostęp na poziomie Domain Admin w AD.

Wymagania wstępne:

  • Cloud Kerberos Trust jest skonfigurowane w środowisku hybrydowym (wskaźnik: konto AzureADKerberos$ RODC istnieje w AD).

  • Atakujący ma prawa Global Admin (lub Hybrid Identity Admin) w tenant Entra ID (te role mogą używać API synchronizacji AD Connect do modyfikacji użytkowników Azure AD).

  • Co najmniej jedno konto użytkownika hybrydowego (istnieje zarówno w AD, jak i AAD), jako którym atakujący może się uwierzytelnić. Można je uzyskać, znając lub resetując jego dane uwierzytelniające lub przypisując metodę bezhasłową (np. Temporary Access Pass), aby wygenerować Primary Refresh Token (PRT) dla niego.

  • Konto docelowe on-prem AD z wysokimi uprawnieniami, które nie znajduje się w domyślnej polityce “deny” RODC. W praktyce doskonałym celem jest konto synchronizacji AD Connect (często nazywane MSOL_*), które ma prawa DCSync (replikacji) w AD, ale zazwyczaj nie jest członkiem wbudowanych grup administracyjnych. To konto zazwyczaj nie jest synchronizowane z Entra ID, co sprawia, że jego SID jest dostępny do podszywania się bez konfliktu.

Kroki ataku:

  1. Uzyskaj dostęp do API synchronizacji Azure AD: Używając konta Global Admin, zdobądź token dostępu do API Provisioning (sync) Azure AD. Można to zrobić za pomocą narzędzi takich jak ROADtools lub AADInternals. Na przykład, z ROADtools (roadtx):
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Alternatywnie, Connect-AADInt AADInternals może być użyty do uwierzytelnienia jako Global Admin.)

  1. Zmodyfikuj atrybuty użytkownika hybrydowego w on-prem: Wykorzystaj Azure AD synchronization API, aby ustawić wybranego użytkownika hybrydowego onPremises Security Identifier (SID) i onPremises SAMAccountName, aby odpowiadały docelowemu kontu AD. To skutecznie informuje Azure AD, że użytkownik w chmurze odpowiada kontu on-prem, które chcemy udawać. Używając otwartoźródłowego zestawu narzędzi ROADtools Hybrid:
# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>

sourceAnchor (niemutowalny identyfikator) użytkownika jest potrzebny do zidentyfikowania obiektu Azure AD, który ma być zmodyfikowany. Narzędzie ustawia lokalny SID użytkownika hybrydowego i nazwę konta SAM na wartości docelowe (np. SID i SAM konta MSOL_xxxx). Azure AD normalnie zabrania zmiany tych atrybutów za pomocą Graph (są one tylko do odczytu), ale API usługi synchronizacji na to pozwala, a Global Admins mogą wywołać tę funkcjonalność synchronizacji.

  1. Uzyskaj częściowy TGT z Azure AD: Po modyfikacji, uwierzytelnij się jako użytkownik hybrydowy w Azure AD (na przykład, uzyskując PRT na urządzeniu lub używając ich poświadczeń). Gdy użytkownik loguje się (szczególnie na urządzeniu z dołączonym do domeny lub dołączonym do Entra systemem Windows), Azure AD wyda częściowy Kerberos TGT (TGTAD) dla tego konta, ponieważ zaufanie do Kerberos w chmurze jest włączone. Ten częściowy TGT jest szyfrowany kluczem AzureADKerberos$ RODC i zawiera docelowy SID, który ustawiliśmy. Możemy to zasymulować, żądając PRT dla użytkownika za pomocą ROADtools:
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

To jest plik .prt, który zawiera częściowy TGT i klucz sesji. Jeśli konto miało tylko hasło w chmurze, Azure AD nadal zawiera TGT_AD w odpowiedzi PRT.

  1. Wymiana częściowego TGT na pełne TGT (w AD): Częściowy TGT można teraz przedstawić lokalnemu kontrolerowi domeny, aby uzyskać pełne TGT dla docelowego konta. Robimy to, wykonując żądanie TGS dla usługi krbtgt (głównej usługi TGT domeny) – zasadniczo aktualizując bilet do normalnego TGT z pełnym PAC. Narzędzia są dostępne, aby zautomatyzować tę wymianę. Na przykład, używając skryptu ROADtools Hybrid:
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash

Ten skrypt (lub jego odpowiedniki w Impacket) skontaktuje się z kontrolerem domeny i pobierze ważny TGT dla docelowego konta AD, w tym hasz NTLM konta, jeśli używana jest specjalna rozszerzenie Kerberos. Rozszerzenie KERB-KEY-LIST-REQ jest automatycznie dołączane, aby poprosić DC o zwrócenie hasza NTLM docelowego konta w zaszyfrowanej odpowiedzi. Wynikiem jest pamięć podręczna poświadczeń (full_tgt.ccache) dla docelowego konta lub odzyskany hasz hasła NTLM.

  1. Impersonacja celu i podniesienie uprawnień do administratora domeny: Teraz atakujący efektywnie kontroluje docelowe konto AD. Na przykład, jeśli celem było konto AD Connect MSOL, ma ono prawa replikacji w katalogu. Atakujący może przeprowadzić atak DCSync używając poświadczeń tego konta lub Kerberos TGT, aby zrzucić hasze haseł z AD (w tym konto domeny KRBTGT). Na przykład:
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

To jest zrzut wszystkich hashy haseł użytkowników AD, dając atakującemu hash KRBTGT (pozwalając im na fałszowanie biletów Kerberos w domenie według uznania) i efektywnie uprawnienia administratora domeny w AD. Jeśli docelowe konto byłoby innym uprzywilejowanym użytkownikiem, atakujący mógłby użyć pełnego TGT, aby uzyskać dostęp do dowolnego zasobu domeny jako ten użytkownik.

  1. Czyszczenie: Opcjonalnie, atakujący może przywrócić oryginalne onPremisesSAMAccountName i SID zmodyfikowanego użytkownika Azure AD za pomocą tego samego interfejsu API lub po prostu usunąć wszelkich tymczasowych użytkowników utworzonych. W wielu przypadkach następny cykl synchronizacji Azure AD Connect automatycznie przywróci nieautoryzowane zmiany w zsynchronizowanych atrybutach. (Jednak w tym momencie szkody są już wyrządzone – atakujący ma uprawnienia DA.)

Warning

Wykorzystując zaufanie chmurowe i mechanizm synchronizacji, Global Admin Azure AD może podszyć się pod niemal dowolne konto AD, które nie jest wyraźnie chronione przez politykę RODC, nawet jeśli to konto nigdy nie było synchronizowane z chmurą. W domyślnej konfiguracji, to tworzy pełne zaufanie od kompromitacji Azure AD do kompromitacji lokalnego AD.

References

{{#include ../../../../banners/hacktricks-training.md}}