Leistungen Vorgehen Insights Ressourcen Kontakt Beratung anfragen
Home / Ressourcen / Defender Threat Hunting

Microsoft Defender – Custom Detection Rules

Schritt-für-Schritt Implementierungsanleitung für Threat Hunting im M365 Tenant

Microsoft Defender XDR 4 Detection Rules E-Mail Alerting
Fortschritt 0 von 24 Schritten erledigt
1
Vorbereitung & Voraussetzungen prüfen
Einmalig ▶
Bevor Custom Detection Rules angelegt werden können, müssen folgende Voraussetzungen erfüllt sein.
2
Die 4 Detection Rules anlegen
Kernaufgabe ▶
Für jede Rule: Hunting → Advanced Hunting → KQL eingeben → testen → als Custom Detection Rule speichern. Der genaue Speicherprozess wird in Schritt 3 beschrieben.
📬 Rule 1 – Verdächtige Weiterleitungsregel angelegt HOCH
Erkennt wenn ein Nutzer eine neue Inbox-Regel anlegt, die Mails weiterleitet oder löscht — klassisches Zeichen für ein kompromittiertes Konto.
KQL Abfrage 
// Rule 1: Verdächtige Inbox-Weiterleitungsregeln
CloudAppEvents
| where Timestamp > ago(1h)
| where ActionType in (
    "New-InboxRule",
    "Set-InboxRule"
)
| where RawEventData has_any (
    "ForwardTo",
    "ForwardAsAttachmentTo",
    "RedirectTo",
    "DeleteMessage",
    "MoveToFolder"
)
| extend RuleDetails = tostring(RawEventData)
| project
    Timestamp,
    AccountDisplayName,
    AccountUpn,
    ActionType,
    IPAddress,
    RuleDetails
🌍 Rule 2 – Login aus unbekanntem Land HOCH
Erkennt erfolgreiche Logins aus Ländern die nicht in der normalen Nutzungsliste sind. Die Länderliste muss auf die tatsächlichen Standorte angepasst werden.
KQL Abfrage 
// Rule 2: Login aus unbekanntem Land
// Erlaubte Länder anpassen (ISO-Codes)
let AllowedCountries = dynamic([
    "DE", "AT", "CH", "NL", "BE"
]);
IdentityLogonEvents
| where Timestamp > ago(1h)
| where ActionType == "LogonSuccess"
| where isnotempty(Location)
| where Location !in (AllowedCountries)
| project
    Timestamp,
    AccountUpn,
    AccountDisplayName,
    Location,
    IPAddress,
    DeviceName,
    LogonType
Die Länderliste muss vor dem Speichern auf die tatsächlichen Standorte angepasst werden. Falsch konfiguriert löst diese Rule bei jedem Geschäftsreisenden aus.
📤 Rule 3 – Massenversand von einem internen Konto HOCH
Erkennt wenn ein einzelnes Konto innerhalb einer Stunde ungewöhnlich viele Mails versendet — typisches Zeichen für Spam-Versand nach Kompromittierung.
KQL Abfrage 
// Rule 3: Massenversand von internem Konto
// Schwellwert: mehr als 50 Mails pro Stunde
EmailEvents
| where Timestamp > ago(1h)
| where EmailDirection == "Outbound"
| where SenderFromDomain endswith "ihredomain.com"
| summarize
    MailCount = count(),
    Recipients = make_set(RecipientEmailAddress)
    by SenderFromAddress
| where MailCount > 50
| order by MailCount desc
📁 Rule 4 – Massendownload aus SharePoint außerhalb der Arbeitszeiten MITTEL
Erkennt wenn ein Konto nachts oder am Wochenende ungewöhnlich viele Dateien aus SharePoint herunterlädt — mögliches Zeichen für Datenexfiltration.
KQL Abfrage 
// Rule 4: Massendownload außerhalb Arbeitszeiten
// Außerhalb Mo–Fr 07:00–19:00 Uhr (UTC+1 → UTC angepasst)
CloudAppEvents
| where Timestamp > ago(1h)
| where Application == "Microsoft SharePoint Online"
| where ActionType == "FileDownloaded"
| where hourofday(Timestamp) !between (6 .. 18)
    or dayofweek(Timestamp) in (
        0d, // Sonntag
        6d  // Samstag
    )
| summarize
    Downloads = count(),
    Files = make_set(ObjectName)
    by AccountUpn, IPAddress
| where Downloads > 20
| order by Downloads desc
3
Custom Detection Rule im Portal speichern
Für jede Rule wiederholen ▶
Dieser Prozess gilt für alle 4 Rules. Nach dem Testen der KQL-Abfrage im Advanced Hunting folgt dieser Speicherprozess.
security.microsoft.com → Hunting → Advanced Hunting
KQL-Abfrage in das Eingabefeld einfügen und auf Run query klicken. Sicherstellen dass keine Fehler angezeigt werden.
Auf Create detection rule klicken (Button oberhalb der Ergebnisse).
Name der Rule eingeben (z.B. Suspicious Inbox Rule), Beschreibung hinzufügen.
Frequency (Ausführungsintervall) wählen: Every 1 hour für High-Rules, Every 3 hours für Medium.
Severity festlegen: High oder Medium je nach Rule.
Unter Actions kann optional eine automatische Reaktion konfiguriert werden (z.B. Konto isolieren bei Rule 1 & 2).
Auf Save klicken. Die Rule erscheint danach unter Hunting → Custom detection rules.
4
E-Mail Alerting konfigurieren
Wichtig ▶
security.microsoft.com → Settings → Microsoft Defender XDR → Email notifications
Unter Email notifications auf + Add notification rule klicken.
Name vergeben, z.B. Security Alerts.
Unter Notification settings die Schweregrade wählen: High und Medium aktivieren, Low deaktivieren (sonst zu viel Rauschen).
E-Mail-Empfänger eintragen — empfohlen: IT-Verantwortlicher + Security-Kontakt. Nicht zu viele Empfänger, sonst ignoriert jeder die Mails.
Auf Save klicken und Test-Mail über Send test email auslösen um die Zustellung zu prüfen.
5
Rules testen & validieren
Abschluss ▶
Nach der Einrichtung sollte jede Rule einmal manuell validiert werden um sicherzustellen dass sie korrekt feuert.
Rule 1 testen: Mit einem Testkonto eine harmlose Inbox-Weiterleitungsregel anlegen (auf eigene Mailadresse) → prüfen ob Alert ausgelöst wird.
Rule 2 testen: KQL manuell im Advanced Hunting mit einem bekannten VPN-Login aus einem Nicht-DE-Land ausführen → Alert prüfen.
Rule 3 & 4: Schwellwerte kurz testweise drastisch senken (z.B. auf 2 statt 50), Rule manuell auslösen, dann wieder zurücksetzen.
Unter Hunting → Custom detection rules den Status aller Rules prüfen — grüner Status = läuft korrekt.
Monatliche Kontrolle einplanen: Rules unter Incidents & Alerts → Alerts auf false positives prüfen und Schwellwerte ggf. anpassen.