Az - Cloud Kerberos Trust
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.**
Wenn ein Vertrauen mit Azure AD hergestellt wird, wird ein Read Only Domain Controller (RODC) im AD erstellt. Das RODC-Computer-Konto heißt AzureADKerberos$
. Außerdem gibt es ein sekundäres krbtgt
-Konto mit dem Namen krbtgt_AzureAD
. Dieses Konto enthält die Kerberos-Schlüssel, die für Tickets verwendet werden, die Azure AD erstellt.
Daher könnte es, wenn dieses Konto kompromittiert wird, möglich sein, sich als jeder Benutzer auszugeben... obwohl dies nicht zutrifft, da dieses Konto daran gehindert wird, Tickets für gängige privilegierte AD-Gruppen wie Domain Admins, Enterprise Admins, Administrators... zu erstellen.
In einem realen Szenario wird es jedoch privilegierte Benutzer geben, die nicht in diesen Gruppen sind. Das neue krbtgt-Konto könnte, wenn es kompromittiert wird, verwendet werden, um sich als diese auszugeben.
Darüber hinaus wird, wenn sich ein Benutzer unter Windows mit einer hybriden Identität authentifiziert, **Azure AD ein teilweises Kerberos-Ticket zusammen mit dem PRT ausstellen. Das TGT ist teilweise, weil AzureAD nur begrenzte Informationen über den Benutzer im lokalen AD hat (wie die Sicherheitskennung (SID) und den Namen).
Windows kann dann dieses teilweise TGT gegen ein vollständiges TGT eintauschen, indem es ein Serviceticket für den krbtgt
-Dienst anfordert.
Da es Dienste geben könnte, die keine Kerberos-Authentifizierung, sondern NTLM unterstützen, ist es möglich, ein teilweises TGT zu beantragen, das mit einem sekundären krbtgt
-Schlüssel signiert ist, indem das KERB-KEY-LIST-REQ
-Feld im PADATA-Teil der Anfrage enthalten ist, und dann ein vollständiges TGT zu erhalten, das mit dem primären krbtgt
-Schlüssel einschließlich des NT-Hashes in der Antwort signiert ist.
Wenn AzureAD ein teilweises TGT generiert, verwendet es die Details, die es über den Benutzer hat. Daher könnte, wenn ein Global Admin Daten wie die Sicherheitskennung und den Namen des Benutzers in AzureAD ändern könnte, bei der Anforderung eines TGT für diesen Benutzer die Sicherheitskennung eine andere sein.
Es ist nicht möglich, dies über die Microsoft Graph oder die Azure AD Graph zu tun, aber es ist möglich, die API zu verwenden, die Active Directory Connect verwendet, um synchronisierte Benutzer zu erstellen und zu aktualisieren, die von den Global Admins verwendet werden kann, um den SAM-Namen und die SID eines hybriden Benutzers zu ändern, und dann, wenn wir uns authentifizieren, erhalten wir ein teilweises TGT, das die geänderte SID enthält.
Beachten Sie, dass wir dies mit AADInternals tun können und synchronisierte Benutzer über das Set-AADIntAzureADObject Cmdlet aktualisieren können.
Der Erfolg des Angriffs und die Erlangung von Domain Admin-Rechten hängen von der Erfüllung bestimmter Voraussetzungen ab:
Die Fähigkeit, Konten über die Synchronisierungs-API zu ändern, ist entscheidend. Dies kann erreicht werden, indem man die Rolle des Global Admin hat oder über ein AD Connect-Synchronisationskonto verfügt. Alternativ würde die Rolle des Hybrid Identity Administrators ausreichen, da sie die Möglichkeit bietet, AD Connect zu verwalten und neue Synchronisationskonten zu erstellen.
Das Vorhandensein eines hybriden Kontos ist unerlässlich. Dieses Konto muss für die Änderung mit den Details des Opferkontos geeignet sein und sollte auch für die Authentifizierung zugänglich sein.
Die Identifizierung eines Zielopferkontos innerhalb des Active Directory ist notwendig. Obwohl der Angriff auf jedes bereits synchronisierte Konto ausgeführt werden kann, darf der Azure AD-Mandant keine replizierten lokalen Sicherheitskennungen haben, was die Änderung eines nicht synchronisierten Kontos erforderlich macht, um das Ticket zu beschaffen.
Darüber hinaus sollte dieses Konto über gleichwertige Domain-Admin-Rechte verfügen, darf jedoch kein Mitglied typischer AD-Administratorgruppen sein, um die Generierung ungültiger TGTs durch das AzureAD RODC zu vermeiden.
Das am besten geeignete Ziel ist das Active Directory-Konto, das vom AD Connect Sync-Dienst verwendet wird. Dieses Konto wird nicht mit Azure AD synchronisiert, wodurch seine SID ein viables Ziel bleibt, und es hat aufgrund seiner Rolle bei der Synchronisierung von Passwort-Hashes (vorausgesetzt, die Passwort-Hash-Synchronisierung ist aktiv) von Natur aus gleichwertige Domain-Admin-Rechte. Für Domänen mit Express-Installation wird dieses Konto mit MSOL_ vorangestellt. In anderen Fällen kann das Konto ermittelt werden, indem alle Konten aufgelistet werden, die über Verzeichnisreplikationsrechte auf dem Domänenobjekt verfügen.
Überprüfen Sie es im Originalbeitrag: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)