KQL Cheat Sheet: Quick Start, Operatoren und Beispiel-Queries

Definition

Kusto Query Language (KQL) ist eine Abfragesprache (query language) zur Analyse von Logs und Ereignisdaten in Microsoft-Diensten wie Azure Data Explorer und Log Analytics, u. a. als Basis für Abfragen in Microsoft Sentinel. Ein kql cheat sheet ist kein vollständiges Training, sondern eine kompakte Cheat-Sammlung für typische KQL Queries und Operatoren.

Einleitung

Wenn du in Microsoft Sentinel oder Log Analytics schneller zu belastbaren Antworten kommen willst, brauchst du wiederholbare KQL Queries statt „Klicken bis es passt“. Dieses KQL Cheat Sheet ist als quick reference gedacht: Quick Start, Kern-Operatoren und Beispiele, die du copy/paste anpassen kannst.

Wo KQL typischerweise eingesetzt wird (und warum es sich lohnt)

KQL taucht dort auf, wo viele Events in kurzer Zeit ausgewertet werden müssen: in Log Analytics (Azure Monitor), in Azure Data Explorer und im SIEM-Kontext von Microsoft Sentinel. In Security-Teams (SOC, Threat Hunting) bedeutet das: weniger Zeit bis zum Signal, weniger Fehlalarme durch bessere Filter und bessere Messbarkeit durch saubere Aggregationen.

• Operativ: schnellere Triage durch gezielte filters und klare columns
• Risiko: verdächtige Muster früher sichtbar, z. B. Anmeldefehler oder ungewöhnliche IPs
• Kosten: weniger manuelle Suchen, weil Templates wiederverwendbar sind

Core-KQL-Konzepte: Operatoren, die du wirklich brauchst

KQL liest sich als Pipeline: Tabelle → operatoren → Ergebnis. Die wichtigsten Bausteine für fast jede query:

• where (filter): Zeilen eingrenzen, z. B. über TimeGenerated, Status, Name, IP

• project und extend: columns auswählen bzw. neue Felder berechnen

• summarize mit count() und Zeitfunktionen: Muster erkennen statt Einzelzeilen lesen

Zeit ist in Logs zentral: ago() setzt Zeitfenster (timegenerated ago), bin() fasst in Intervalle zusammen (bin timegenerated), und desc sortiert für „neueste zuerst“.

Für Textsuche sind has und contains die häufigsten Operatoren. Für Korrelation über Datenquellen hinweg ist join wichtig. Für Lesbarkeit und Wiederverwendung im Team: let (KQL statement).

Quick Start: 3 Start-Queries zum Anpassen

Diese Beispiele sind bewusst einfach: erst Zeitfenster, dann filter, dann project. So bekommst du schnell „erste rows“, bevor du komplexer wirst.

• SigninLogs | where TimeGenerated > ago(24h) | project TimeGenerated, UserPrincipalName, IPAddress, ResultType | sort by TimeGenerated desc

• SecurityEvent | where TimeGenerated > ago(1d) | where EventID == 4625 | summarize count() by bin(TimeGenerated, 1h) | sort by TimeGenerated desc

• Resources | where type has "Microsoft.Compute/virtualMachines" | project name, location, resourceGroup

Hinweis: Tabellen wie SigninLogs und SecurityEvent sind typische Log-Analytics-Quellen; in Azure Resource Graph ist Resources eine zentrale Tabelle für Infrastruktur-Queries (resources microsoft, name location, location resourcegroup).

Beispiele für typische Sentinel- und SOC-Anwendungsfälle

Im SOC geht es selten um „eine“ Zeile, sondern um Muster: Was passiert häufig, bei wem, von wo, und seit wann?

Mini-Story: Ein Analyst sieht viele Fehlanmeldungen, aber erst die Aggregation macht es entscheidbar. Mit summarize count() und bin() werden Peaks sichtbar. Danach wird auf eine specific IP oder einen Benutzer eingegrenzt, um echte Angriffe von Tippfehlern zu trennen. Genau diese Reihenfolge spart Zeit und reduziert Risiko.

Für Threat Hunting (hunting) gilt: erst breit suchen (where + Zeitfenster), dann verdichten (summarize), dann gezielt nachschärfen (z. B. contains auf error-Strings oder Tags).

Best Practices: Templates, Migration und Betrieb ohne Chaos

Ein Cheat Sheet bringt Nutzen erst dann stabil, wenn Queries als Templates gepflegt werden. Bewährte Schritte:

• Standardisieren: gemeinsame Namenskonventionen, feste Output-Columns über project, klare Zeitfenster

• Wiederverwenden: let für Basisteile; Query-Bibliothek als „Download“-Ordner (z. B. signin-fails.kql, securityevent-auth.kql)

• Messbar machen: für wiederkehrende Fragen immer summarize-Ausgaben definieren (z. B. count bin pro Stunde/Tag)

Wenn eine Migration ansteht (z. B. von ad-hoc-Suchen zu wiederholbaren Sentinel-Analytics), starte nicht mit „alles bauen“. Starte mit 10 Kernfragen, die Betrieb und SOC tatsächlich täglich brauchen, und mache daraus saubere KQL Templates.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn KQL nicht mehr nur „ein paar queries“ ist, sondern Teil eines SOC-Prozesses oder eines Sentinel-Betriebs wird. Typische Trigger sind Zeitdruck, Risiko und Messbarkeit: Abfragen müssen wartbar sein, Ergebnisse müssen vergleichbar sein, und die Logik muss dokumentiert werden.

Gerade wenn mehrere Datenquellen (across) zusammenkommen und joins Standard werden, entscheidet Struktur über Betriebskosten: schlechte KQL kostet jeden Tag Zeit.

FAQ, Ressourcen und Download-Idee

Was ist der Unterschied zwischen KQL und SQL?

KQL ist für Analytics auf Events und Logs optimiert (schnelles Filtern, Aggregieren, Zeitreihen). SQL ist stärker für relationale Datenmodelle und Transaktionen gedacht.

Wo nutze ich KQL am häufigsten?

Typisch sind Log Analytics (Azure Monitor), Microsoft Sentinel sowie Azure Data Explorer. Im Security-Kontext kommt KQL außerdem in Hunting-Szenarien vor, z. B. im Umfeld von Microsoft Defender for Endpoint (Advanced Hunting).

Welche Operatoren sollte ich zuerst lernen?

Start mit where, project, summarize, count(), ago(), bin(). Danach extend, has/contains und join.

Gibt es eine Download-Option für Templates?

Pragmatisch: lege intern einen Ordner „KQL Quick Reference“ an, speichere Templates als .kql und pflege eine kurze README pro Query (Zweck, Eingaben, erwartete Ausgabe). Als resources/weiterlesen eignen sich außerdem die offiziellen Microsoft docs zu Kusto Query Language und die KQL-Referenz.