Az - Cloud Kerberos Trust
Dieser Beitrag ist eine Zusammenfassung von https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ , der weitere Informationen zum Angriff enthält. Diese Technik wird auch in https://www.youtube.com/watch?v=AFay_58QubY** kommentiert.**
Grundlegende Informationen
Vertrauen
Wenn ein Vertrauensverhältnis mit Azure AD hergestellt wird, wird ein Read Only Domain Controller (RODC) im AD erstellt. Das RODC-Computerkonto wird AzureADKerberos$ genannt. Außerdem wird ein sekundäres krbtgt-Konto namens krbtgt_AzureAD erstellt. Dieses Konto enthält die Kerberos-Schlüssel, die für Tickets verwendet werden, die von Azure AD erstellt werden.
Daher könnte es möglich sein, jeden Benutzer zu imitieren, wenn dieses Konto kompromittiert ist... obwohl dies nicht stimmt, da dieses Konto daran gehindert wird, Tickets für gängige privilegierte AD-Gruppen wie Domänenadministratoren, Unternehmensadministratoren, Administratoren usw. 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 kompromittiert, verwendet werden, um sie zu imitieren.
Kerberos TGT
Darüber hinaus wird bei der Authentifizierung eines Benutzers unter Windows mit einer hybriden Identität Azure AD ein teilweises Kerberos-Ticket zusammen mit dem PRT ausstellen. Das TGT ist teilweise, weil AzureAD 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 austauschen, indem es ein Dienstticket 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 **teilweises TGT zu fordern, das mit einem sekundären krbtgt-Schlüssel signiert ist, einschließlich des Felds KERB-KEY-LIST-REQ im PADATA-Teil der Anforderung, und dann ein vollständiges TGT zu erhalten, das mit dem primären krbtgt-Schlüssel signiert ist, einschließlich des NT-Hash im Antwort.
Ausnutzen des Cloud-Kerberos-Vertrauens zur Erlangung von Domänenadministratorrechten
Wenn AzureAD ein teilweises TGT generiert, verwendet es die Details, die es über den Benutzer hat. Daher, wenn ein Globaler Administrator Daten wie die Sicherheitskennung und den Namen des Benutzers in AzureAD ändern könnte, wenn er ein TGT für diesen Benutzer anfordert, wäre die Sicherheitskennung eine andere.
Dies ist nicht über das Microsoft Graph oder das Azure AD Graph möglich, 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 Globalen Administratoren verwendet werden kann, um den SAM-Namen und die SID eines beliebigen hybriden Benutzers zu ändern, und dann, wenn wir uns authentifizieren, erhalten wir ein teilweises TGT, das die modifizierte SID enthält.
Beachten Sie, dass dies mit AADInternals möglich ist und die Synchronisierung von Benutzern über das Set-AADIntAzureADObject Cmdlet aktualisiert werden kann.
Angriffsvoraussetzungen
Der Erfolg des Angriffs und die Erlangung von Domänenadministratorrechten hängen von bestimmten Voraussetzungen ab:
Die Fähigkeit, Konten über die Synchronisierungs-API zu ändern, ist entscheidend. Dies kann durch die Rolle des Globalen Administrators oder den Besitz eines AD Connect Sync-Kontos erreicht werden. Alternativ würde die Rolle des Hybrid Identity Administrators ausreichen, da sie die Möglichkeit bietet, AD Connect zu verwalten und neue Sync-Konten einzurichten.
Das Vorhandensein eines hybriden Kontos ist unerlässlich. Dieses Konto muss für Änderungen mit den Details des Opferkontos anfällig sein und sollte auch für die Authentifizierung zugänglich sein.
Die Identifizierung eines Ziel-Opferkontos im Active Directory ist eine Notwendigkeit. 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 zur Beschaffung des Tickets erforderlich macht.
Darüber hinaus sollte dieses Konto über Domänenadministrator-äquivalente Berechtigungen verfügen, darf jedoch kein Mitglied typischer AD-Administratorgruppen sein, um die Generierung ungültiger TGTs durch den AzureAD RODC zu vermeiden.
Das geeignetste Ziel ist das Active Directory-Konto, das vom AD Connect Sync-Dienst verwendet wird. Dieses Konto wird nicht mit Azure AD synchronisiert, sodass seine SID als mögliches Ziel bleibt, und es besitzt inhärent Domänenadministrator-äquivalente Berechtigungen aufgrund seiner Rolle bei der Synchronisierung von Passworthashes (sofern die Passworthashsynchronisierung aktiv ist). Für Domänen mit Expressinstallation wird dieses Konto mit MSOL_ vorangestellt. In anderen Fällen kann das Konto durch Aufzählen aller Konten ermittelt werden, die mit Replikationsberechtigungen für das Domänenobjekt ausgestattet sind.
Der vollständige Angriff
Überprüfen Sie dies im Originalbeitrag: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated