Microsoft Entra Connect (ehem. Azure AD Connect) unterstützt die Nutzerfreundlichkeit, wenn gleichzeitig ein On Premise Active Directory und Microsoft Entra (ehem. Azure Active Directory) im Einsatz sind. Ist die Synchronisation eingerichtet, müssen sich Anwender nur einmal anmelden, um Zugriff auf beide Dienste zu haben. Was vielen Administratoren jedoch nicht bewusst ist: Bei der Einrichtung von Microsoft Entra Connect (ehem. Azure AD Connect) wird ein spezieller Account angelegt, der über weitreichende Rechte verfügt und daher für Angreifer ein lohnenswertes Ziel darstellt. In diesem Artikel erklären wir, wie Hacker bei einem solchen Angriff vorgehen können und wie du dich angemessen davor schützen kannst.
Wenn du dich zunächst grundsätzlich über Microsoft Entra (ehem. Azure AD) informieren möchtest, findest du alle Basics in unserem Grundlagenartikel Was ist Microsoft Entra (ehem. Azure) mit vielen anschaulichen Screenshots. Weiterführende Artikel zu Angriffen und Schutzmöglichkeiten findest du hier:
Microsoft Entra Connect (ehem. Azure AD Connect) ist eine Anwendung von Microsoft. Mit dem Connect-Dienst können Admins Domänen in einem klassischen On Premise Active Directory mit einem Entra/ Azure Active Direcotry innerhalb eines M365-Tenants verbinden. Dies hat den Vorteil, dass sich Nutzer mit einem Accountnamen und Passwort an beiden Diensten anmelden können. So ist die Grenze zwischen beiden Diensten für die Nutzer häufig gar nicht wahrnehmbar.
Für diese Verbindung bzw. Synchronisation gibt es verschiedene Möglichkeiten, die durch Microsoft angeboten werden. In unserem Szenario betrachten wir eine Anbindung, die man sehr häufig in der Realität vorfindet, weil sie die simpelste und am schnellsten eingerichtete Form von Microsoft Entra Connect (ehem. Azure AD Connect) ist.
In unserem Szenario ist unser Angriffsziel wie folgt aufgebaut: Der Admin verbindet eine bestehende Domäne (secperts.com) in seinem AD (ON PREM) mit der Microsoft Entra ID (ehem. Azure AD) (ebenfalls secperts.com). Hierzu installiert er das Tool „Microsoft Entra Connect“ (ehem. Azure AD Connect) auf einem dediziert dafür installiertem Windows Server, der Teil der ON-PREM-Domain ist. In der Standardeinstellung verwendet Microsoft Entra Connect die „Kennwort-Hashsynchronisierung“.
Diese Standardeinstellung führt dazu, dass die Domain Controller in der lokalen Domäne und das Entra (ehem. Azure) AD den Passwort-NT-Hash zu einem Konto synchronisieren. Dadurch können sich Nutzer bei beiden Diensten mit demselben Passwort anmelden. Hierzu verwendet Microsoft Entra Connect (ehem. Azure AD Connect) die Funktion „DC-Sync“. Diese wird auch von lokalen Domaincontroller genutzt, um ihre Hashdatenbank NTDS-synchron zu halten.
Über eine Entität mit entsprechenden Rechten ist es somit möglich, bei jedem Domain Controller die NTDS anzufragen und vollständig zu erhalten. Ein Account mit dem Recht zum DC-Sync hat somit Zugriff auf alle NT-Hashes sämtlicher Accounts einer Domäne.
Damit die Synchronisierung zwischen Cloud und Lokalem AD funktioniert, wird bei der Installation des Microsoft Entra Connect Tools ein spezieller Account im lokalen AD angelegt. Dieser Account verfügt über die oben erwähnten Rechte zum DC-Sync und damit über Zugriff auf alle NT-Hashes der Domäne. Das macht diesen Account sehr interessant für Angreifer: Der DC-Sync besitzt besondere Privilegien, die üblicherweise nur Domänen-Admins und den Domaincontrollern selbst vorbehalten sind.
Ein mögliches Szenario, um die Funktionalität des Entra (ehem. Azure) Syncs zu missbrauchen, ist daher ein Angriff auf den speziellen DC-Sync-Account. Angreifer können diesen Account durch folgende Merkmale identifizieren:
Angreifer können den Account anhand dieser Merkmale sehr leicht in einer Ziel-Domäne finden. Der Account stellt außerdem aufgrund seiner Rechte ein lohnendes Ziel für die Privilege Escalation zum Domain-Admin dar.
Das Ziel von Angreifern ist es grundsätzlich, die Domäne mit Domain-Admin-Rechten zu übernehmen. Der Ansatz ist hier daher eine lokale Privilege Escalation, um den Server über eine Erweiterung der Rechte innerhalb der Domäne zu missbrauchen.
Dieses Szenario ist realistisch, weil den meisten Admins gar nicht bewusst bzw. bekannt ist, wie gefährlich die DC-Sync-Rechte sind und dass dieser spezielle Account für den Entra (Azure) Sync über diese Rechte verfügt. Häufig ist es nämlich so, dass der Server und Azure AD Connect eingerichtet werden und dann ungestört vor sich hinarbeiten, ohne dass weitere Maßnahmen zur Absicherung des Systems getroffen werden.
Wenn es uns nun gelingt, auf dem Server die Rechte eines lokalen Administrators zu erlangen (z. B. weil kein LAPS verwendet wird) und wir die Credentials für das lokale Adminkonto an anderer Stelle erbeuten konnten, steht einer Erweiterung unserer Rechte nicht mehr viel im Weg.
Sofern keine gute Endpoint Protection im Einsatz ist und kein Credential Guard verwendet wird, kann schon ein LSASS-Dump über lsassy ausreichen, um das Klartext-Passwort des MSOL-Accounts zu erhalten. Lsassy wird aber von den meisten EPP-Lösungen inklusive des standardmäßig aktivierten Windows Defender erkannt und verhindert.
Der LSASS-Dump soll hier daher nicht der Weg unserer Wahl sein, weil bei dem Beispiel unten „geschummelt“ wurde und der Windows Defender dabei deaktiviert war. Im Folgenden präsentieren wir jedoch einen einfachen Angriff in 2 Schritten, der auch bei aktiviertem Windows Defender funktioniert.
In diesem Abschnitt versetzen wir uns als Penetration Tester in die Perspektive böswilliger Angreifer. Wir werden zeigen, dass wir in nur 2 einfachen Schritten die Kontrolle über den Domain-Admin-Account erlangen können.
Im ersten Schritt wollen wir das Passwort des speziellen MSOL-Accounts mit den DC-Sync-Rechten erlangen. Dafür benutzten wir ein Tool namens CrackMapExec (CME), in dem wir das Modul „msol“ verwenden. Dieses führt bei Ausführung ein Powershell-Skript auf dem Ziel aus und kann dadurch das Klartext-Passwort des MSOL-Accounts extrahieren. Diese Variante ist im Vergleich zum LSASS-exe-Dump wesentlich weniger auffällig und wird (zumindest Stand heute) von vielen EPP-Lösungen noch nicht bemerkt bzw. unterbunden.
Mit folgendem Befehl führen wir das Skript aus und erhalten im Output das Passwort des MSOL-Accounts:
cme smb TARGET-IP -u LOCAL-ADMIN-ACCOUNT -p PASSWORD --local-auth -M msol
Sobald wir das Passwort haben, sind wir nur einen einzigen CME-Befehl von der vollständigen Übernahme der Domäne entfernt. Wir haben den folgender Befehl verwendet, um die NTDS der Domäne zu „dumpen“:
cme smb 10.1.1.10 -u MSOL_ac290fc6510f -d secperts.com -p '%uY*rI?
hfya{tb{.IpWrGFZ]Mcga^*v$a-b9V@*0/@x}NNwIn-1{^;*p*z*j/F*V%?^_iC!
b3=@AQI^*MG&UE=B9E^l(]hbtGiQ]1rM7/@V;3[(}H5;!BA:t5*Gk91W' --ntds
Der Befehl missbraucht die DC-Sync-Rechte des MSOL-Accounts und gibt uns sämtliche Accounts und zugehörige NT- bzw. LM-Hashes aus. Über Pass-the-Hash können wir nun mit dem NT-Hash des Accounts Administrator@secperts.com die Domäne übernehmen. Alternativ können wir uns mit dem NT-Hash des KRBTGT-Kontos ein Golden Tickets erstellen.
Kurzum: Die Domäne ist kompromittiert und einem potenziellen Angreifer schutzlos ausgeliefert.
Wechseln wir nun zurück in die Perspektive des eigentlichen Domain-Administrators: Wie kannst du dich vor einem solchen Angriff schützen? Das System, auf dem Microsoft Entra Connect (ehem. Azure AD Connect) ausgeführt wird, muss hierfür besonders geschützt werden. Gleiches gilt für den Account, der für den Synchronisierungsdienst genutzt wird.
Gemäß Microsofts eigenem Tiering-Modell solltest du sowohl das System als auch der Account im sog. T 0 (Tier Zero) verorten. Diese Berechtigungsstufe ist besonders mächtigen und sensiblen Accounts vorbehalten.
Das bedeutet, dass nur Accounts mit Domänenadministrationsrechten entsprechende Rechte auf dem Server haben dürfen und dementsprechend auch das lokale Adminstrationskonto besonders schützenswert ist. Hier ist die gängige Empfehlung, LAPS (Local Admin Password Solution) zu verwenden, damit das lokale Adminstrationskonto ein individuelles Passwort erhält, auf das nur T0-Accounts Zugriff haben.
Darüber hinaus sollte auf dem Server Credential Guard eingesetzt werden. Eine moderne Endpoint Protection ist ebenfalls Pflicht.
Bei Microsoft Entra Connect (ehem. Azure AD Connect) gilt wie bei zahlreichen anderen Anwendungen: Ein funktionierendes System ist nicht unbedingt auch ein sicheres System. Man muss sich aktiv mit Sicherheitsaspekten auseinandersetzen, um potenzielle Angriffspunkte zu erkennen und entsprechend zu schützen.
Im Fall des Connect-Dienstes ist dies der speziell für diesen Zweck im lokalen AD eingerichtete DC-Sync-Account mit dem Anfangskürzel MSOL. Dieser Account hat Zugriff auf alle NT-Hashes sämtlicher Accounts seiner Domäne und sollte daher besonders geschützt werden.
Eine geeignete Schutzmaßnahme ist es, diesen MSOL-Account im Tier Zero zu verorten. Eine gängige Empfehlung ist hierbei die Verwendung von LAPS (Local Admin Password Solution). Der Einsatz von Credential Guard auf dem Server und eine moderne Endpoint Protection runden deinen Schutz ab.
So kannst du den Komfort von Microsoft Entra Connect (ehem. Azure AD Connect) nutzen, ohne dich dadurch wesentlich angreifbarer zu machen.
