Az - Cloud Kerberos Trust

Reading time: 8 minutes

Dieser Beitrag ist eine Zusammenfassung von https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ , die für weitere Informationen über den Angriff konsultiert werden kann. Diese Technik wird auch in https://www.youtube.com/watch?v=AFay_58QubY** kommentiert.**

Kerberos-Vertrauensbeziehung Übersicht

Cloud Kerberos Trust (Entra ID -> AD) -- Diese Funktion (Teil von Windows Hello for Business) etabliert ein einseitiges Vertrauen, bei dem das lokale AD Entra ID vertraut, Kerberos-Tickets für AD auszustellen. Die Aktivierung erstellt ein AzureADKerberos$ Computerobjekt im AD (das als Read-Only Domain Controller erscheint) und ein verknüpftes krbtgt_AzureAD Konto (ein sekundärer KRBTGT). Entra ID hält die Schlüssel für diese Konten und kann "partielle" Kerberos TGTs für AD-Benutzer ausstellen. AD-Domänencontroller werden diese Tickets anerkennen, jedoch mit RODC-ähnlichen Einschränkungen: standardmäßig sind Hochprivilegierte Gruppen (Domain Admins, Enterprise Admins usw.) verweigert und gewöhnliche Benutzer sind erlaubt. Dies verhindert, dass Entra ID unter normalen Bedingungen Domänenadministratoren über das Vertrauen authentifiziert. Wie wir sehen werden, kann ein Angreifer mit ausreichenden Entra ID-Rechten dieses Vertrauensdesign ausnutzen.

Pivoting von Entra ID zu On-Prem AD

Szenario: Die Zielorganisation hat Cloud Kerberos Trust für passwortlose Authentifizierung aktiviert. Ein Angreifer hat Global Administrator-Rechte in Entra ID (Azure AD) erlangt, kontrolliert jedoch noch nicht das lokale AD. Der Angreifer hat auch einen Fuß in der Tür mit Netzwerkzugang zu einem Domänencontroller (über VPN oder eine Azure-VM im hybriden Netzwerk). Mithilfe des Cloud-Vertrauens kann der Angreifer die Kontrolle über Azure AD nutzen, um einen Domain Admin-Zugang im AD zu erlangen.

Voraussetzungen:

• Cloud Kerberos Trust ist in der hybriden Umgebung konfiguriert (Indikator: ein AzureADKerberos$ RODC-Konto existiert im AD).

• Der Angreifer hat Global Admin (oder Hybrid Identity Admin)-Rechte im Entra ID-Mandanten (diese Rollen können die AD Connect Synchronisations-API verwenden, um Azure AD-Benutzer zu ändern).

• Mindestens ein hybrides Benutzerkonto (existiert sowohl im AD als auch im AAD), bei dem sich der Angreifer authentifizieren kann. Dies könnte durch Kenntnis oder Zurücksetzen der Anmeldeinformationen oder durch Zuweisen einer passwortlosen Methode (z. B. eines Temporary Access Pass) zur Generierung eines Primary Refresh Token (PRT) für dieses Konto erlangt werden.

• Ein lokales AD-Zielkonto mit hohen Rechten, das nicht in der Standard-RODC-"verweigern"-Richtlinie enthalten ist. In der Praxis ist ein hervorragendes Ziel das AD Connect-Synchronisationskonto (oft als MSOL_* benannt), das DCSync (Replikations-)Rechte im AD hat, jedoch normalerweise kein Mitglied der integrierten Administrationsgruppen ist. Dieses Konto wird typischerweise nicht mit Entra ID synchronisiert, wodurch seine SID ohne Konflikt zur Identitätsübernahme verfügbar ist.

Angriffsschritte:

1. Zugriff auf die Azure AD-Synchronisations-API erhalten: Verwenden Sie das Global Admin-Konto, um ein Zugriffstoken für die Azure AD Provisioning (sync) API zu erwerben. Dies kann mit Tools wie ROADtools oder AADInternals erfolgen. Zum Beispiel mit ROADtools (roadtx):

# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Alternativ kann AADInternals' Connect-AADInt verwendet werden, um sich als Global Admin zu authentifizieren.)

2. Ändern der On-Prem-Attribute eines Hybridbenutzers: Nutzen Sie die Azure AD Synchronisierungs-API, um den onPremises Security Identifier (SID) und den onPremises SAMAccountName eines gewählten Hybridbenutzers so festzulegen, dass sie mit dem Ziel-AD-Konto übereinstimmen. Dies teilt Azure AD effektiv mit, dass der Cloud-Benutzer dem On-Prem-Konto entspricht, das wir nachahmen möchten. Verwenden Sie das Open-Source-Toolkit 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>

Der sourceAnchor (unveränderliche ID) des Benutzers wird benötigt, um das Azure AD-Objekt zu identifizieren, das geändert werden soll. Das Tool setzt die lokale SID und den SAM-Kontonamen des hybriden Benutzers auf die Werte des Ziels (z. B. die SID und den SAM des MSOL_xxxx-Kontos). Azure AD erlaubt normalerweise nicht, diese Attribute über Graph zu ändern (sie sind schreibgeschützt), aber die Sync-Service-API erlaubt dies, und globale Administratoren können diese Synchronisierungsfunktionalität aufrufen.

3. Erhalten Sie ein partielles TGT von Azure AD: Nach der Änderung authentifizieren Sie sich als hybrider Benutzer bei Azure AD (zum Beispiel, indem Sie ein PRT auf einem Gerät erhalten oder ihre Anmeldeinformationen verwenden). Wenn sich der Benutzer anmeldet (insbesondere auf einem domänenverbundenen oder Entra-verbundenen Windows-Gerät), gibt Azure AD ein partielles Kerberos TGT (TGT_AD) für dieses Konto aus, da Cloud Kerberos Trust aktiviert ist. Dieses partielle TGT ist mit dem AzureADKerberos$ RODC-Schlüssel verschlüsselt und enthält die Ziel-SID, die wir festgelegt haben. Wir können dies simulieren, indem wir ein PRT für den Benutzer über ROADtools anfordern:

roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

Dies gibt eine .prt-Datei aus, die das partielle TGT und den Sitzungsschlüssel enthält. Wenn das Konto ein cloud-only Passwort war, enthält Azure AD dennoch ein TGT_AD in der PRT-Antwort.

4. Exchange Partial TGT for Full TGT (on AD): Das partielle TGT kann nun dem lokalen Domain Controller präsentiert werden, um ein vollständiges TGT für das Zielkonto zu erhalten. Wir tun dies, indem wir eine TGS-Anfrage für den krbtgt-Dienst (den primären TGT-Dienst der Domäne) durchführen – im Wesentlichen wird das Ticket auf ein normales TGT mit einem vollständigen PAC aktualisiert. Tools sind verfügbar, um diesen Austausch zu automatisieren. Zum Beispiel mit dem Skript von 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

Dieses Skript (oder Impacket-Äquivalente) wird den Domänencontroller kontaktieren und ein gültiges TGT für das Ziel-AD-Konto abrufen, einschließlich des NTLM-Hashes des Kontos, wenn die spezielle Kerberos-Erweiterung verwendet wird. Die KERB-KEY-LIST-REQ-Erweiterung wird automatisch hinzugefügt, um den DC zu bitten, den NTLM-Hash des Zielkontos in der verschlüsselten Antwort zurückzugeben. Das Ergebnis ist ein Anmeldeinformationen-Cache (full_tgt.ccache) für das Zielkonto oder den wiederhergestellten NTLM-Passwort-Hash.

5. Ziel impersonieren und zu Domain Admin erhöhen: Jetzt kontrolliert der Angreifer effektiv das Ziel-AD-Konto. Wenn das Ziel beispielsweise das AD Connect MSOL-Konto war, hat es Replikationsrechte im Verzeichnis. Der Angreifer kann einen DCSync-Angriff unter Verwendung der Anmeldeinformationen dieses Kontos oder des Kerberos-TGT durchführen, um Passwort-Hashes aus AD zu dumpen (einschließlich des Domänen-KRBTGT-Kontos). Zum Beispiel:

# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

Dies dumpft alle AD-Benutzerpassworthashes und gibt dem Angreifer den KRBTGT-Hash (was es ihm ermöglicht, Kerberos-Tickets für die Domäne nach Belieben zu fälschen) und effektiv Domain Admin-Berechtigungen über AD. Wenn das Zielkonto ein anderer privilegierter Benutzer wäre, könnte der Angreifer das vollständige TGT verwenden, um auf jede Domänenressource als dieser Benutzer zuzugreifen.

6. Bereinigung: Optional kann der Angreifer den ursprünglichen onPremisesSAMAccountName und SID des modifizierten Azure AD-Benutzers über dieselbe API wiederherstellen oder einfach jeden erstellten temporären Benutzer löschen. In vielen Fällen wird der nächste Azure AD Connect-Synchronisierungszyklus nicht autorisierte Änderungen an synchronisierten Attributen automatisch zurücksetzen. (Zu diesem Zeitpunkt ist der Schaden jedoch bereits angerichtet – der Angreifer hat DA-Berechtigungen.)

References

• Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust