Neue Defender-for-Identity-Alerts für Entra ID und AD ausgerollt

Executive Summary

Microsoft hat die Alert-Bibliothek von Defender for Identity in der Juni-Welle 2026 noch einmal aufgebohrt: zehn neue Detektionen, davon sieben rund um Microsoft Entra ID, zwei für das klassische Active Directory und erstmals eine, die aus einem fremden Identity Provider stammt – SailPoint Identity Security Cloud. Zusammen mit den Wellen aus Januar, Februar, März und Mai sind das rund 46 neue Alerts in sieben Monaten. Wer sein SOC-Playbook zuletzt 2024 angefasst hat, betreibt faktisch ein anderes Produkt als das, was er dokumentiert hat.

Inhaltlich ist die Richtung eindeutig: weg von der reinen Kerberos-Forensik auf dem Domain Controller, hin zu Verhaltensmustern über Cloud, On-Premises und Fremd-IdP hinweg. Neu sind unter anderem eine dedizierte DCSync-Erkennung, ein Alert auf verdächtige Anmeldungen des Entra-Connect-Kontos, die Erkennung reziproker Temporary Access Passes und ein Signal auf Massenlöschung von Konten per Skript. Parallel wurde im Juli die Migration der Sensoren von v2.x auf v3.x allgemein verfügbar, RPC-Auditing aktiviert sich ab Sensorversion 3.0.8 selbst, und der Identity Risk Score ist seit Juni allgemein verfügbar.

Für dich als Betreiber heißt das dreierlei. Erstens hängt ein Teil der neuen Erkennungen an Sensorversion und Audit-Konfiguration – ohne Hausaufgaben kein Signal, und ein stiller Sensor sieht im Bericht genauso aus wie eine sichere Umgebung. Zweitens ändert sich die Rauschsignatur deines SOC spürbar, weil verhaltensbasierte Alerts naturgemäß mehr Diskussion erzeugen als ein sauberer Golden-Ticket-Fund. Drittens – und das ist der eigentliche Hebel – lassen sich die neuen Signale endlich sinnvoll in XDR-Automatik und bedingten Zugriff hängen, statt sie als hochwertige Dekoration im Portal versauern zu lassen.

Worum geht es im Detail?

Fangen wir bei dem an, was am meisten weh tut, wenn es fehlt: DCSync. Der Alert „DCSync-Angriff (Replikation der Verzeichnisdienste)“ feuert, wenn eine Replikationsanfrage von einer Quelle kommt, die kein Domain Controller ist – MITRE T1003.006, Schweregrad hoch. Das ist die Technik, mit der jedes zweite Ransomware-Team seit Jahren an den krbtgt-Hash und damit an das Goldene Ticket kommt. Dass Microsoft das jetzt als eigenständigen, klar benannten Alert führt, statt es in generischen Replikationsanomalien zu vergraben, ist ein handfester Fortschritt für die Triage: Der Analyst liest den Angriffsnamen und weiß sofort, welches Playbook zieht. Vorher las er „ungewöhnliche Verzeichnisreplikation“ und rief erst mal den Kollegen an, der schon länger dabei ist.

Der zweite AD-Alert zielt auf ein Konto, das in fast jeder hybriden Umgebung existiert und in fast keiner ordentlich überwacht wird: das Entra-Connect-Synchronisationskonto. „Verdächtige Authentifizierung eines Entra-Connect-Kontos“ schlägt an, wenn dieses Konto von einer IP-Adresse authentifiziert, die über Threat Intelligence auffällig ist oder schlicht nicht zum üblichen Muster passt – Techniken T1078 und T1556.007, Schweregrad hoch. Der Hintergrund ist unbequem: Das Sync-Konto hat historisch Replikationsrechte im Verzeichnis, es ist damit ein wandelnder DCSync-Freifahrtschein, und es wird typischerweise einmal eingerichtet und dann ein Jahrzehnt lang niemandem zugeordnet. Angreifer wissen das seit mindestens 2019, Betreiber erfahren es meistens beim Incident.

Auf der Cloud-Seite dreht sich fast alles um Persistenz und Verhaltenssprünge. Besonders elegant ist „Reziproke Erstellung von Temporary Access Passes zwischen Benutzern“: Zwei Konten stellen sich innerhalb eines kurzen Zeitfensters gegenseitig einen TAP aus. Als Betriebsmuster ist das praktisch nie erklärbar, als Angriffsmuster ist es brillant – zwei kompromittierte Konten halten sich gegenseitig am Leben, und wenn du eines zurücksetzt, backt das andere es freundlich wieder auf. Dazu kommen „Auffällige Aktivität nach Global-Administrator-Elevation“, „Verdächtige Anmeldung eines Service Principals nach Hinzufügen von Anmeldeinformationen“ – der klassische Backdoor-Pfad über die App-Registrierung – und „Verdächtiges Entfernen einer privilegierten App-Rollenzuweisung über die Graph API“.

Zwei weitere Alerts adressieren Verhaltenssprünge einzelner Konten: der Sprung bei der Anzahl unterschiedlicher Anwendungs-Ressourcen-Kombinationen (T1087, klassische Erkundung nach erfolgreichem Diebstahl einer Sitzung) und die verdächtige Anmeldung eines Benutzers mit auffällig vielen Kontoaktualisierungen, darunter das Entfernen von MFA-Methoden. Letzteres ist genau die Stelle, an der aus einem gestohlenen Cookie eine dauerhafte Übernahme wird. Und schließlich die Massenlöschung von Benutzerkonten per Skript, erkannt unter anderem am Python-User-Agent, MITRE T1531. Das ist kein Aufklärungs-, sondern ein Sabotagesignal: Wenn das feuert, ist die Party vorbei und jemand räumt gerade auf.

Der strategisch interessanteste Punkt steckt in einem einzigen Alert: „SailPoint ISC – vermuteter Brute-Force-Angriff“. Defender for Identity verlässt damit sichtbar den Microsoft-Kosmos. Zusammen mit den Posture-Empfehlungen für Okta, PingOne, CyberArk und SailPoint sowie der Aufnahme von SaaS-Passwortrisiken aus Salesforce und ServiceNow in die Password-Protection-Seite im Juli ist die Botschaft klar: Microsoft will nicht mehr nur dein AD und dein Entra ID sehen, sondern deine gesamte Identitätslandschaft. Ob dir das gefällt, ist eine strategische Frage. Dass es passiert, ist keine.

Die neuen Alerts der Juni-Welle, einsortiert nach Signalquelle und Angriffsphase.

Der zweite Teil der Geschichte ist die Plattform darunter. Seit Juli ist die Migration der Sensoren von v2.x auf v3.x allgemein verfügbar, inklusive der vorher ausgenommenen Domain Controller unter Windows Server 2025. Die Migration startest du aus dem Defender-Portal, sie dauert bis zu 20 Minuten pro Server, und der alte Sensor läuft weiter, bis der neue übernimmt – also kein Wartungsfenster im klassischen Sinne. Neu ist auch, dass dir das Portal per Tooltip verrät, warum ein Server als „nicht migrationsbereit“ gilt, statt dich raten zu lassen. Wer schon einmal drei Stunden mit dem Vergleich von Patchständen verbracht hat, weiß diese kleine Textzeile sehr zu schätzen.

Entscheidend für die Erkennungsqualität ist das erweiterte RPC-Auditing. Ohne das laufen mehrere der fortgeschrittenen Detektionen schlicht ins Leere – der Alert existiert, das Rohmaterial fehlt. Bis zum Frühjahr musstest du dafür manuell ein Tag setzen; ab Sensorversion 3.0.8 aktiviert der Sensor die Konfiguration selbst. Der zugehörige Health-Alert „Sensor v3.x RPC Audit Misconfigured“ wird seit Januar schrittweise ausgerollt und ist momentan der ehrlichste Freund, den dein Identitätsbetrieb hat. Hör auf ihn.

Sieben Monate, mehrere Wellen, rund 46 neue Alerts – und die Plattform-Meilensteine dazu.

Was sind Chancen? Was sind Risiken?

Die größte Chance ist banal und wird trotzdem regelmäßig liegen gelassen: Du bekommst Erkennungen für Angriffspfade, die du bisher nur mit handgeschnitzten Abfragen und viel Optimismus abgedeckt hast – ohne Aufpreis, ohne Projekt, ohne Ausschreibung. Wer eine eigene DCSync-Regel gebaut hat, kann sie jetzt gegen die Microsoft-Variante fahren und im Zweifel abschalten. Das ist gelebte Betriebsentlastung, und Betriebsentlastung ist die einzige Währung, in der ein SOC-Team wirklich rechnet.

Die zweite Chance liegt in der Kombination mit dem Identity Risk Score, der seit Juni allgemein verfügbar ist. Der Wert von 0 bis 100 speist sich aus Kritikalität und privilegierten Rollenzuweisungen und steht in Entra ID zur Verfügung – er kann also bedingten Zugriff und Identity-Protection-Abläufe steuern. Damit wird aus „Alert im Portal“ endlich „Sitzung beendet, Zugriff verweigert“. Genau an diesem Punkt entwickeln sich Zero-Trust-Roadmaps von PowerPoint zu Produktivbetrieb.

Dritte Chance: die Öffnung zu Fremdanbietern. Wenn in deinem Konzern die HR-Seite auf SailPoint läuft, das Kundenportal auf Okta und alles andere auf Entra ID, hattest du bisher drei Konsolen und keinen zusammenhängenden Angriffspfad. Diese Lücke schließt sich – langsam. Langsam ist hier das Schlüsselwort: Ein Brute-Force-Alert ist noch keine Abdeckung, sondern eine Absichtserklärung mit Produktnummer.

Und jetzt die Risiken. Erstens sind verhaltensbasierte Alerts statistisch, nicht deterministisch. Der Sprung bei App-Resource-Kombinationen feuert auch dann, wenn der neue Kollege aus dem Einkauf am ersten Tag beherzt jedes System ausprobiert. Wer solche Alerts ungefiltert in ein Ticketsystem kippt, produziert Alarmmüdigkeit – und Alarmmüdigkeit ist die zuverlässigste Angriffsunterstützung, die es gibt, günstiger als jedes Zero-Day.

Zweitens ist der Rollout gestaffelt. Microsoft liefert nicht an alle Tenants gleichzeitig. Deine Dokumentation kann also korrekt sein und das Portal des Kunden trotzdem anders aussehen. Plane keine Abnahme auf ein Feature, das du im eigenen Tenant siehst und in seinem noch nicht.

Drittens – und das ist das teuerste Risiko: Wer sich auf neue Alerts verlässt und die Hygiene weiter treiben lässt, hat die Erkennung verbessert, nicht die Angriffsfläche. Ein Entra-Connect-Konto mit Replikationsrechten bleibt ein Entra-Connect-Konto mit Replikationsrechten, auch wenn Defender jetzt hübsch meldet, dass jemand es benutzt. Detektion ersetzt keine Tier-0-Disziplin, sie dokumentiert nur deren Abwesenheit.

Was müssen wir jetzt schon vorbereiten?

Der erste Schritt ist unspektakulär und fehlt trotzdem am häufigsten: Bestandsaufnahme der Sensoren. Welche Version läuft wo, welcher Server ist migrationsbereit, welche Health-Alerts stehen offen? Ziel ist v3.x auf allen Domain Controllern, mindestens 3.0.8, damit RPC-Auditing automatisch greift. Die Migration ist seit Juli allgemein verfügbar und läuft ohne Ausfall – es gibt also keine gute Ausrede mehr, und schlechte Ausreden hält die Geschäftsführung nach dem ersten Vorfall erfahrungsgemäß nur sehr kurz aus.

Zweitens gehören die neuen Alert-IDs in deine Hunting-Historie. Fahre sie rückwirkend gegen die letzten 90 Tage, bevor du Playbooks schreibst. Du willst wissen, wie oft jeder Alert in deiner Umgebung realistisch feuert, bevor der erste Analyst um drei Uhr nachts entscheiden muss, ob er einen Global Admin sperrt. Ohne Basislinie ist jedes Playbook geraten, und Raten skaliert schlecht.

Drittens: Kläre die Berechtigungen für Remediation-Aktionen. Defender for Identity legt dafür eine eigene Unternehmensanwendung in Entra ID an und autorisiert die Aktion über die Entra-Rollen des auslösenden Benutzers. Unterstützt werden unter anderem Benutzeradministrator, Authentifizierungsadministrator, Privilegierter Authentifizierungsadministrator, Verzeichnisautoren, Helpdesk-Administrator und Sicherheitsoperator. Wenn deine Analysten keine dieser Rollen haben, können sie wunderbar Alerts betrachten, aber nichts abstellen – ungefähr so nützlich wie ein Rauchmelder ohne Türschlüssel.

Viertens: Kritikalität pflegen. Der Identity Risk Score bewertet unter anderem die Kritikalitätsstufe der Identität. Wenn bei dir alles „normal“ ist, ist der Score eine Zufallszahl mit guter Grafik. Markiere Entra-Connect-Konten, Break-Glass-Konten, AD-Dienstkonten in privilegierten Gruppen und die klassischen Tier-0-Systeme als das, was sie sind. Die Posture-Bewertungen aus dem Januar-Release – verwaiste Konten, Dienstkonten in privilegierten Gruppen, doppelt privilegierte Identitäten in Entra und AD – liefern dir die Liste frei Haus.

Fünftens: Üben. Eine Purple-Team-Runde mit DCSync-Simulation, einer TAP-Kette zwischen zwei Testkonten und einer gescripteten Löschaktion im Testtenant kostet einen Tag und beantwortet drei Fragen auf einmal: Feuert der Alert überhaupt? Wie lange dauert es bis zur Triage? Und greift die Automatik oder schaut sie nur höflich zu?

Drei Sprints von der Release-Notiz zum belastbaren Playbook.

Häufig gestellte Fragen

Muss ich für die neuen Defender-for-Identity-Alerts zusätzlich lizenzieren?

Nein. Die neuen Erkennungen gehören zum bestehenden Umfang von Defender for Identity und werden ohne Zusatzkosten in die Tenants ausgerollt. Aufwand entsteht nicht durch Lizenzen, sondern durch Sensoraktualisierung, Audit-Konfiguration und die Anpassung deiner Playbooks.

Warum sehe ich einen angekündigten Alert in meinem Portal noch nicht?

Microsoft rollt Defender-for-Identity-Funktionen schrittweise über die Tenants aus, es kann also mehrere Wochen dauern, bis eine Neuerung bei dir ankommt. Zusätzlich setzen einige Detektionen eine aktuelle Sensorversion und korrekt konfiguriertes RPC- beziehungsweise Windows-Ereignis-Auditing voraus – fehlt die Datenbasis, feuert der Alert nie.

Wie riskant ist die Migration der Sensoren von v2.x auf v3.x im laufenden Betrieb?

Die Migration ist seit Juli 2026 allgemein verfügbar, wird aus dem Defender-Portal gestartet und dauert pro Server bis zu 20 Minuten. Der alte Sensor läuft währenddessen weiter, bis der neue übernimmt, sodass keine Überwachungslücke entsteht – Voraussetzung ist ein aktueller Windows-Patchstand auf dem Domain Controller.

Was tue ich als Erstes, wenn der DCSync-Alert feuert?

Prüfe zuerst, ob die Quell-IP zu einem legitimen Domain Controller gehört; wenn nicht, isoliere das Quellsystem und behandle jeden dort verwendeten Zugang als kompromittiert. Danach folgt die unangenehme Frage nach dem krbtgt-Konto: Bei bestätigtem Abfluss führt kein Weg an einem zweifachen krbtgt-Reset mit korrektem zeitlichen Abstand vorbei.

Lohnt sich die Anbindung von Fremdanbietern wie SailPoint oder Okta jetzt schon?

Für Umgebungen mit mehreren Identity Providern lohnt sich der Konnektor bereits, weil Posture-Empfehlungen, Passwortrisiken und Identitätsinventar quellenübergreifend zusammenlaufen. Die Detektionstiefe ist bei Fremdanbietern aber noch deutlich geringer als bei Entra ID und Active Directory – rechne mit einer Ergänzung, nicht mit einem Ersatz für die dortige Überwachung.