Az - Cloud Kerberos Trust
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.**
Grundinformationen
Vertrauen
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, wenn dieses Konto kompromittiert wird, könnte es möglich sein, jeden Benutzer zu impersonieren... obwohl dies nicht zutrifft, da dieses Konto daran gehindert wird, Tickets für beliebige gemeinsame 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. Daher könnte das neue krbtgt-Konto, wenn es kompromittiert wird, verwendet werden, um sie zu impersonieren.
Kerberos TGT
Darüber hinaus, wenn sich ein Benutzer unter Windows mit einer hybriden Identität authentifiziert, wird Azure AD ein partielles Kerberos-Ticket zusammen mit dem PRT ausstellen. Das TGT ist partiell, weil AzureAD nur begrenzte Informationen über den Benutzer im lokalen AD hat (wie die Sicherheitskennung (SID) und den Namen).
Windows kann dann dieses partielle TGT gegen ein vollständiges TGT eintauschen, indem es ein Serviceticket für den krbtgt-Dienst anfordert.
NTLM
Da es Dienste geben könnte, die keine Kerberos-Authentifizierung, sondern NTLM unterstützen, ist es möglich, ein partielles 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.
Missbrauch von Cloud Kerberos Trust, um Domain Admin zu erhalten
Wenn AzureAD ein partielles TGT generiert, verwendet es die Details, die es über den Benutzer hat. Daher, wenn ein Global Admin Daten wie die Sicherheitskennung und den Namen des Benutzers in AzureAD ändern könnte, wäre die Sicherheitskennung bei der Anforderung eines TGT für diesen Benutzer eine andere.
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, was von den Global Admins genutzt werden kann, um den SAM-Namen und die SID eines hybriden Benutzers zu ändern, und dann, wenn wir uns authentifizieren, erhalten wir ein partielles TGT, das die geänderte SID enthält.
Beachte, dass wir dies mit AADInternals tun können und synchronisierte Benutzer über das Set-AADIntAzureADObject Cmdlet aktualisieren können.
Angriffsvoraussetzungen
Der Erfolg des Angriffs und der Erwerb 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 ein AD Connect-Synchronisationskonto besitzt. 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 den 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 mit Verzeichnisreplikationsberechtigungen auf dem Domänenobjekt aufgelistet werden.
Der vollständige Angriff
Überprüfe es im Originalbeitrag: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated
