KQL-Grundlagen für jeden SOC-Analysten

Kusto Query Language (KQL) ist das Rückgrat der Threat Hunting und Alert Triage in Microsoft Sentinel und Microsoft Defender. Wenn Sie in einem SOC arbeiten, trennt KQL-Flüssigkeit Analysten, die schnell "Was ist hier passiert?" beantworten können, von denen, die sich durch Dashboards klicken. Dies ist keine vollständige Sprachreferenz — es ist die praktische Teilmenge, die ständig im Dienst verwendet wird.

Warum KQL im SOC wichtig ist

KQL ist schreibgeschützt und optimiert für schnelle Abfragen großer Log-Datensätze. Sentinel, Defender for Endpoint, Azure Monitor und Log Analytics sprechen alle KQL. Sobald Sie es beherrschen, können Sie zwischen Produkten mit demselben mentalen Modell wechseln: eine Tabelle auswählen, sie eingrenzen, die Ausgabe strukturieren. Jede Untersuchung — Phishing-Triage, Lateral-Movement-Hunts, False-Positive-Tuning — beginnt mit einer Abfrage.

Die Pipe ist alles

KQL-Abfragen werden als Pipeline aufgebaut. Sie beginnen mit einer Tabelle und leiten Daten durch eine Reihe von Operatoren, von denen jeder das vorherige Ergebnis filtert, transformiert oder zusammenfasst:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

Lesen Sie es von oben nach unten wie einen Satz: Beginnen Sie mit SecurityEvent-Logs, behalten Sie nur fehlgeschlagene Anmeldungen (4625), beschränken Sie sich auf den letzten Tag, zählen Sie Fehler pro Konto/Computer, dann sortieren Sie. Diese lineare Lesbarkeit ist KQLs größter Vorteil gegenüber SQL für Ad-hoc-Hunts.

Wichtige Operatoren zum Merken

• where — Ihr primärer Filter. Verwenden Sie ihn früh und oft, um Datenvolumen vor teuren Operationen zu reduzieren.
• project — Wählen Sie spezifische Spalten aus und benennen Sie sie um, wobei Sie den Lärm verwerfen, den Sie in der Ausgabe nicht benötigen.
• extend — Fügen Sie berechnete Spalten hinzu, ohne vorhandene zu löschen. Nützlich zum Analysieren von Strings oder zum Markieren von Bedingungen.
• summarize — Aggregieren Sie Daten mit count(), sum(), dcount() oder make_set(), fast immer mit by gepaart.
• join — Korrelieren Sie über Tabellen hinweg, z. B. beim Verknüpfen von Anmeldungs-Logs mit Geräte-Inventar, um nicht verwaltete Geräte-Anmeldungen zu erkennen.
• render — Visualisieren Sie Ergebnisse als Zeitdiagramm oder Balkendiagramm direkt im Abfrage-Editor, praktisch zum Erkennen von Spitzen.

Zeitfilterung richtig durchführen

Filtern Sie immer auf TimeGenerated (oder die äquivalente Zeitstempel-Spalte der Tabelle) so früh wie möglich in der Pipeline. KQL-Engines optimieren stark um Zeit-Range-Filter, und das Platzieren von | where TimeGenerated > ago(7d) oben statt unten kann den Unterschied zwischen einer Abfrage, die in Sekunden zurückkehrt, und einer, die auf einem ausgelasteten Mandanten ausläuft, ausmachen.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## String-Matching: has vs contains vs ==

Ein häufiger Fehler ist, standardmäßig `contains` für alles zu verwenden. `has` stimmt mit ganzen Begriffen überein und verwendet einen Begriff-Index, was es auf großen Tabellen dramatisch schneller macht. Verwenden Sie `contains` nur, wenn Sie Substring-Übereinstimmungen innerhalb eines Wortes benötigen (wie ein partielles Domain-Fragment), und verwenden Sie `==` für exakte Übereinstimmungen bei strukturierten Feldern wie EventID oder IPAddress. Diese eine Gewohnheit beschleunigt Hunts über Large-Volume-Tabellen wie `DeviceNetworkEvents` oder `CommonSecurityLog` merklich.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Wiederverwendbare Erkennungslogik aufbauen

Sobald eine Abfrage sich als nützlich erweist, binden Sie sie als Funktion mit let ein, oder speichern Sie sie als Sentinel Analytics Rule mit geplanter Ausführung. Parametrisieren Sie Schwellwerte (wie fehlgeschlagene Anmeldungszahlen), damit die gleiche Logik über Mandanten skaliert oder ohne Neuschreiben angepasst wird. So entwickeln sich einmalige Hunting-Abfragen zu stehenden Erkennungen, die den SOC automatisch aufrufen.

Häufige Fallstricke

• Vergessen von TimeGenerated-Filtern, was zu langsamen, teuren Vollzugriff-Scans führt.
• Verwendung von summarize vor where, was die Engine zwingt, ungefilterte Daten zu aggregieren.
• Nicht übereinstimmende Spaltennamen beim Verknüpfen von Tabellen — überprüfen Sie Schema immer zuerst mit getschema.
• Übernutzung von contains, das Indizierungsvorteile überspringt und Large-Scale-Hunts verlangsamt.

KQL belohnt Analysten, die in Pipelines denken, nicht in verschachtelten Unterabfragen. Beginnen Sie jede Untersuchung mit einem engen Zeitfenster und einer spezifischen Tabelle, dann erweitern Sie nur bei Bedarf.

Wenn dies Ihnen eine solide Grundlage gab, erkunden Sie die Blue Team und Digital Forensics Segmente auf Korra Studio für weitere praktische SOC-Abfrage-Walkthroughs und Erkennungsaufbau-Übungen.