Microsoft Defender for Endpoint: Finetuning

Wenn Defender for Endpoint (MDE) erst einmal ausgerollt und die AV-Konfiguration steht, beginnt die eigentliche Arbeit: das Finetuning. Genau hier trennt sich eine Standardinstallation von einer wirklich abgehärteten Umgebung. In diesem Teil geht es um die Punkte, die man nach dem Onboarding angeht, um MDE zu einem geschlossenen Sicherheitssystem auszubauen – vom Entfernen lokaler Adminkonten über die Integration der übrigen Defender-Produkte, Advanced Hunting mit eigenen Erkennungsregeln, Automatisierung per Logic Apps und Sentinel, Attack Disruption bis hin zu den häufigsten Fehlern aus realen Projekten und der abschließenden Validierung. Die Beispiele beziehen sich durchgehend auf Defender for Endpoint Plan 2 – alle P1-Funktionen sind darin ohnehin enthalten.

Lokale Adminkonten entfernen

Lokale Administratorkonten auf Endgeräten sind ein klassisches Einfallstor für laterale Bewegung und Credential-Diebstahl. Wer LAPS (Local Administrator Password Solution) oder EPM (Endpoint Privilege Management) einsetzt, will sicherstellen, dass außer diesen verwalteten Konten keine weiteren lokalen Admins mehr existieren. Genau das lässt sich über eine Richtlinie erzwingen.

LocalUsersAndGroups-Policy per CSP

Grundlage ist der LocalUsersAndGroups Policy CSP. Über eine entsprechende Intune-Richtlinie wählt man zunächst die lokale Standardgruppe aus, die auf dem Endgerät bearbeitet werden soll (typischerweise die Gruppe Administratoren). Anschließend definiert man eine Aktion. Zur Auswahl stehen drei Varianten:

1. Add (Update)
2. Remove (Update)
3. Add (Replace)

Der entscheidende Unterschied liegt im Zusatz hinter der Aktion:

• Die Varianten mit (Update) löschen keine anderen Mitglieder der Gruppe. Sie fügen jeweils nur einen definierten User hinzu (Add) oder entfernen einen definierten User (Remove).
• Die Variante Add (Replace) ist die entscheidende: Sie fügt den definierten User der Gruppe hinzu und entfernt gleichzeitig alle anderen Mitglieder. Damit räumt man die Gruppe zuverlässig auf.

Beim User-Selection-Type legt man fest, wen man in die Gruppe aufnimmt. Möglich sind zwei Wege:

• Auswahl eines vorhandenen Users bzw. einer vorhandenen Gruppe aus Entra ID / Active Directory.
• Der Modus Manual, bei dem man einen Account selbst frei definiert – etwa das dedizierte LAPS-Admin-Konto.

Kombiniert man also die Standardgruppe Administratoren mit Add (Replace) und dem LAPS-Konto als definiertem User, ist danach ausschließlich das gewünschte, verwaltete Admin-Konto Mitglied der lokalen Administratorengruppe – alle anderen (womöglich historisch gewachsenen) lokalen Admins fliegen automatisch heraus.

Integration anderer Produkte

MDE entfaltet seine volle Leistung erst im Zusammenspiel mit den übrigen Sicherheitskomponenten der Microsoft-Umgebung. Die Integration mit Intune (Bereitstellung und Verwaltung der Defender-Funktionen) wurde bereits in früheren Teilen behandelt. Hier geht es um die Vernetzung mit den anderen Defender-Diensten:

• Defender for Office 365 – gemeinsame Bedrohungsüberwachung von E-Mails und Endpunkten.
• Defender for Identity – Erkennung von Identitätsbedrohungen.
• Defender for Cloud Apps – Analyse von Cloud-Anwendungen und Synchronisation unsicherer Apps.
• Microsoft Sentinel – zentrales SIEM (Security Information and Event Management).
• Defender for Cloud (früher Azure Defender) – Schutz für Cloud-Server.

Durch diese Vernetzung erreicht man eine bessere Erkennung und umfassendere Gegenmaßnahmen, weil Signale aus mehreren Quellen korreliert werden.

Defender for Office 365

Die Integration mit Defender for Office 365 schafft einen ganzheitlichen Blick über E-Mail-Sicherheit und Endpunktschutz hinweg. Voraussetzung ist eine aktive Lizenz für Defender for Office 365 Plan 2. Analysten, die Bedrohungen untersuchen, brauchen Zugang zu beiden Datenbereichen, damit im Threat Explorer alle relevanten Informationen erscheinen.

Wichtig: Seit Januar 2021 ist keine manuelle Konfiguration mehr nötig. Die Verbindung zwischen MDE und Defender for Office 365 Plan 2 ist standardmäßig in den Microsoft-Defender-Diensten enthalten und immer aktiv. Die früher notwendigen Schalter in den Advanced Features entfallen – Defender for Office 365 nutzt automatisch die Endpoint-Daten für erweiterte Analysen und Reaktionsmaßnahmen.

Defender for Identity

Defender for Identity (früher Azure ATP) erkennt identitäts- und infrastrukturbasierte Angriffe. Die Integration findet heute im Microsoft-Defender-Portal statt. Seit November 2022 ist keine zusätzliche Konfiguration mehr erforderlich: Beide Produkte sind nativ mit security.microsoft.com verbunden. Sobald man sie über das gemeinsame Portal verwaltet, sind ihre Daten miteinander verknüpft – Alerts aus beiden Systemen erscheinen zentral, ohne weitere Einstellungen. Relevant ist das vor allem dort, wo Defender for Identity tatsächlich eingesetzt wird (in älteren Dokumentationen als MDI-Integration bezeichnet).

Defender for Cloud Apps

Defender for Cloud Apps (früher Microsoft Cloud App Security) lässt sich mit MDE verbinden, um Informationen über genutzte Cloud-Anwendungen auszutauschen. Konkret verwendet Defender for Cloud Apps die Telemetrie des Endgerätsensors, um festzustellen, welche Cloud-Apps auf einem Gerät genutzt werden. Ist die Integration aktiv, sendet MDE seine Protokolle direkt an Defender for Cloud Apps.

Voraussetzungen:

• Lizenzen: Eine Lizenz für Defender for Cloud Apps und mindestens Defender for Endpoint Plan 2.
• Betriebssystem: Unterstützt sind Windows 10 (ab Version 1709 mit bestimmten Updates) und Windows 11. Konkret werden Builds ab 16299.1085 (mit KB4493441), 17134.704 (mit KB4493464) oder 17763.379 (mit KB4489899) benötigt.
• Netzwerkkonfiguration: Damit blockierte Apps tatsächlich gestoppt werden, muss in den MDE-Network-Protection-Einstellungen der Block-Modus aktiv sein. Andernfalls wird die URL nur protokolliert, aber nicht geblockt.

Einrichtung:

1. Aktivieren in MDE: Im Defender-Portal unter Einstellungen → Erweiterte Funktionen den Schalter Microsoft Defender for Cloud Apps auf Ein setzen.
2. Enforce App Access: Im Defender-for-Cloud-Apps-Portal unter den MDE-Einstellungen die Option Enforce App Access aktivieren. Dadurch werden alle als unsanctioned markierten Apps automatisch als Indikatoren mit Status Block an MDE übergeben und die betreffenden URLs/Domains direkt auf den Endgeräten gesperrt.
3. Vor dem Aktivieren prüfen: Unbedingt vorher kontrollieren, welche Apps bereits als unsanctioned gelistet sind. Beim Einschalten der Synchronisierung werden alle aktuell unsanctioned Apps blockiert – produktive Apps auf dieser Liste würden sonst unbeabsichtigt gesperrt.
4. Beispiel: Markiert man etwa WhatsApp als unsanctioned, taucht es in MDE unter Indikatoren → URLs/Domains auf – Typ URL, Titel „Unsanctioned cloud app access was blocked", Created by = Microsoft Defender for Cloud Apps.
5. Scope-Profile: Standardmäßig gilt die Block-Regel für All Devices. Über App-Tags legt man ein Profil (z. B. „Blocking Profile") an und definiert per Include/Exclude, welche Gerätegruppen betroffen sind. Beim Markieren einer App wählt man dieses Profil – der Indikator wird dann nur für die festgelegten Gruppen bereitgestellt.

Microsoft Sentinel

Microsoft Sentinel ist ein cloudbasiertes SIEM und lässt sich über Daten-Connectoren mit MDE verbinden. Für den Import stehen zwei Wege bereit:

• Microsoft-Defender-XDR-Connector: Liefert sämtliche Sicherheitsereignisse (Ereignisse und Vorfälle) aus der gesamten Defender-Instanz – über alle verbundenen Lösungen (Endpoint, Office, Cloud Apps usw.). Der Connector ist bidirektional: Schließt man einen Vorfall in Sentinel, wird er auch in Defender XDR geschlossen und umgekehrt. Für Alarm- und Vorfallerstellung ist das der empfohlene Weg. Optional lässt sich die komplette Rohtelemetrie streamen – allerdings mit zusätzlichen Ingestionskosten.
• Defender-for-Endpoint-Connector: Der klassische Connector liefert vorrangig die Endpoint-Alerts nach Sentinel. Er ist nicht bidirektional und enthält keine erweiterten Telemetriedaten.

Die Verbindung ist unkompliziert: In Sentinel Daten-Connectoren öffnen, den gewünschten Connector auswählen, auf Verbinden klicken und den Anweisungen folgen. Danach erhält Sentinel automatisch die neuen Alerts. Beim Erfassen zusätzlicher Telemetrie entstehen erhebliche Datenmengen und Kosten – daher nur die tatsächlich benötigten Ereignistypen aktivieren.

Längere Datenspeicherung

Standardmäßig speichert MDE seine Daten nur begrenzt: 180 Tage Retention für normale Ereignisse, aber nur 30 Tage für Advanced-Hunting-Abfragen. Für eine längere Aufbewahrung gibt es zwei Hauptoptionen:

• Microsoft Sentinel: Weiterleitung ausgewählter MDE-Ereignisse an Log Analytics. Hoher Funktionsumfang, aber Ingestions- und Speicherkosten. Sinnvoll, wenn ohnehin ein zentrales SIEM genutzt wird.
• Streaming API (Azure): Über die Streaming-API von Defender XDR lassen sich Ereignisse direkt in ein Azure Storage Account oder einen Event Hub exportieren. Damit kann man die Daten quasi unbegrenzt zu Standard-Speicherkosten aufbewahren – ohne zusätzliche Analysegebühren. Nachteil: Die Daten liegen in Rohform vor und müssen bei Bedarf selbst analysiert werden.

Die Konfiguration der Streaming API erfolgt im Defender-Portal auf Event-Typ-Ebene: Für jeden Datentyp (z. B. Devices, Alerts) legt man ein Exportziel (Storage Account oder Event Hub) fest. Der Device-Datentyp speichert alle Geräteinformationen, der Alerts-Datentyp alle Alert-Details und -Beweise.

Advanced Hunting & Erkennungsregeln

Advanced Hunting ist ein abfragebasiertes Tool im Defender-Portal, mit dem man alle Rohdaten der Sensoren durchsuchen kann. Jeder Sensor sendet Telemetrie und Ereignisse direkt an die Defender-Instanz; Gerätedaten (DeviceEvents) und Warnmeldungen (AlertInfo/AlertEvidence) sind sofort abrufbar. Advanced Hunting eignet sich nicht nur für Threat Hunting, sondern auch zur Validierung des Defender-Zustands.

Grundlagen und KQL

Advanced Hunting basiert auf der Kusto Query Language (KQL) – einer von Microsoft entwickelten Abfragesprache, die u. a. in Log Analytics, Sentinel, MDE und Azure Data Explorer zum Einsatz kommt. Weil viele Microsoft-365-Sicherheitsprodukte in einem Portal zusammengeführt sind, lassen sich die Daten einheitlich durchsuchen. Typische Validierungs-Abfragen sind etwa:

• Alle Geräte anzeigen, bei denen MAPS (Microsoft Advanced Protection Service) nicht konfiguriert ist.
• Alle Geräte mit veralteten Versionsständen anzeigen.
• Alle Geräte anzeigen, bei denen das neueste Update fehlt.
• Überwachungsereignisse für Attack Surface Reduction (ASR) anzeigen.
• Über SmartScreen blockierte Netzwerkverbindungen anzeigen.

Advanced Hunting bietet zwei Modi:

• Erweiterter Modus = Abfrage direkt im Editor (KQL-Code).
• Geführter Modus = Abfrage im visuellen Query Builder – ideal für Einsteiger ohne KQL-Kenntnisse.

Über „Edit in KQL" lässt sich eine im Builder erstellte Abfrage in KQL-Code umwandeln – ein guter Weg, die Sprache zu lernen. Empfehlenswert ist ohnehin, KQL zu beherrschen und den erweiterten Modus zu nutzen.

Datenquellen und Schemata

Zur Advanced-Hunting-Plattform gehören mehrere Produkte, jeweils mit eigenem Schema:

Typische Tabellen sind etwa DeviceInfo, AlertInfo oder EmailEvents. Die vollständige Schema-Referenz findet sich in der Microsoft-Dokumentation.

Bekannte Einschränkungen

Um den Dienst stabil zu halten, gelten mehrere Limits:

• Datenbereich: Abfragen greifen maximal auf die letzten 30 Tage zu – gleichermaßen für Advanced Hunting und Custom Detection Rules.
• Ergebnismenge: Eine Abfrage liefert höchstens 10.000 Datensätze. Deshalb immer gut filtern.
• Laufzeit: Jede Abfrage darf maximal 10 Minuten laufen, sonst bricht der Dienst mit einem Fehler ab.
• CPU-Ressourcen: Verbraucht eine Abfrage mehr als 10 % der zugewiesenen CPU-Kapazität, schlägt sie fehl. Ist die volle Mandantenkapazität (100 %) erreicht, werden bis zum nächsten 15-Minuten-Intervall keine Abfragen ausgeführt.

Ressourcen-Report und gespeicherte Abfragen

Über den Query Resources Report (oben rechts in Advanced Hunting) lassen sich alle ausgeführten Abfragen einsehen – sortiert nach Ressourcennutzung (CPU, Laufzeit). So findet man besonders aufwendige Abfragen und kann die Historie auditieren. Auch alte, noch nicht gespeicherte Abfragen lassen sich hier wiederfinden und erneut öffnen. Zu den Berechtigungen: Jeder Benutzer sieht seine eigenen Abfragen; nur Global Administrator, Security Administrator und Security Reader sehen die Abfragen aller Nutzer.

Eigene Abfragen speichert man im Bereich Queries über Save – wahlweise unter My queries (privat) oder Shared queries (für alle mit Defender-Zugriff). Ordner helfen bei der Strukturierung.

Benutzerdefinierte Erkennungsregeln

Eine der stärksten Funktionen ist das Erstellen von Custom Detection Rules auf Basis von Advanced-Hunting-Abfragen. Damit generiert man zusätzliche Alerts und automatisierte Reaktionen für Szenarien, für die Microsoft keinen Standard-Alert liefert. Typische Beispiele:

• Ein neuer lokaler Benutzer wurde angelegt.
• Umgehung von SmartScreen (User bestätigt eine potenziell gefährliche Seite).
• Installation verbotener Software.
• Remote-Tools installiert und ausgehend verbunden (z. B. AnyDesk, TeamViewer).
• Ein IoC aus einer öffentlichen Liste wurde gefunden (CSV-Abgleich).
• Start einer ausführbaren Datei oder eines Skripts aus einem ungewöhnlichen Ordner (z. B. C:\Users\Public\).
• Ausführung von cipher.exe auf dem System.

Jede Regel wird in regelmäßigen Abständen ausgeführt. Trifft die Abfrage auf Ergebnisse, generiert das System automatisch Alerts und kann vordefinierte Reaktionen auslösen (z. B. Geräte isolieren, Benutzer deaktivieren). Regeln erstellen dürfen Benutzer mit der Rolle Security Administrator oder Security Operator. Achtung: Ist das erweiterte RBAC-Modell aktiv, brauchen Security Operators zusätzlich die Berechtigung Manage security settings.

Damit eine Regel eine Erkennung auslöst, muss die Abfrage bestimmte Spalten liefern:

• Timestamp – Zeitpunkt des Ereignisses.
• ReportId – eindeutiger Berichtsschlüssel.
• Identifizierende Spalten – eine oder mehrere Spalten, die Geräte, Benutzer oder Mailboxen eindeutig identifizieren (z. B. DeviceId, AccountSid).

Eine Regel ist zudem so ausgelegt, dass sie pro Lauf höchstens 100 Alerts erstellt – so vermeidet man eine Flut von Meldungen.

Regel erstellen

Zunächst erstellt man die passende KQL-Abfrage im Editor und klickt dann auf Create detection rule. Im Dialog gibt man Name, Titel, Schweregrad, Kategorie, Beschreibung und Häufigkeit an. Verwende einen prägnanten Titel – vermeide generische Namen wie „Custom Detection 1".

Jede Regel prüft Ereignisse der letzten 30 Tage. Die Ausführungshäufigkeit steuert, welcher Zeitraum betrachtet wird:

Neu ist die Continuous (NRT) frequency: Near-Real-Time-Regeln generieren nahezu sofort Alerts. Voraussetzung ist, dass die Abfrage aus nur einer Tabelle besteht (keine Joins, Unions oder externen Daten). Unterstützte Tabellen für NRT-Regeln sind u. a. AlertEvidence, DeviceEvents, DeviceFileCertificateInfo, DeviceFileEvents, DeviceImageLoadEvents, DeviceLogonEvents, DeviceNetworkEvents, DeviceNetworkInfo, DeviceInfo, DeviceProcessEvents, DeviceRegistryEvents, EmailAttachmentInfo, EmailEvents, EmailPostDeliveryEvents, EmailUrlInfo und UrlClickEvents.

Im Rule-Wizard folgen weitere Schritte:

• Impacted entities: Auswahl der Spalten, die betroffene Geräte und Benutzer identifizieren – typischerweise DeviceId/DeviceName für Geräte, AccountSid für Benutzer. Der Assistent listet nur Spalten auf, die tatsächlich in der Abfrage vorkommen.
• Actions: Definition automatisierter Reaktionen. Für Geräte stehen u. a. Isolate device, Collect investigation package, Run antivirus scan, Initiate investigation und Restrict app execution zur Verfügung; für Benutzer, Dateien und E-Mails jeweils passende Optionen (Benutzer deaktivieren, Datei in Quarantäne verschieben, E-Mail verschieben).

Für jede Aktionskategorie müssen bestimmte Spalten im Ergebnis vorhanden sein:

Regeln verwalten und KQL lernen

Alle erstellten Regeln findet man unter Hunting → Custom detection rules. Die Übersicht zeigt je Regel Name, Alert-Titel, Schweregrad, Aktionen, letzte Ausführung und Änderungszeitpunkt. Über Open detection rule page sieht man alle Parameter (Alert-Name, Kategorie, MITRE-Technik, betroffene Entitäten) sowie den Trigger-Verlauf und kann Run, Edit oder Turn off ausführen.

KQL zu lernen lohnt sich, weil viele Microsoft-Security-Tools darauf aufbauen. Hilfreiche Quellen sind die Threat-Analytics-Berichte im Portal (sie enthalten oft KQL-Beispiele, z. B. im Report zu IRIDIUM/TOR-Angriffen), die offizielle Microsoft-Dokumentation, die Serie „Must Learn KQL" von Rod Trent, 365 Days of KQL (Matt Zorich, GitHub) sowie KustoKing.com und KQLCafe (Gianni Castaldi / Alex Verboon).

Automatisierung mit Logic Apps & Sentinel

Custom Detections erlauben bereits einfache automatisierte Reaktionen, allerdings mit begrenzter Auswahl an Aktionen. Mit Azure Logic Apps und den Defender-APIs sind deutlich umfangreichere Szenarien möglich – von der Geräteisolation über das Sammeln von Investigation Packages bis hin zum Ausführen eigener PowerShell-Skripte (z. B. Speicherabbild-Export).

Warum automatisieren?

In modernen SOCs (mit Sentinel, Splunk o. Ä.) reagiert man automatisch auf Alarme und Vorfälle. Typische Beispiele:

• Geräte isolieren oder die Isolation aufheben.
• Die App Execution Restriction für einen Rechner aktivieren oder deaktivieren.
• Ein komplettes Investigation Package auslesen und sammeln.
• Eigene PowerShell-Skripte ausführen.

Setzt man Sentinel ein, lassen sich Logic Apps als Reaktion auf Incidents oder Alerts automatisch auslösen. Aber auch ohne SIEM können Defender-Aktionen per API oder geplanter Logic App automatisiert werden – etwa das Setzen von Device-Tags.

Logic Apps versus Power Automate

Azure Logic Apps bieten die für Security wichtigen Funktionen: Sie unterstützen Managed Identities statt Service Principals, liefern ausführliche Diagnose-Logs und nutzen das umfassende Azure-RBAC. Deshalb sind sie in Kombination mit MDE meist die bessere Wahl.

Beispiel 1: Geräte automatisch taggen

Szenario: Gerätetags dienen der Gruppierung und Berichterstellung. In der Registry lässt sich pro System nur ein einzelner Tag setzen – über die MDE-API bzw. das Portal jedoch mehrere. Ziel ist, alle per Advanced-Hunting-Abfrage gefundenen Geräte automatisch mit einem Tag zu versehen, etwa um Domaincontroller zu kennzeichnen.

Als Grundlage dient eine Abfrage, die Domaincontroller anhand des lokalen Kerberos-Ports 88 und des IP-Typs FourToSixMapping identifiziert:

// Domain-Controller anzeigen: lokaler Port 88, IP-Typ FourToSixMapping
DeviceNetworkEvents
| where LocalPort == "88"
| where LocalIPType contains "FourToSixMapping"
| distinct DeviceId
| join (
    DeviceInfo
    | summarize arg_max(Timestamp, *) by DeviceId
  ) on DeviceId
| project DeviceId, DeviceName, OnboardingStatus

Das Ergebnis liefert die DeviceId, die anschließend in der Logic App zum Setzen des Tags gebraucht wird.

Logic App anlegen:

1. Neue Logic App: Im Azure-Portal unter Logic Apps → Add das Abonnement, eine Ressourcengruppe (z. B. RG-MDE-PlayBooks), einen Namen (z. B. MDE-DeviceTag-1.0) und eine Region wählen.
2. Tarifmodell: Für Defender-Integrationen wird häufig das Consumption-Modell genutzt (Abrechnung pro Ausführung); alternativ ein Standardplan.
3. Managed Identity aktivieren: Unter Identity die System-assigned Managed Identity auf On setzen. Die erforderlichen Berechtigungen dieser Identität müssen derzeit per PowerShell vergeben werden, da das im Portal nicht direkt möglich ist.

Ablauf im Designer:

• Trigger: Recurrence (zeitgesteuert), z. B. Interval = 1, Frequency = Week, On these days = Friday – der Flow läuft dann jeden Freitag.
• Advanced Hunting ausführen: Aktion Microsoft Defender ATP → Advanced Hunting hinzufügen und die obige KQL-Abfrage einfügen. Die Verbindung muss über die Managed Identity laufen (Anzeige „Connected to Managed Identity").
• For each: Schleife über die Results des Advanced-Hunting-Schritts – für jede gefundene DeviceId wird der nächste Schritt ausgeführt.
• Tag setzen: Innerhalb der Schleife die Aktion Machines – Tag machine konfigurieren:
  • ID of the machine: DeviceId (dynamisch aus der Schleife)
  • Value: gewünschter Tag-Name, z. B. Domain Controllers
  • Action: Add

In der Run History der Logic App lässt sich der Erfolg nachvollziehen: Der Advanced-Hunting-Schritt gibt z. B. { "DeviceId": "13ad2da5..." } zurück, und die Tag machine-Aktion versieht dieses Gerät mit dem Tag. Zwei grüne Häkchen zeigen an, dass beide Schritte erfolgreich waren. Damit identifiziert der Flow Domaincontroller vollautomatisch und markiert sie.

Beispiel 2: Automatisierung via Microsoft Sentinel

In Sentinel lassen sich Logic Apps (Playbooks) direkt mit Vorfällen (Incidents) verknüpfen. Ein Vorteil sind die Automation Rules: Ein Playbook startet automatisch, sobald ein neuer Vorfall bestimmte Kriterien erfüllt. Für Vorfälle gibt es zwei Automatisierungsoptionen:

• Manueller Playbook-Start: Der Analyst führt ein Playbook direkt im Vorfall aus.
• Automation Rules: Regeln, die bei der Erstellung eines Vorfalls automatisch Aktionen auslösen (gefiltert nach Schweregrad, Titel, bestimmten Entitäten usw.).

Berechtigungen vorbereiten: Unter Settings → Playbook permissions die Ressourcengruppe mit den Playbooks (z. B. RG-MDE-PlayBooks) auswählen und mit Apply bestätigen. Danach darf Sentinel diese Logic Apps ausführen.

Playbook-Vorlagen: Unter Automation → Playbook templates kann man nach „MDE" filtern. Häufige Beispiele:

• Run MDE Antivirus Scan – Virenscan auf einem Endpunkt.
• Isolate endpoint / Unisolate MDE machine – Gerät isolieren bzw. Isolation aufheben.
• Restrict MDE App Execution – AppLocker-Richtlinie auf ein MDE-Gerät anwenden.
• Restrict MDE Domain/FileHash/IP/URL – bestimmte Domains, Dateihashes, IPs oder URLs sperren.

Über Create playbook wählt man Name, Abo und Ressourcengruppe und richtet die Verbindungen ein – auch hier empfiehlt sich die Nutzung von Managed Identities.

Beispiel-Playbook – Gerät automatisch isolieren:

1. Microsoft Sentinel Incident Trigger: Startet automatisch bei Erstellung eines Sentinel-Vorfalls.
2. Entities – Get Hosts: Liest alle Rechner-Entitäten (Hosts) aus dem Vorfall aus.
3. For each Host: Für jedes Host prüft eine Condition:
   • True: Hat das Host eine gültige MDE-Device-ID? Dann Isolate device ausführen und einen Kommentar zum Vorfall hinzufügen.
   • False: Ohne MDE-Device-ID nur einen Kommentar hinzufügen.

Automatische Auslösung (Automation Rule): Unter Automation → Automation rules eine neue Regel anlegen, z. B.:

1. Trigger: When an incident is created
2. Conditions: Severity = High und Title contains "ransomware"
3. Actions:
   • Change status to Active
   • Run playbook Isolate-MDEMachine

Damit wird künftig bei jedem neuen High-Severity-Vorfall mit dem Stichwort ransomware der Status auf Active gesetzt und das Isolierungs-Playbook gestartet.

Protokollierung: Der Erfolg lässt sich an zwei Stellen nachvollziehen. In der Runs History der Logic App zeigen grüne bzw. rote Häkchen erfolgreiche und fehlerhafte Läufe; bei Fehlern kann man den Input/Output eines Schritts analysieren. Zusätzlich erscheinen die Aktionen im Defender Action Center – dort ist protokolliert, welche Aktion wann von wem (Admin, Public API), aus welcher Quelle und mit welchem Status (Completed) durchgeführt wurde.

Attack Disruption

Automatic Attack Disruption ist eine leistungsstarke Reaktionsfunktion von Microsoft Defender XDR. Sie schützt vor ausgeklügelten, hochwirksamen Angriffen, indem sie – während ein Angriff noch läuft – die vom Angreifer genutzten Assets eindämmt. Der Angriff wird so frühzeitig gestoppt, weiterer Schaden verhindert und die Gesamtauswirkung reduziert. Attack Disruption arbeitet automatisch, erfordert aber die korrekte Konfiguration der einzelnen Produkte.

Wie funktioniert Attack Disruption?

Attack Disruption korreliert die Signale aller Defender- und Microsoft-Sicherheitsprodukte und ist standardmäßig aktiv, sobald alle Voraussetzungen erfüllt sind. Auf Basis von Sicherheitsforschung und KI-Modellen kombiniert es Ereignisse, identifiziert fortgeschrittene Angriffe und führt automatisierte Aktionen aus. Je mehr Tools und Daten verbunden sind, desto mehr Bedrohungen werden abgedeckt.

Der Ablauf gliedert sich in drei Stufen:

1. Korrelieren: Ereignisse aus Defender XDR über alle Produkte hinweg werden zu einem einzigen, hoch vertrauenswürdigen Incident zusammengeführt – auf Basis der Daten von Endpunkten, Identitäten, E-Mail und Collaboration-Tools. Eine Berechnung filtert dabei False Positives heraus.
2. Assets identifizieren: Ermittlung der betroffenen, vom Angreifer kontrollierten Assets.
3. Reagieren: Automatisierte Reaktionsaktionen, um den Angriff einzudämmen und betroffene Maschinen zu isolieren.

Attack Disruption korreliert Signale aller Defender-Produkte, klassifiziert den Angriff mit hoher Zuversicht und führt automatisierte Reaktionen aus.

Da automatische Aktionen bei einem False Positive selbst Schaden anrichten könnten, stützt sich Attack Disruption bewusst auf hochqualitative Signale und einen hohen Signal-to-Noise-Ratio. Erst wenn mehrere Produkt-Alarme korrelieren und Microsoft den Impact mit hoher Zuversicht validiert, greift die Automation.

Verfügbare Aktionen

Attack Disruption nutzt die vorhandenen XDR-Reaktionsaktionen der Produkte:

Endpoint (MDE):

• Contain device (Teil des Flows)
• Contain user
• Contain IP

Mit Device Discovery und Containment erkennt MDE auch unmanaged Geräte und blockiert die ein- und ausgehende Kommunikation mit einem verdächtigen Gerät. Das macht die Contain-Aktion besonders stark, weil Angreifer gern nicht verwaltete Geräte im Netzwerk nutzen. Für Contain ist kein Defender for Identity nötig – Contain ist Teil von MDE.

Identity (MDI):

• Disable user – blockiert Benutzer in AD/Entra ID. Die Abläufe unterscheiden sich je nach Kontotyp:
  • Konto in Active Directory: MDI löst Disable user auf Domain-Controllern mit installiertem MDI-Sensor aus.
  • AD-Konto mit Entra-ID-Sync: MDI deaktiviert das Konto auch in Entra ID.
  • Nur Entra ID (Cloud-Native): Attack Disruption deaktiviert das Konto direkt in Entra ID – ohne Abhängigkeit von einer MDI-Bereitstellung.

Die Disable user-Aktion wird durch Defender for Identity (MDI) ausgeführt und im Action Center protokolliert.

Entra ID:

• Disable OAuth applications

Unterstützte Angriffe

Attack Disruption greift u. a. bei folgenden Szenarien ein:

• Human-Operated Ransomware (HumOR)
• Business Email Compromise (BEC)
• Adversary-in-the-Middle (AiTM)
• Password-Spray-Angriffe

Es gibt weitere unterstützte Szenarien; die Liste ist nicht abschließend.

Voraussetzungen und Konfiguration

Attack Disruption ist automatisch aktiv, wenn Defender XDR genutzt wird. Da es eine XDR-Funktion ist, braucht es Signale aus mehreren Quellen:

• Defender for Office
• Defender for Endpoint
• Defender for Identity
• Defender for Cloud Apps
• Entra ID Protection (korreliert mit Defender XDR)
• Microsoft Sentinel (nur für SAP Financial Process Manipulation)

Prerequisites:

• Defender-Produkte konfiguriert (für vollständige Sichtbarkeit)
• korrekte Lizenz/Subscription vorhanden
• MDE Device Discovery auf Standard discovery gesetzt
• MDE mit passendem Automation Level konfiguriert

Die wichtigsten Einstellungen je Produkt:

Microsoft Defender for Endpoint

• Device Discovery: Unter Settings → Device discovery den Modus auf Standard discovery setzen. Nur so erkennt MDE nicht verwaltete Geräte und Containment-Aktionen funktionieren korrekt – Basic discovery lauscht nur passiv. Nicht onboardete Geräte lassen sich per KQL anzeigen:

  DeviceInfo
  | summarize arg_max(Timestamp, *) by DeviceId
  | where isempty(MergedToDeviceId)
  | where OnboardingStatus != "Onboarded"
  

  Device Discovery auf Standard discovery – Voraussetzung dafür, dass Containment und Attack Disruption unmanaged Geräte erfassen können.

• Automation Level: Für automatische Aktionen wird Full – remediate threats automatically empfohlen. Damit sind Datei-Quarantäne und Containment automatisiert; für einzelne Geräte lassen sich Ausnahmen definieren.

  Das Automation Level wird pro Gerätegruppe gesetzt – für Attack Disruption ist „Full – remediate threats automatically" empfohlen.

• Sense Agent: Mindestversion 10.8470 oder höher – erforderlich u. a. für die Aktion Contain user. Sensoren generell aktuell halten.

Microsoft Defender for Identity

• Action accounts: Korrekt konfigurieren – entweder über das Sensor local system account oder ein manuell konfiguriertes gMSA-Konto. MDI führt Disable user auf Domain-Controllern mit installiertem Sensor aus. Für reine Entra-ID-Konten ist MDI nicht zwingend nötig.

  Die Action Accounts in MDI steuern, mit welchem Konto Remediation-Aktionen wie Disable user ausgeführt werden.

• Sensor & Auditing: Alle Sensoren korrekt installiert, mit gesundem Status, und die erforderliche Auditierung aktiviert – ohne korrektes Auditing arbeitet MDI nicht effektiv.

Microsoft Defender for Cloud Apps

• Der Microsoft-365-Connector muss aktiviert und korrekt konfiguriert sein. Zusätzlich – falls verfügbar – App Governance einrichten, um tiefere App- und OAuth-Einblicke zu erhalten.

  Der Microsoft-365-Connector in Defender for Cloud Apps muss aktiv sein, damit App- und OAuth-Signale in Attack Disruption einfließen.

Microsoft Defender for Office 365

• Folgende Mailbox-Audit-Events aktivieren: HardDelete, MailItemsAccessed, UpdateInboxRules, MoveToDeletedItems, SoftDelete. Zusätzlich mindestens eine Safe-Links-Policy konfigurieren.

Attack Disruption in Aktion

Ein durchgespieltes Angriffsszenario verdeutlicht die Wirkung. Ausgangspunkt ist ein nicht in MDE onboardeter, internet-exponierter Windows-Server, der Teil der Domain und mit einigen CVEs verwundbar ist. Der Angreifer dumpt mit Mimikatz das dort gespeicherte Domain-Administrator-Konto Bill. Alle übrigen Geräte und der Domain Controller sind bereits in MDE onboarded, der DC zusätzlich in MDI.

Ausgangspunkt des Angriffs: der nicht in MDE onboardete, internet-exponierte Windows-Server mit dem gedumpten Bill-Konto.

• Neue Konten: Vom exponierten Server aus legt der Angreifer mit dem Bill-Konto ein Konto Backup-account an und fügt es der Domain-Admin-Gruppe hinzu. MDI erkennt das sofort mit dem Alarm „Suspicious additions to sensitive groups".

  Der Angreifer legt per net user ein Backup-Konto an und hebt es in die Domain-Admin-Gruppe – von MDI sofort als „Suspicious additions to sensitive groups" erkannt.

• Lateral Movement: Über RDP verbindet sich der Angreifer zu einem Domain Controller und erlangt so volle Kontrolle über das Netzwerk.

  Laterale Bewegung: Über RDP verbindet sich der Angreifer mit dem kompromittierten Konto zum Domain Controller.

• Malicious activity: Der Angreifer setzt das Framework impacket für Credential-Dumps und laterale Bewegung ein:

  impacket-smbexec 'm365securitylab.local/Bill:Secret20231@DC01.m365securitylab.local'
  impacket-wmiexec 'm365securitylab.local/Bill:Secret20231@DCLAB-5.m365securitylab.local' whoami
  lsassy -u Bill -p Secret2023! DCLAB-5.m365securitylab.local
  

  Da die anderen Maschinen onboarded sind, wird impacket vom Defender AV geblockt und durch die EDR-Komponente erkannt.

  Die impacket-Angriffe scheitern – Credential-Dumps und laterale Bewegung werden vom Defender AV bzw. der EDR-Komponente blockiert.

• Automatic Attack Disruption: Ab hier wendet Attack Disruption eine Policy auf alle onboardeten Geräte an und blockiert das Konto Bill inline/in Echtzeit. Diese Contain user-Aktion wird über MDE ausgeführt (nicht über MDI). Sie tritt sofort in Kraft und wirkt unabhängig davon, ob das Konto aktiv oder deaktiviert ist. Die aktive RDP-Session zum Domain Controller wird umgehend beendet.

  Contain user in Aktion: Die Sign-in-Restriction sperrt das Konto Bill inline auf allen onboardeten Geräten – ausgeführt über MDE.

  Die aktive RDP-Session zum Domain Controller wird durch Attack Disruption sofort beendet.

• Backup-Konten nutzlos: Der Versuch, sich mit dem zuvor angelegten Backup-Konto zu verbinden, scheitert – die Kontoerstellung war bereits früh erkannt und blockiert worden. Auch ein weiteres Konto Backup2 lässt sich nicht mehr für laterale Bewegung nutzen, weil Bills Berechtigungen eingeschränkt sind.

  Auch das Backup-Konto ist nutzlos: Die früh erkannte Kontoerstellung wird blockiert, laterale Bewegung ist nicht mehr möglich.

Sichtbarkeit im Defender XDR: Das vollständige Bild setzt sich aus vielen Alerts zusammen, u. a.:

• User-created or modified an account that later performed malicious activity
• User was created or modified by a compromised account
• User’s password was changed by a compromised account
• Possible lateral movement
• EDR-Alerts wie Suspicious service registration, Process memory dump, ‘DumpLsass’ malware was detected during lateral movement
• Impacket-Alerts wie Ongoing hands-on-keyboard attack via Impacket toolkit und ‘Impacket’ malware was detected during lateral movement

Defender XDR korreliert die Einzelalarme – von der Kontoerstellung bis zur lateralen Bewegung – zu einem Gesamtbild.

Die Attack Story visualisiert den gesamten Angriff als Incident-Graph – inklusive der bereits eingedämmten Konten (1/2 Contained).

Jeder zugehörige Alert trägt das Tag „Attack Disruption". Der Vorfall zeigt zudem eine gelbe Infoleiste: „Important! Attack disruption has automatically taken multiple response actions. For more details, go to the Action Center."

Alle von Attack Disruption behandelten Alerts sind mit dem Tag „Attack Disruption" gekennzeichnet.

Action Center und Rückgängig machen: Im Action Center sind alle automatisierten Aktionen unter der Action source „Attack disruption" sichtbar – etwa Contain user (ausgeführt durch MDE) und Disable user (ausgeführt durch MDI). Über die Buttons lässt sich ein Konto wieder aktivieren bzw. eine Contain-Einschränkung per Undo aufheben; automatisch wird die Einschränkung nach 12 Stunden aufgehoben.

Im Action Center sind alle automatisierten Aktionen unter der Action source „Attack disruption" dokumentiert – Contain user (MDE) und Disable user (MDI).

Die Benutzer-Detailseite zeigt das Konto Bill als „Contained" und „Disabled" – der volle Kontext inklusive Incidents und Alerts.

Wichtig: Immer erst die Untersuchung gründlich prüfen und keine Konten ohne weitere Analyse wiederherstellen. Das Wiederherstellen gewährt sofort vollen Netzwerkzugriff und kann in einem realen Angriff erheblichen Schaden verursachen.

Über Advanced Hunting lassen sich alle Contain-Events in der DeviceEvents-Tabelle einsehen – z. B. UserLogonBlocked, RemoteDesktopSessionDisconnected und ContainedUserSMBSessionStopped.

In der DeviceEvents-Tabelle lassen sich alle Contain-Events der Attack Disruption gezielt per KQL auswerten.

Tipps, Tricks & häufige Fehler

Bei der Einführung von MDE treten in der Praxis immer wieder dieselben Fehler auf. Die folgenden Punkte fassen die häufigsten zusammen.

Häufige Fehler bei Planung und Rollout

• Keine Struktur: Ohne durchdachtes Gerätegruppen-Konzept wird die Plattform unübersichtlich. Gerätegruppen sind die Grundlage für RBAC (gezielte Zugriffsrechte) und für Berichte pro Gruppe – gerade wenn mehrere Teams jeweils nur einen Teil der Geräte verwalten.

• Zu großzügige Rechte auf kritischen Servern: Beim Onboarding von Domänencontrollern oder Tier-0-Servern (über Azure Arc oder direkt) ist Vorsicht geboten. Wer einen DC in Azure Arc eingebunden hat, kann per Custom Script Extension lokale Admins anlegen – effektiv wie ein echter Administratorzugriff. Ähnliches gilt für Live Response: Damit lassen sich per PowerShell eigene Skripte auf jedem Endpunkt ausführen, sofern die Berechtigung besteht. Deshalb: sauberes RBAC-Modell, kritische Server in separate Resource Groups und dedizierte Gerätegruppen, Zugriff restriktiv vergeben, unsignierte Skripte in Live Response deaktivieren und die Live-Response-Aktivitäten unter Aktionen & Übermittlungen → Aktionszentrum → Verlauf (letzte 30 Tage) regelmäßig prüfen.

• Dienst-Einstellungen unvollständig aktiviert: Wird MDE ohne alle Advanced Features eingeschaltet (z. B. ohne Cloud Protection oder Network Protection), entstehen Lücken. Vor dem Onboarding sicherstellen, dass alle relevanten Schutzfunktionen aktiv sind.

• Neuerungen ignoriert: Microsoft aktualisiert MDE laufend. Häufig werden nur die Standardoptionen der Ersteinrichtung gesetzt und danach jahrelang nicht mehr geprüft (klassisches Beispiel: fehlende ASR-Regel „Block vulnerable drivers"). Neuerungen regelmäßig prüfen und wichtige Schutzfunktionen sofort aktivieren.

• Fehlendes Onboarding-Konzept: Es gibt viele Wege (Intune, GPO, PowerShell, MECM, Azure Arc, Defender for Servers). Der Fehler ist, sich auf eine veraltete Methode zu versteifen. Besser: die für die Infrastruktur passende Methode wählen und mehrere Wege kombinieren (Intune für moderne PCs, GPO für Offline-Geräte, Azure Arc für Hybrid).

• Richtlinienkonflikte: In Windows-Umgebungen existieren viele Einstellungsquellen (GPO, Intune, ConfigMgr, lokale Richtlinien). Typische Konflikte: Defender-AV per GPO manuell deaktiviert, Security-Baseline-GPO kollidiert mit Intune, SCCM Endpoint Protection widerspricht einem Intune-Profil. Lösung: bestehende Konfiguration dokumentieren und priorisieren. In Intune legt man per OMA-URI fest, dass MDM Vorrang vor GPO hat:

  OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
  Datentyp: Integer
  Wert:     1
  

• Alte AV-Ausnahmelisten übernommen: Jede Ausnahme senkt den Schutz. Ausnahmen aus früheren AV-Produkten niemals blind migrieren – nur bei nachgewiesenem Bedarf hinzufügen und mit Ticketnummer, Datum und Begründung dokumentieren.

• Defender Antivirus (NGP) nicht richtig konfiguriert: „Sensor Active" bedeutet nur, dass die Grundverbindung zu MDE besteht. Der Next-Gen-Schutz (Cloud Protection, ASR-Regeln, Network Protection) muss separat aktiviert werden. Zur Prüfung eignet sich das Empfehlungs-Framework unter Vulnerability Management → Recommendations, gefiltert nach Security controls.

• In Produktion ohne Funktionswissen: Das Team muss die MDE-Funktionen verstehen – EDR-Block-Modus, MAPS/Cloud-Schutz, PUA-Schutz, Tamper Protection und vor allem den Unterschied zwischen Audit-Modus (nur protokollieren) und Block-Modus. Betriebsanleitungen erstellen und Helpdesk-Teams schulen.

Unbekannte Geräte aufspüren (Device Discovery)

Eine CMDB kennt selten wirklich alle Geräte – Testsysteme, IoT-Geräte (Drucker, Kameras) oder neue Server tauchen unerfasst auf. Onboardete Endpunkte scannen das Netzwerk aktiv und passiv nach weiteren Hosts. Unter Endpoints → Configuration management → Device discovery gibt es zwei Modi:

• Basic discovery: lauscht rein passiv mit.
• Standard discovery (empfohlen): nutzt zusätzlich aktives Scanning und erlaubt gezielte Erkennungen – etwa die erweiterte Log4j-Detektion (CVE-2021-44228) auf Server-2019+.

Gefundene Geräte erscheinen im Inventar (Computers & Mobile, Network devices, IoT devices) und lassen sich nach Onboarding-Status filtern (Kann onboarded werden, Nicht unterstützt, Nicht genug Informationen). Für Netzwerkgeräte (Router, Switches) gibt es zusätzlich den Authenticated Scan mit hinterlegten Credentials (SNMP/LDAP). Nicht vollständig onboardete Geräte findet man per KQL:

DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId
| where isempty(MergedToDeviceId)
| where OnboardingStatus != "Onboarded"

Portal-Daten aktiv nutzen

MDE ist kein Produkt, das man einmal installiert und dann ignoriert. Statt nur auf einzelne Alarme zu warten, sollte man täglich proaktiv arbeiten: neue Vorfälle/Alarme prüfen, Schwachstellen nach Risiko-Score patchen, Threat Analytics (mit fertigen KQL-Jagdregeln) nutzen, das Aktionszentrum auf automatisch gelöste Alarme kontrollieren sowie Systeme konsequent patchen und härten.

Beim Schwachstellenmanagement gilt: nicht jede CVE muss sofort bearbeitet werden. Priorisieren nach Bedrohungsbewertung (Anzahl CVEs pro Gerät, aktive Ausnutzung) mit dem Ziel, den Exposure Score zu senken. Unter Vulnerability management → Recommendations helfen Filter (Status Active, Komponente Attack surface reduction), sich auf drängende Einträge zu konzentrieren. Wichtige Empfehlungen exportieren oder Benachrichtigungen einrichten, damit nichts übersehen wird.

Automatisierte Aktionen prüfen: Unter Aktionen & Übermittlungen → Aktionszentrum zeigt das Register Verlauf alle vergangenen Aktionen mit Datum, Aktionstyp (Isolate device, Quarantine file, Live Response command), Ressource und Ergebnis. Der Eintrag „Approved (Automation)" bedeutet, dass Defender selbstständig reagiert hat. Wurde eine Datei fälschlich isoliert, lässt sich das über Undo rückgängig machen. Live-Response-Sitzungen sind komplett protokolliert – inklusive aller Befehle und Ausgaben, etwa:

C:\> connect
Session established
C:\> run MDEStatus.ps1

Das erlaubt ein vollständiges Audit der administrativen Aktivitäten auf den Endpunkten.

Konfigurationsfehler im Detail

Kein Manipulationsschutz aktiv (Tamper Protection): Ohne Tamper Protection können Schadsoftware oder lokale Admins kritische Defender-Settings verändern (z. B. Firewall-Regeln abschalten). Aktivieren lässt er sich im Portal (Endpoints → Advanced features → Tamper Protection = On) oder in Intune (Endpoint Security → Antivirus → TamperProtection = On). Zusätzlich empfiehlt Microsoft, alle Ausnahmen in Intune zu verwalten und dabei DisableLocalAdminMerge zu aktivieren (lokale Ausnahmelisten aus Registry/GPO werden nicht übernommen). Für kurzfristiges Abschalten einzelner Funktionen gibt es den Troubleshooting Mode – der Grundsatz bleibt aber: Tamper Protection immer aktiv.

Lokale Adminrechte einschränken: Selbst mit lokalen Adminrechten sollte der Zugriff auf Defender-Policies begrenzt sein. Über den Registry-Schlüssel HideExclusionsFromLocalAdmins unter HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager (Wert 1) sind Ausnahmelisten für lokale Admins nicht mehr sicht- oder änderbar. Per Intune:

OMA-URI:  ./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalAdmins
Datentyp: Integer
Wert:     1

Keine Updates bereitgestellt: WSUS und ConfigMgr sind oft fehleranfällig (inkonsistente Kataloge, Sync-Probleme). Wo möglich, Signatur-Updates über Windows Update verteilen. Wichtige Update-Typen:

In ConfigMgr muss die Produktkategorie „Microsoft Defender for Endpoint" bzw. „Windows Defender Antivirus" aktiviert sein, damit diese Updates nicht übersprungen werden.

BAFS falsch konfiguriert (Block at First Sight): BAFS blockiert neue Malware innerhalb von Sekunden – funktioniert aber nur, wenn mehrere Einstellungen zusammenwirken: Cloudschutz aktiv, automatischer Dateiversand (alle bzw. sichere Dateien automatisch an die Cloud) und ein erhöhtes Cloud-Timeout (empfohlen ca. 50 Sekunden). Fehlt eine Komponente, bleibt BAFS wirkungslos.

Notfall-Updates ignoriert: Microsoft verteilt bei akuten Bedrohungen Emergency Updates über den Cloudschutz (MAPS). Ist Cloud-delivered Protection abgeschaltet, erhält Defender diese dringenden Updates nicht.

Exclusions falsch gehandhabt: Vor dem Rollout die Präventions-Einstellungen setzen – DisableLocalAdminMerge, Tamper Protection und (bei lokalen Admins) HideExclusionsFromLocalAdmins. Herstellervorschläge mit ganzen Programm-Ordnern nie ungeprüft übernehmen; oft läuft eine Anwendung auch ohne. Bei Bedarf gezielt per Process Monitor die kritischen Pfade ermitteln und jede Ausnahme dokumentieren. Ein guter Leitfaden ist der „Hitchhiker’s Guide to Defender Exclusions" von Fabian Bader (cloudbrothers.info).

Netzwerkschutz ohne SmartScreen: Network Protection blockiert gefährliche Domains und C2-Server, gehört aber immer mit Defender SmartScreen zusammen. SmartScreen ergänzt den Schutz um Phishing- und Download-Warnungen und muss in allen Komponenten aktiv sein (Edge, Datei-Explorer, weitere Apps). Ohne SmartScreen fehlt ein wesentlicher Teil des Web-Schutzes.

Auto-Remediation deaktiviert: Seit 2021 ist in neuen Tenants Full Automation für die Vorfallreaktion standardmäßig aktiv. Es gibt fünf Automatisierungsstufen (von No automated response bis Full automation). Der häufige Fehler, die Automatik ganz abzuschalten, führt dazu, dass Defender keine Untersuchungen mehr durchführt und Vorfälle liegen bleiben. Ist Full Automation nicht möglich, mindestens eine Semi-Automation-Stufe wählen.

Advanced Hunting / Custom Detections nicht genutzt: Defender sammelt laufend umfangreiche Telemetrie, alarmiert aber nicht für jede mögliche Bedrohung. Mit eigenen KQL-basierten Custom Detection Rules schließt man diese Detection Gaps – etwa für ungewöhnliche Benutzererstellungen („New user created by ’net user’") oder Daten-Exfiltration.

Weiterführende Quellen

MDE entwickelt sich ständig weiter – am Ball bleiben lohnt sich. Empfehlenswert sind das Buch „Microsoft Defender for Endpoint In-Depth" (2. Auflage, Packt), Microsoft Learn und die Defender-Ninja-Trainings sowie Community-Experten wie Ru Campbell (campbell.scot), Fabian Bader (cloudbrothers.info), Olaf Hartong (FalconForce) und Sami Lamppu.

Validierung & Troubleshooting

Nach Implementierung und Konfiguration ist es entscheidend, die Schutzfunktionen zu validieren und sicherzustellen, dass alle Komponenten sauber arbeiten.

Gerätezustand prüfen (PowerShell)

Den Antivirenstatus prüft man mit Get-MpComputerStatus und Get-MpPreference. Wichtige Parameter aus Get-MpComputerStatus:

• AMRunningMode: sollte „Normal" sein (aktiver Schutz).
• AMProductVersion: neueste Version installiert.
• AMServiceEnabled, AntiSpywareEnabled, BehaviorMonitorEnabled, RealTimeProtectionEnabled, IoavProtectionEnabled: alle auf True.
• AntispywareSignatureAge, AntivirusSignatureAge: möglichst niedrig – Signaturen idealerweise mehrmals täglich aktualisiert.
• AntiVirusSignatureLastUpdated / AntiVirusSignatureVersion: letzte Aktualisierung und Version mit der neuesten verfügbaren vergleichen.

Für den Manipulationsschutz:

• IsTamperProtected: sollte True sein.
• TamperProtectionSource: sollte „ATP" anzeigen (über den Dienst aktiviert).

Konfigurationszustand prüfen

Mit Get-MpPreference sieht man alle konfigurierten Einstellungen. Besonders relevant:

• AllowDatagramProcessingOnWinServer, AllowNetworkProtectionDownLevel, AllowNetworkProtectionOnWinServer: auf True für Netzwerkschutz auf Servern.
• CloudBlockLevel: empfohlen 2 (hoch) oder 4 (hoch+).
• CloudExtendedTimeout: empfohlener Wert 50.
• DisableBehaviorMonitoring, DisableRealtimeMonitoring: auf False.
• EnableNetworkProtection: auf True.
• PuaProtection: 1 (Blockieren) oder 2 (Überwachen), je nach Richtlinie.

Onboarding-Status und Datensammlung

Nach der AV-Prüfung den Onboarding-Status in MDE kontrollieren – ein korrekt eingebundenes Gerät zeigt „Onboarded". Für eine tiefere Analyse dient der Microsoft Defender for Endpoint Client Analyzer: Nach dem Entpacken von MDEClientAnalyzer.zip enthält der Ordner mehrere Analysedateien, über die sich z. B. die meistgenutzten Dateierweiterungen und Prozesse anzeigen lassen. Auch hier gilt: Ausnahmen nur bei zwingendem Bedarf hinzufügen.

Defender wurde deaktiviert – sauberer Weg zurück in den Passiv-Modus

Ein häufiges Troubleshooting-Szenario: Defender wurde in der Vergangenheit gezielt deaktiviert, üblicherweise über den Regkey

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender – DisableAntispyware (1)

(manuell gesetzt oder per GPO); oft wurden zusätzlich die Defender-Dienste verändert. Setzt man diesen Wert nun über Intune schlicht auf 0, würde Defender trotz eines vorhandenen Drittanbieter-AV in den aktiven Modus springen – was in der Regel nicht gewünscht ist.

Der saubere Weg ist, den Regkey auf den betroffenen Geräten ganz zu entfernen (Status nicht konfiguriert), damit Defender das Handling zwischen den AV-Systemen wieder selbst übernimmt und in den Passiv-Modus wechselt. Über den Intune-Einstellungskatalog geht das nicht direkt, weil dort nur 1 oder 0 konfigurierbar ist. Deshalb erledigt man es per Skript/Regkey und verteilt dieses über Intune – und setzt bei Bedarf gleich die Defender-Dienste auf ihre Default-Startwerte zurück:

$regpath = 'HKLM:\SYSTEM\CurrentControlSet\Services'
Set-ItemProperty -Path ($regpath + "\WinDefend")  -Name Start -Value 2
Set-ItemProperty -Path ($regpath + "\Sense")      -Name Start -Value 3
Set-ItemProperty -Path ($regpath + "\WdFilter")   -Name Start -Value 0
Set-ItemProperty -Path ($regpath + "\WdNisDrv")   -Name Start -Value 3
Set-ItemProperty -Path ($regpath + "\WdNisSvc")   -Name Start -Value 3
Set-ItemProperty -Path ($regpath + "\WdBoot")     -Name Start -Value 0

Damit ergeben sich zwei Möglichkeiten:

1. Über Intune (Einstellungskatalog) aktivieren (Wert auf 0): geringerer Aufwand, aber der Drittanbieter-AV (z. B. Cynet) wäre dann nicht mehr führend.
2. Über Regkey/Skript in den Status „nicht konfiguriert" bringen und bei Bedarf die Default-Start-Werte der Dienste wiederherstellen: mehr Aufwand, aber Defender wählt selbstständig den korrekten (Passiv-)Modus.

Damit ist der Finetuning-Teil abgeschlossen: Von entfernten lokalen Admins über integrierte Defender-Produkte, eigene Erkennungsregeln, Automatisierung und Attack Disruption bis zur sauberen Validierung steht nun eine abgehärtete MDE-Umgebung.

Nächster Teil der Serie: Defender for Endpoint in VDI-Umgebungen.