Conceptos Básicos de KQL que Todo Analista SOC Debe Conocer

Kusto Query Language (KQL) es la base de la búsqueda de amenazas y la clasificación de alertas en Microsoft Sentinel y Microsoft Defender. Si trabajas en un SOC, el dominio de KQL diferencia a los analistas que pueden responder rápidamente "¿qué pasó aquí?" de aquellos atrapados haciendo clic en paneles. Esto no es una referencia de lenguaje completa — es el subconjunto práctico que se utiliza constantemente durante el turno.

Por Qué KQL es Importante en el SOC

KQL es de solo lectura y está optimizado para consultar rápidamente conjuntos de datos masivos de registros. Sentinel, Defender for Endpoint, Azure Monitor y Log Analytics todos lo hablan. Una vez que lo conoces, puedes moverte entre productos con el mismo modelo mental: selecciona una tabla, filtrala, da forma a la salida. Cada investigación — clasificación de phishing, búsquedas de movimiento lateral, ajuste de falsos positivos — comienza con una consulta.

El Pipe es Todo

Las consultas de KQL se construyen como un pipeline. Comienzas con una tabla y pasas datos a través de una serie de operadores, cada uno filtrando, transformando o resumiendo el resultado anterior:

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

Léelo de arriba a abajo como una oración: comienza con registros de SecurityEvent, mantén solo los logons fallidos (4625), restringe al último día, cuenta los fallos por cuenta/computadora, luego ordena. Esa legibilidad lineal es la mayor fortaleza de KQL sobre SQL para búsquedas ad hoc.

Operadores Principales para Memorizar

• where — tu filtro principal. Úsalo temprano y frecuentemente para reducir el volumen de datos antes de operaciones costosas.
• project — selecciona y renombra columnas específicas, descartando ruido innecesario en la salida.
• extend — añade columnas computadas sin eliminar las existentes, útil para analizar cadenas o marcar condiciones.
• summarize — agrega datos con count(), sum(), dcount() o make_set(), casi siempre emparejado con by.
• join — correlaciona entre tablas, p. ej., vinculando registros de inicio de sesión con inventario de dispositivos para detectar logons de dispositivos no administrados.
• render — visualiza resultados como un timechart o barchart directamente en el editor de consultas, útil para detectar picos.

Filtrado de Tiempo Hecho Bien

Siempre filtra en TimeGenerated (o la columna de marca de tiempo equivalente de la tabla) lo más pronto posible en el pipeline. Los motores KQL optimizan mucho alrededor de filtros de rango de tiempo, y poner | where TimeGenerated > ago(7d) cerca de la parte superior en lugar de la inferior puede ser la diferencia entre una consulta que se devuelve en segundos y una que agota el tiempo en un inquilino ocupado.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Coincidencia de Cadenas: has vs contains vs ==

Un error común es usar `contains` por defecto para todo. `has` coincide con términos completos e utiliza un índice de términos, haciéndolo dramáticamente más rápido en tablas grandes. Usa `contains` solo cuando necesites coincidencias de subcadenas dentro de una palabra (como un fragmento de dominio parcial), y usa `==` para coincidencias exactas en campos estructurados como EventID o IPAddress. Este único hábito acelera notablemente las búsquedas en tablas de alto volumen como `DeviceNetworkEvents` o `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Construyendo Lógica de Detección Reutilizable

Una vez que una consulta demuestra ser útil, envuélvela como una función con let, o guárdala como una Regla Analítica de Sentinel con ejecución programada. Parametriza umbrales (como conteos de logons fallidos) para que la misma lógica se escale entre inquilinos u obtenga ajustes sin reescribir desde cero. Así es como las consultas de búsqueda únicas evolucionan hacia detecciones permanentes que alertan al SOC automáticamente.

Trampas Comunes

• Olvidar filtros TimeGenerated, causando escaneos de tabla completa lentos y costosos.
• Usar summarize antes de where, lo que fuerza al motor a agregar datos sin filtrar.
• Nombres de columnas no coincidentes al unir tablas — siempre verifica el esquema con getschema primero.
• Usar excesivamente contains, que salta los beneficios de indexación y ralentiza las búsquedas a gran escala.

KQL recompensa a los analistas que piensan en pipelines en lugar de subconsultas anidadas. Comienza cada investigación con una ventana de tiempo estrecha y una tabla específica, luego amplía solo según sea necesario.

Si esto te dio una base sólida, explora los segmentos de Blue Team y Digital Forensics en Korra Studio para más recorridos de consultas SOC prácticos y ejercicios de construcción de detecciones.