Wer regelmäßig hybride Umgebungen prüft, kennt das Bild: Um den Entra-Connect-Server kümmert sich kaum jemand. In vielen Tenants läuft er nach wie vor ungehärtet mitten im Produktionsnetz, gelegentlich sogar mit Internetzugang, und Admins melden sich ohne Bedenken daran an. Wie gefährlich das ist, belegt der aktuelle Bericht von Microsoft zu Storm-0501 (https://www.microsoft.com/en-us/security/blog/2024/09/26/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/) einmal mehr. Nachdem die Angreifer die On-Premises-Umgebungen kompromittiert hatten, stahlen sie die Anmeldeinformationen des Directory Synchronization Accounts direkt vom Entra-Connect-Server und übernahmen damit die Kontrolle über den Cloud-Tenant.

Der Entra-Connect-Server gehört in die Tier-0-Ebene

Technisch betrachtet ist der Entra-Connect-Server eben kein beliebiger Rechner im Unternehmensnetz. Er übernimmt den Verzeichnisabgleich zwischen Active Directory und Entra ID und sitzt damit an einer äußerst sensiblen Stelle. Wer ihn kompromittiert, erbeutet häufig Hashes und Dienstkonten. Wie Storm-0501 vorgeführt hat, kommt er außerdem an die Synchronisationsidentität, die im Tenant oft weitreichende Rechte besitzt. Mir begegnen immer noch Umgebungen, in denen das Sync-Konto zusätzlich Admin-Rollen innehat oder der Server in kaum segmentierten Servernetzen steht. Dieses Risiko wird regelmäßig unterschätzt.

Synchronisierte Admin-Konten ohne MFA sind ein häufiges Einfallstor

Ein Kernproblem besteht darin, dass aus dem AD synchronisierte Konten weiterhin privilegierte Cloud-Rollen innehaben, oft ohne durchgängige MFA. Storm-0501 hat genau diese Schwäche ausgenutzt. Mit dem gestohlenen Sync-Konto und einem weiteren kompromittierten Konto mit Cloud-Admin-Rechten war der Tenant übernommen. Die Verteidigung fängt deshalb damit an, in administrativen Rollen von Entra ID keine synchronisierten Konten einzusetzen. Tenant-Admins brauchen Cloud-only-Konten, die zwingend mit phishing-resistenter MFA wie FIDO2 oder Passkeys geschützt sind. Wer hier aus Bequemlichkeit oder wegen gewachsener Altlasten Ausnahmen zulässt, macht es Angreifern unnötig leicht.

Praktischer Tipp: Richtet für alle privilegierten Rollen (Global Admin, Privileged Role Admin, Exchange Admin usw.) ausschließlich Cloud-only-Konten ein und erzwingt für diese die Anmeldung per FIDO2 oder Passkey über eine eigene Authentifizierungsmethodenrichtlinie.

Mit der Migration auf die neue Authentifizierungsmethodenrichtlinie in Entra ID gewinnt man dabei deutlich mehr Spielraum als mit den alten MFA-Einstellungen (wie die Migration gelingt, beschreibe ich hier).

Der Connect-Server braucht Härtung und lückenlose Überwachung

Der Entra-Connect-Server verdient dieselbe Sorgfalt wie ein Domain Controller. Am Anfang steht die physische und logische Segmentierung. Der Server bekommt keinen Internetzugang, nur die unbedingt nötigen Ports bleiben offen, und anmelden darf sich ausschließlich, wer dort tatsächlich arbeiten muss. Gern übersehen wird, dass sich die auf dem Server gespeicherten Anmeldedaten, vor allem die des Sync-Kontos, im Klartext auslesen lassen. Die Anmeldungen des Directory Synchronization Accounts gehören deshalb zwingend überwacht. Unter Entra ID Portal → Überwachungsprotokolle → Anmeldungen kann man gezielt nach dem Sync-Konto filtern. Fallen verdächtige Anmeldungen auf, etwa aus ungewohnten Ländern oder zu ungewöhnlichen Uhrzeiten, sollte man ihnen sofort nachgehen.

Eine Beispielabfrage in KQL (Defender for Cloud Apps, Lizenz: Defender for Cloud Apps P1/P2, Rolle: Security Reader):

IdentityInfo
| where AccountName contains "Sync_" or AccountName contains "MSOL_"
| join kind=inner (SigninLogs | where ResultType == 0) on $left.AccountObjectId == $right.UserId
| project TimeGenerated, AccountName, Location, IPAddress, AppDisplayName

So fallen ungewöhnliche Aktivitäten des Synchronisationskontos schnell auf. Das ist vor allem bei Angriffen wichtig, die sich vom On-Premises-Netz aus seitwärts ausbreiten.

Cloud Sync und aktuelle Versionen senken das Risiko zusätzlich

Wem der Aufwand für einen klassischen Connect-Server zu hoch ist, sollte sich Entra Cloud Sync ansehen. Cloud Sync arbeitet mit einem schlanken Agent und sieht von Haus aus minimale Berechtigungen vor. Gut passt es dort, wo weder komplexe Sync-Regeln noch Writeback-Funktionen gebraucht werden. Für viele kleine und mittlere Umgebungen ist das mittlerweile die bessere Wahl. Ausführlicher gehe ich darauf im Beitrag Entra Connect Sync oder Cloud Sync ein.

Genauso wichtig wie Härtung und getrennte Konten ist es, Entra Connect aktuell zu halten. Die meisten Schwachstellen rühren von veralteten Versionen her. Gemeint sind damit Sicherheitslücken im Code ebenso wie überholte Authentifizierungsverfahren. Ist zudem die Passwort-Hash-Synchronisierung aktiviert, funktionieren Cloud-Anmeldungen auch dann, wenn die On-Premises-Komponenten ausfallen. Diesen Zugewinn an Resilienz unterschätzen viele. Den zugehörigen Leitfaden von Microsoft gibt es hier: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-prerequisites.

Das folgende vereinfachte Ablaufdiagramm zeigt den typischen Angriffsweg von Storm-0501 und die kritischen Schwachstellen:

flowchart TD
    A["Angreifer kompromittiert AD"] --> B["Zugriff auf Entra Connect Server"]
    B --> C["Sync-Konto-Anmeldedaten auslesen"]
    C --> D["Sync-Konto nutzt Admin-Rolle in Entra ID"]
    D --> E["Cloud-Admin-Konto ohne MFA"]
    E --> F["Übernahme des Entra Tenants"]

Abbildung: Angriffspfad von Storm-0501 über den Entra-Connect-Server bis zur Übernahme des Tenants.

Bei Hybrid Identity verbieten sich Kompromisse

Die Angriffe von Storm-0501 sind kein Einzelfall. Sie legen Schwachstellen offen, die mir in der Praxis ständig begegnen. Wer Hybrid Identity betreibt, muss den Entra-Connect-Server mindestens so ernst nehmen wie den Domain Controller. Vertretbar sind heute nur noch Cloud-only-Admins in privilegierten Rollen, konsequent durchgesetzte MFA und aktuelle Softwarestände. Oft lässt sich das Risiko weiter senken, indem man auf Cloud Sync umsteigt und bewusst auf überflüssige On-Premises-Abhängigkeiten verzichtet. Die Angreifer werden immer geschickter, und unsere Verteidigung muss mithalten. Wer das Thema jetzt angeht, bleibt später von bösen Überraschungen verschont.