Wenn ich in Projekten die „automatische Angriffsunterbrechung“ in Microsoft Defender XDR anspreche, ernte ich oft fragende Blicke. Dass automatische Reaktion und Blockierung verlockend klingen, versteht jeder. Unklar ist meist, wie die Komponenten in der Praxis zusammenspielen und wann Defender XDR tatsächlich eingreift. In vielen Tenants, die ich betreue, ist das Feature noch ein blinder Fleck in der Security-Konfiguration. Dabei nehmen gezielte, von Menschen gesteuerte Angriffe wie Ransomware, Business Email Compromise (BEC) und AiTM-Phishing ständig zu und richten immer mehr Schaden an.

Defender XDR stoppt erkannte Angriffe schon während der Ausführung

Die automatische Angriffsunterbrechung soll Angriffe, die mit sehr hoher Sicherheit erkannt werden („high-confidence detections“), noch während der Ausführung stoppen. Man wartet also nicht, bis die Analyse im Nachhinein läuft. Defender XDR wertet dafür Signale von Endpoints, Identitäten und E-Mail gemeinsam aus. Stößt das System auf typische Muster für menschlich gesteuerte Ransomware, BEC, AiTM-Phishing oder Password Spraying, handelt es selbstständig: Es isoliert kompromittierte Endpoints, sperrt gefährdete Konten oder beendet aktive Sitzungen sofort. Die Grundlagen beschreibt die offizielle Microsoft-Dokumentation, viele Details versteht man allerdings erst im laufenden Betrieb und mit etwas Erfahrung.

Ich habe selbst miterlebt, wie eine Angriffsunterbrechung Endgeräte isoliert, Benutzer in Entra ID oder im lokalen Active Directory deaktiviert und Sitzungen widerruft, und das wenige Minuten nach der Erkennung. Seine Stärke spielt das Feature vor allem beim Lateral Movement aus, wenn Angreifer sich im Netzwerk ausbreiten wollen. Nicht jeder Alarm löst diese Aktionen aus. Dafür braucht es eine als „high-confidence“ eingestufte Erkennung, die in der Regel erst durch die Korrelation mehrerer Signale entsteht.

Mehrere Defender-Produkte müssen sauber zusammenspielen

Zuverlässig funktioniert die automatische Angriffsunterbrechung nur, wenn mehrere Defender-Komponenten im Tenant aktiv und korrekt integriert sind. Im Einzelnen sind das:

  • Microsoft Defender for Endpoint auf Windows-Clients und Servern, im „Block-Modus“ mit aktivierter automatischer Untersuchung
  • Defender for Identity (Sensoren auf den Domain Controllern, Action Account konfiguriert)
  • Defender for Office 365 (Plan 2, für E-Mail-Schutz und BEC-Erkennung)
  • Defender for Cloud Apps (Konnektoren für Entra ID und Exchange Online)

Erst mit dieser Kombination kann Defender XDR Geräte isolieren, Benutzer sperren und Sitzungen beenden. Fehlen sauber eingerichtete Sensoren oder Berechtigungen, etwa für den Action Account bei Identitätsmaßnahmen, bleibt das Feature wirkungslos oder einzelne Aktionen tauchen gar nicht erst auf. Welche Pfade und Anforderungen jeweils gelten, steht in der Konfigurationsanleitung von Microsoft. In meinen Projekten stolpern Teams am häufigsten über den Action Account.

Praxistipp: Prüft regelmäßig, ob Defender for Identity tatsächlich alle Domänencontroller überwacht und ob dem Action Account keine Passwort- oder Anmeldesperre droht. Ein einziger vergessener Sensor reicht, damit Benutzersperrungen im Ernstfall ins Leere laufen.

In älteren oder hybriden Umgebungen lohnt es sich, die Integration schrittweise zu testen. Gut eignet sich dafür die simulierte Kompromittierung eines Testkontos.

Jede automatische Maßnahme landet im Action Center und im Incident

Wie die Komponenten zusammenwirken, zeigt ein einfaches Ablaufdiagramm. So sieht der Weg von der Erkennung bis zur Reaktion in der Praxis aus:

flowchart TD
    Angriff["Angriff erkannt"] --> Korrelation["Signale korrelieren"]
    Korrelation --> HighConf["High-Confidence-Detektion"]
    HighConf --> Aktion["Automatische Gegenmaßnahme"]
    Aktion --> Isolieren["Gerät isolieren"]
    Aktion --> UserSperren["Benutzer sperren"]
    Aktion --> SessionRevoke["Session widerrufen"]
    Aktion --> InfoAdmin["Admin benachrichtigen"]

Abbildung: Typischer Ablauf einer automatischen Angriffsunterbrechung in Defender XDR.

Jede dieser Maßnahmen dokumentiert Defender XDR im Action Center (Microsoft Defender-Portal → Aktionen). Dort ist nachzulesen, wann welche automatische Aktion lief, welchen Benutzer oder welches Gerät sie betraf und ob sie erfolgreich war. Die Einträge erscheinen außerdem im zugehörigen Incident (Vorfall), mit allen Details und der Option, die Aktion zurückzunehmen. Einen Benutzer entsperren oder die Isolation eines Endgeräts aufheben lässt sich direkt im Action Center. Bei Fehlalarmen oder besonders kritischen Konten ist das unverzichtbar.

Ausschlüsse für kritische Konten sollten die Ausnahme bleiben

So verlockend die Automatik ist: Niemand will erleben, dass ausgerechnet der CFO oder ein Break-Glass-Account mitten im Monatsabschluss gesperrt wird. Defender XDR erlaubt es deshalb, kritische Konten von den Maßnahmen auszunehmen. Die Einstellung findet man unter Einstellungen → Microsoft Defender XDR → „Identity automated response“ (Identitätsautomatisierte Reaktion). Dort lassen sich beispielsweise Notfall- oder Dienstkonten eintragen, die nie automatisch deaktiviert werden dürfen. Jeder Ausschluss bedeutet aber ein mögliches Risiko, und ich sehe in Projekten häufig, dass viel zu großzügig ausgenommen wird. Mehr als zwei echte Notfallkonten sollten es nicht sein, und der Prozess dahinter gehört ordentlich dokumentiert.

Welche Konten von der automatischen Sperrung ausgenommen sind, zeigt das Defender-XDR-Portal unter den genannten Einstellungen. Diese Liste sollte man in regelmäßigen Abständen kontrollieren und anpassen, sobald sich im Admin-Team etwas ändert.

Die Automatisierung hat sich in meinen Projekten bezahlt gemacht

Mit der automatischen Angriffsunterbrechung ist Microsoft Defender XDR der „autonomen Verteidigung“ ein gutes Stück näher gekommen. Das gilt allerdings nur, wenn die Einrichtung stimmt und jemand regelmäßig hinschaut. Ihren vollen Nutzen entfalten die automatischen Maßnahmen im Zusammenspiel mit Unified Incidents: Das kompromittierte Gerät wird isoliert, der betroffene Benutzer gesperrt, und sämtliche aktiven Sitzungen werden blockiert, bevor sich der Angreifer im Netzwerk ausbreiten kann. In den meisten Umgebungen zeigt erst die praktische Erfahrung, wie viel von sauberen Sensoren, einem getesteten Action Account und klaren Ausschlussregeln abhängt. Wer sich zum ersten Mal mit der Konfiguration befasst, findet in meinem Beitrag zu Defender XDR Unified Security einen guten Überblick über die Zusammenhänge.

Security Awareness und ein funktionierendes Incident-Response-Team kann die Automatisierung nicht ersetzen. Sie verschafft aber oft die entscheidenden Minuten, und im Ernstfall zählen genau die.