In vielen Tenants, die ich betreue, kommt die Live-Response-Funktion von Defender beim ersten echten Vorfall zum ersten Mal zum Einsatz, und das meist unter Zeitdruck. In Microsoft Defender for Endpoint Plan 2 schlägt plötzlich ein kritischer Alarm an, das SOC ruft an, und das betroffene Gerät muss sofort vom Netz. Zwischen dem, was in der Theorie möglich ist, und dem, was ein Team dann tatsächlich umsetzen kann, liegt oft eine große Lücke. Das gilt besonders für die Details der Geräteisolation, den Umgang mit Live Response und die forensische Nachbereitung. Im Folgenden beschreibe ich, wie ich ein solches Vorgehen in der Praxis aufbaue, welche Kniffe sich bewährt haben und an welchen Stellen man gern stolpert.

Die vollständige Isolation ist in den meisten Fällen die bessere Wahl

Ein kompromittiertes Gerät muss von der Umgebung getrennt werden, soll sich aber weiterhin über Defender verwalten lassen. Dazu öffnet man im Defender-Portal die Geräteübersicht, wählt unter „Aktionen“ den Punkt „Gerät isolieren“ und entscheidet sich anschließend für die vollständige oder die selektive Isolation. Bei der vollständigen Isolation ist das Gerät praktisch vom Netzwerk abgeschnitten, lediglich der Datenverkehr zu den Defender-Diensten bleibt bestehen. Die selektive Variante lässt dagegen bestimmte Verbindungen zu, etwa zu einzelnen Managementsystemen. In beiden Modi stehen Live-Response-Aktionen weiter zur Verfügung, solange das Gerät mit Microsoft Defender kommunizieren kann. Ich rate in der Regel zur vollständigen Isolation, sofern dadurch keine kritische Produktion ausfällt. Wie sich solche Maßnahmen automatisieren lassen, lest ihr in meinem Beitrag zur automatischen Angriffsunterbrechung in Defender XDR.

flowchart TD
    Start["Alarm auf Gerät"] --> Isolation["Gerät isolieren (voll/selektiv)"]
    Isolation --> RestrictApps["App-Ausführung einschränken"]
    RestrictApps --> Investigation["Investigation Package sammeln"]
    Investigation --> LiveResponse["Live Response Session starten"]
    LiveResponse --> Doku["Maßnahmen dokumentieren"]

Abbildung: So läuft eine Live-Response-Sitzung bei einem Vorfall auf einem Endpunkt typischerweise ab.

Die App-Einschränkung wird im Ernstfall gern vergessen

Solange niemand weiß, ob weitere Schadsoftware nachgeladen werden kann, leistet die Defender-Funktion „App-Ausführung einschränken“ gute Dienste. Man löst sie im Portal direkt für das betroffene Gerät aus. Danach lassen sich keine neuen Programme mehr starten, bereits laufende Prozesse arbeiten aber weiter. Einen kompletten Lockdown bedeutet das nicht. Es verhindert jedoch zuverlässig, dass ein Angreifer zusätzliche Werkzeuge auf das System holt. Zu finden ist die Option im Defender-Portal auf der Gerätekarte unter „Aktionen“ → „App-Ausführung einschränken“. Sie setzt Defender for Endpoint Plan 2 und aktivierte erweiterte Funktionen voraus.

Das Investigation Package sichert die forensischen Spuren mit wenigen Klicks

Ist das Gerät isoliert, fordere ich als Nächstes fast immer ein Investigation Package an. Darin stecken Speicherabbilder, Logdateien und weitere Artefakte, ohne die eine spätere Analyse kaum möglich wäre. Auch dieses Paket wird über die Aktionsleiste im Geräteportal angefordert. Bis es bereitsteht, können durchaus einige Minuten vergehen, und so lange muss das Gerät erreichbar bleiben. Wer den Vorgang automatisieren möchte, findet in den APIs von Defender for Endpoint die passenden Schnittstellen. Für die meisten Fälle genügt aber das Portal. Die Pakete sind übrigens verschlüsselt. Das Passwort zeigt Defender bei der Bereitstellung an, und es sollte unbedingt in die Dokumentation wandern.

Praxis-Tipp: Auch wenn es eilt, wartet beim Investigation Package immer ab, bis der Download vollständig ist. Erst danach sollte das Gerät aus dem Bestand entfernt oder eine weitergehende forensische Untersuchung gestartet werden. Andernfalls unterbrecht ihr die Beweiskette selbst.

Live-Response-Sitzungen setzen passende Einstellungen und Rechte voraus

Während das Gerät isoliert ist, startet man im Defender-Portal auf der Gerätekarte über „Live Response“ eine Sitzung. Vorher muss die Funktion unter Einstellungen → Endpunkte → Erweiterte Funktionen eingeschaltet und das Häkchen bei „Live Response“ gesetzt sein. Eigene Skripte, auch unsignierte, laufen nur, wenn das an derselben Stelle ausdrücklich erlaubt ist. Weil das ein Risiko darstellt, sollten nur erfahrene Analysten diese Freigabe erhalten. Die Berechtigungen vergibt man über das einheitliche RBAC-Modell von Defender (Microsoft Defender Portal → Einstellungen → Berechtigungen). Mindestens nötig ist die Rolle „Live Response“ oder „Benutzerdefinierte Ermittlungen“.

Nützliche Live-Response-Befehle sind zum Beispiel:

  • processes – zeigt alle laufenden Prozesse an,
  • getfile – holt einzelne Dateien gezielt vom Gerät (praktisch bei verdächtigen DLLs oder Skripten),
  • run – startet Skripte aus der Bibliothek (sofern aktiviert und erlaubt).

Welche Befehle aktuell zur Verfügung stehen, steht vollständig in der Dokumentation von Microsoft. Häufig genügt schon ein kurzer Blick auf die Prozessliste und das Einsammeln verdächtiger Dateien, um eine erste Vermutung zu bestätigen oder zu verwerfen.

So sammelt man beispielsweise eine verdächtige Datei ein:

getfile C:\Users\Public\Downloads\suspect.exe

Den Befehl gibt man direkt in der Live-Response-Konsole ein (Defender-Portal → Geräte → Gerät auswählen → Live Response starten).

Jeder Schritt gehört sofort in die Incident-Timeline

Wer mitten in einem Vorfall steckt, vergisst schnell, die eigenen Schritte sauber festzuhalten. Deshalb trage ich schon während der Live Response in die Incident-Timeline im Defender-Portal ein, was ich getan habe, also Isolation, App-Einschränkung, angeforderte Pakete, heruntergeladene Dateien und ausgeführte Skripte. Das Incident-Response-Team kann so jederzeit nachvollziehen, was passiert ist. Gleichzeitig bilden diese Notizen die Grundlage für spätere Auswertungen und für die Weiterentwicklung der eigenen Playbooks. Wer mit eigenen Erkennungsregeln arbeitet, kann diese etwa nach den Methoden aus meinem Beitrag zu benutzerdefinierten Erkennungsregeln in Defender XDR direkt dokumentieren und fortlaufend anpassen.

Eingeübte Abläufe sind im Ernstfall mehr wert als jede Hektik

Defender Live Response ist ein starkes Werkzeug. Sein Potenzial entfaltet es aber erst, wenn Prozesse, Rechte und technische Voraussetzungen schon vor dem Vorfall passen. Viel zu oft erlebe ich, dass jemand die Aktivierung der Funktion, die RBAC-Einrichtung oder den Umgang mit Investigation Packages erst im Ernstfall ausprobiert, und die Folgen kennt jeder, der so etwas schon einmal mitgemacht hat. Teams, die regelmäßig testen, ihre Playbooks durchspielen und die wichtigsten Befehle beherrschen, reagieren in der Krise schneller und sicherer und dokumentieren sauberer. Ein paar Trockenübungen mehr sind deshalb allemal besser, als im Ernstfall improvisieren zu müssen.