In vielen Tenants, die ich betreue, bilden die Standardregeln von Microsoft Defender XDR eine solide Grundlage. Im Alltag genügen sie aber selten. Spätestens bei firmenspezifischen Angriffspfaden, exotischen Tools oder Insider-Bedrohungen braucht man eigene Abfragen. Genau dafür hat Microsoft die Custom Detection Rules geschaffen. Aus geprüften KQL-Queries lassen sich damit vollwertige Erkennungs- und Reaktionsregeln bauen, die automatisch auf neue Daten anspringen. Der Weg von der einmaligen Hunting-Abfrage zur belastbaren Detection Rule hat allerdings seine Tücken.

Eine gute Hunting-Query wird mit wenigen Klicks zur Detection Rule

In der Regel beginnt alles unter Microsoft Defender portal → Hunting → Advanced hunting. Am Anfang steht eine aussagekräftige KQL-Abfrage, die einen verdächtigen Vorgang erkennt und dabei möglichst wenige Fehlalarme erzeugt. Mindestens die Spalten Timestamp und ReportId sowie eine Identität wie DeviceId oder AccountObjectId muss die Query zurückgeben. Fehlt eine davon, lässt einen der Rule Wizard nicht weiter.

So sieht das bei mir typischerweise aus: Während einer Investigation fällt mir ein Muster auf, zum Beispiel ungewöhnliche Prozesse, die nach dem Start eines Office-Makros auftauchen. Daraus baue ich die folgende Query auf der Tabelle DeviceProcessEvents. Voraussetzung sind eine Lizenz für Defender for Endpoint P1/2 und die Rolle Security Administrator oder Unified RBAC:

DeviceProcessEvents
| where InitiatingProcessFileName =~ "WINWORD.EXE"
| where FileName has_any ("certutil.exe", "mshta.exe", "powershell.exe")
| project Timestamp, DeviceId, ReportId, FileName, InitiatingProcessCommandLine

Getestet und verfeinert wird die Query unter „Microsoft Defender portal → Hunting → Advanced hunting“. Ist man mit dem Ergebnis zufrieden, genügt im Ergebnisdialog ein Klick auf Create detection rule. Es öffnet sich ein Assistent, der die Query übernimmt und sämtliche Pflichtspalten kontrolliert. Weiter geht es erst, wenn alles stimmt.

In der Regelkonfiguration legt man Frequenz, Auslöser und Aktionen fest

Als Nächstes bestimmt man, in welchem Takt die Regel läuft (frühestens alle 5 Minuten, spätestens alle 24 Stunden), ob sie für jeden Treffer einzeln oder aggregiert auslöst und welche Automatisierung daran hängen soll. In produktiven Umgebungen konfiguriere ich neue Regeln zunächst ausschließlich mit Alert. Automatische Maßnahmen wie das Isolieren eines Geräts oder das Deaktivieren eines Benutzerkontos kommen erst nach einer Lernphase dazu. Wer zu früh automatisiert, erntet schnell Ärger, besonders wenn die Regel zu grob gestrickt ist.

Viele legen ihre Regel zu weit an und erfassen etwa jeden einzelnen PowerShell-Start. Besser ist eine Query, die so genau wie möglich zuschneidet, denn nur so bleiben die Fehlalarme im Rahmen. Wo die Möglichkeiten und Grenzen liegen, erklären die Dokumentation zu Custom Detection Rules und die Übersicht zu Custom Detections. Ein Detail wird gern übersehen, nämlich der Entity-Type. Von ihm hängt ab, ob Automatisierungen wie das Isolieren eines Geräts überhaupt greifen. Liefert die Query beispielsweise keine DeviceId, fehlen die passenden Aktionen.

Tipp aus der Praxis: Bevor eine Regel produktiv geht, sollte sie zunächst in einer Testgruppe laufen, etwa nur auf High-Value-Devices oder IT-Konten. Die Alerts in dieser Phase genau beobachten.

Gezieltes Tuning dämpft den Alert-Lärm deutlich

Custom Detection Rules sind ein mächtiges Werkzeug, können aber auch viel Lärm verursachen. Praktisch jede neue Regel meldet anfangs mehr, als einem lieb ist. Es zahlt sich deshalb aus, die Query gezielt nachzuschärfen, zum Beispiel mit zusätzlichen Filtern auf bestimmte CommandLines oder über eine Alert-Suppression im Rule-Dialog. Mit der Suppression lassen sich etwa identische Alerts pro Gerät eine Stunde lang zurückhalten, sodass keine Flut entsteht. Bei Regeln, die viele Geräte betreffen, ist das Gold wert.

Um die Regeln laufend zu verbessern, nutze ich die Alert-Review-Funktion. Dazu baue ich mir kleine Auswertungen in Advanced hunting, mit denen ich Fehlalarme systematisch aufspüre.

Im Defender portal verwaltet man alle eigenen Regeln an einer Stelle

Sämtliche eigenen Regeln finden sich im Defender portal unter Hunting → Custom detection rules. Dort sieht man auch, ob eine Regel beim letzten Lauf fehlerfrei durchgekommen ist, wie viele Alerts sie erzeugt hat und ob sie nachjustiert werden muss. Angenehm ist, dass sich Regeln direkt deaktivieren oder klonen lassen und die Query angepasst werden kann, ohne alles neu anzulegen. In größeren Umgebungen lohnen sich ein Namensstandard und eine Dokumentation der jeweiligen Regellogik. Im Ernstfall weiß das Team dann sofort, was eigentlich erkannt wurde.

Das folgende Diagramm zeigt den Weg von der Query bis zur automatisierten Reaktion über eine Custom Detection Rule:

flowchart TD
    A["Advanced hunting query"] --> B["Create detection rule"]
    B --> C["Rule configuration"]
    C --> D["Rule evaluates data"]
    D --> E["Alert generated"]
    E --> F["Automated response (optional)"]

Abbildung: Ablauf von der Advanced-Hunting-Query bis zur automatisierten Reaktion in Defender XDR

Eigene Erkennungsregeln verlangen dauerhafte Pflege und Verantwortung

Für eine moderne, anpassungsfähige Sicherheitsüberwachung in Microsoft 365 und Azure sind Custom Detection Rules aus meiner Sicht unverzichtbar. Sie kombinieren die Flexibilität von KQL mit unmittelbarer Reaktion. Davon profitiert man allerdings nur, wenn man die Verantwortung ernst nimmt und die Regeln regelmäßig pflegt und nachjustiert. Zusammen mit Unified Incidents und Automation entsteht auf diese Weise ein Detection-Ökosystem, das sich wirklich an die Verhältnisse im eigenen Unternehmen anpassen lässt. Ich setze lieber auf wenige, sauber abgestimmte Regeln als auf viele, die vor allem Lärm machen. Dabei frage ich mich jedes Mal kritisch, was eine Regel dem SOC-Team tatsächlich bringt.