> For the complete documentation index, see [llms.txt](https://hacking-3.gitbook.io/barre/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-3.gitbook.io/barre/apuntes/blue-team/splunk/spl.md). # SPL ### 1. Qué es SPL **SPL (Search Processing Language)** es el lenguaje de búsqueda de Splunk. No es solo un lenguaje para “buscar texto”: es un lenguaje completo de procesamiento de datos que permite: * Buscar eventos en índices. * Filtrar datos por campos, tiempo, texto. * Extraer campos de eventos crudos (`_raw`). * Transformar eventos en tablas y series temporales. * Calcular estadísticas y agregaciones. * Crear dashboards y visualizaciones. * Crear alertas y detecciones programadas. * Desarrollar reglas de detección de seguridad (use cases). * Hacer threat hunting exploratorio. * Normalizar datos heterogéneos a un modelo común (CIM). * Enriquecer eventos con lookups (listas de referencia externas). * Correlacionar eventos entre distintas fuentes. * Analizar series temporales (tendencias, picos, baselines). * Optimizar búsquedas sobre grandes volúmenes de datos. SPL está compuesto, según la documentación oficial de Splunk, por **search commands** (comandos de búsqueda), **functions** (funciones), **arguments** (argumentos) y **clauses** (cláusulas). Es decir, no es solo “una sintaxis de búsqueda de texto”, sino un lenguaje con piezas combinables como en SQL, aunque con una filosofía distinta: en SPL los datos fluyen a través de una **tubería (`|`, pipe)** de comandos, cada uno transformando el resultado del anterior. #### Estructura básica de una búsqueda ``` index=main sourcetype=access_combined status=500 | stats º BY host | sort - count ``` Interpretación paso a paso: * `index=main sourcetype=access_combined status=500`: es la **búsqueda base**. Aquí Splunk decide qué eventos crudos recuperar de los índices. * `|` (pipe): envía (canaliza) el conjunto de resultados obtenido hasta ese punto al siguiente comando. Es el equivalente conceptual a una tubería Unix (`cmd1 | cmd2`). * `stats count BY host`: agrupa los eventos por el campo `host` y cuenta cuántos eventos hay en cada grupo. Convierte eventos individuales en una tabla agregada. * `sort - count`: ordena la tabla resultante de mayor a menor según el campo `count` (el signo indica orden descendente). La idea central para razonar sobre cualquier búsqueda SPL es: ``` Buscar datos → Filtrar → Crear campos → Agregar → Ordenar → Mostrar ``` *** ### 2. Anatomía de una búsqueda SPL Toda búsqueda SPL, por compleja que sea, se puede descomponer en las mismas piezas: #### Búsqueda base ``` index=windows sourcetype=WinEventLog:Security EventCode=4624 ``` Es el punto de entrada. Define qué datos se recuperan de los índices (de disco/almacenamiento) antes de aplicar cualquier procesamiento adicional. #### Pipe ``` | ``` Encadena comandos. Cada comando recibe como entrada la salida (el conjunto de resultados) del comando anterior. #### Comando Ejemplos: `stats`, `eval`, `where`, `table`, `lookup`, `rex`. Un comando realiza una acción concreta sobre el conjunto de eventos/resultados que recibe. #### Argumentos ``` count BY user ``` Son los parámetros que recibe un comando para modificar su comportamiento (en este caso, `count` es la función estadística y `BY user` indica la dimensión de agrupación). #### Funciones ``` count(), dc(), avg(), sum(), if(), case(), coalesce() ``` Cálculos concretos que se usan dentro de comandos como `eval` o `stats`. #### Campos ``` user, src_ip, dest_ip, host, _time, _raw ``` Son las “columnas” de cada evento. Algunos son generados automáticamente por Splunk al indexar (`_time`, `_raw`, `_indextime`…), otros provienen de la extracción de datos (`user`, `src_ip`…). #### Alias ``` AS total ``` Permite renombrar el resultado de una función o campo calculado para que sea más legible en la salida. #### Ejemplo completo comentado ``` index=windows sourcetype=WinEventLog:Security EventCode=4625 earliest=-24h | stats count AS failed_logons dc(src_ip) AS unique_sources BY user | where failed_logons > 10 | sort - failed_logons ``` * Busca eventos de login fallido (`EventCode=4625`) en las últimas 24 horas. * Cuenta el número de fallos y el número de IPs origen distintas, por usuario. * Filtra para quedarse solo con usuarios con más de 10 fallos. * Ordena de mayor a menor número de fallos. *** ### 3. Comandos, funciones y operadores: diferencias clave Es fundamental no confundir estos tres conceptos porque tienen roles distintos en una query: #### Comando Un **comando** ejecuta una acción sobre el conjunto de eventos/resultados. Ejemplos: `stats`, `eval`, `where`, `table`, `fields`, `lookup`, `rex`, `sort`. ``` | stats count BY user ``` Aquí `stats` es el comando. #### Función Una **función** calcula un valor. Se usa normalmente dentro de un comando (como `eval` o `stats`). Ejemplos: `count()`, `if()`, `case()`, `lower()`, `round()`, `coalesce()`, `dc()`, `values()`. ``` | eval user=lower(user) ``` Aquí `lower()` es la función, y `eval` es el comando que la ejecuta. #### Operador Un **operador** compara, combina o calcula valores entre términos. Ejemplos: `=`, `!=`, `>`, `<`, `>=`, `<=`, `AND`, `OR`, `NOT`, `+`, `-`, `*`, `/`, `%`, `.` (concatenación). ``` | where count > 10 AND status="failure" ``` Aquí `>` y `AND` son operadores. **Regla mental**: si algo *hace* algo con todo el conjunto de resultados → comando. Si algo *calcula* un valor → función. Si algo *compara o combina* dos valores → operador. *** ### 4. Orden recomendado para optimizar una query La regla de oro en SPL es: **filtra lo máximo posible, lo antes posible**. La documentación oficial de optimización de Splunk indica que la clave para búsquedas rápidas es limitar al mínimo los datos que se leen de disco, filtrar lo antes posible y usar la ventana temporal más pequeña posible. #### Orden ideal de una búsqueda SPL optimizada ``` index= sourcetype= earliest=