Módulo 2: El laboratorio: SIEM gratuito y telemetría real

Antes de escribir una sola regla de detección hace falta un sitio donde probarla sin miedo a tumbar nada real. Este módulo monta ese sitio: un SIEM funcionando en tu propio portátil, con un generador de telemetría Windows y un endpoint Linux al lado, y una forma de meterle datos de ataques reales sin instalar malware ni levantar un dominio de Active Directory.

La comparación de plataformas que viene a continuación es deliberadamente incómoda con todas ellas: cada una tiene un límite que su propio fabricante reconoce por escrito, y ese límite es justo lo que hay que conocer antes de elegir dónde vas a pasar las próximas semanas construyendo.

Qué aprenderás

• A comparar Wazuh, Security Onion 2.4, Splunk en su modalidad gratuita y la pila de Elastic por lo que documentan, no por fama.
• A dimensionar un laboratorio de tres máquinas (SIEM, generador Windows, endpoint Linux) con cifras reales de requisitos.
• A instalar Wazuh con el asistente oficial todo-en-uno y comprobar que el manager, el indexador y el panel han levantado.
• A enrolar un agente en Windows y otro en Linux contra ese manager.
• A localizar y usar EVTX-ATTACK-SAMPLES, Security-Datasets y BOTSv3 para tener telemetría de ataques reales sin ejecutarlos tú.
• A convertir un fichero .evtx suelto en algo que Wazuh pueda indexar, y a verificar que ha entrado.
• A aplicar higiene básica de laboratorio: aislamiento de red, instantáneas y el límite legal de dónde se puede probar esto.
• A entender qué papel juega este laboratorio en el resto del curso, desde la activación de telemetría hasta el despliegue de reglas.

Cuatro plataformas gratuitas para montar un SOC casero

Ninguna de las cuatro es gratis sin condiciones. Wazuh y Security Onion son software libre de verdad, sin límite artificial de volumen, pero exigen que tú administres el servidor. Splunk regala una licencia con un techo diario duro. Elastic dejó de ser código abierto en 2021 y volvió a serlo en 2024, con una capa gratuita que cubre bastante más de lo que la gente asume.

Cada fila de la tabla y cada cifra que sigue vienen de la documentación oficial del propio proyecto, enlazada donde corresponde. Es una elección deliberada: en foros y comparativas de terceros circulan cifras de «requisitos mínimos» y de «qué incluye la versión gratuita» que llevan años sin actualizarse, y varias de las cuatro plataformas han cambiado de licencia o de tabla de requisitos en los últimos dos años.

Plataforma	Qué incluye	Lo que hace bien	Dónde se nota el límite
Wazuh (manager + indexer + dashboard)	Agente universal, motor de reglas y decodificadores, indexador basado en OpenSearch, panel basado en OpenSearch Dashboards	Instalación todo-en-uno oficial en un solo comando; sin techo de volumen; agente ligero para Windows/Linux/macOS	Sin soporte nativo para leer un .evtx suelto; hay que exportarlo y decodificarlo a mano
Security Onion 2.4	Suricata, Zeek, Elastic Agent, osquery, Elasticsearch, Security Onion Console (SOC) con Alerts, Hunt, Cases y Detections	Importación nativa de .evtx y .pcap desde la propia consola web; visión de red de fábrica	Consume mucha más RAM que Wazuh para un laboratorio equivalente; los componentes Elastic van bajo Elastic License 2.0
Splunk (licencia gratuita)	Splunk Enterprise completo con una licencia Free aplicada	Lenguaje de búsqueda (SPL) muy potente para explorar datos ya indexados	500 MB de indexación al día, sin alertas, sin reenvío por TCP/HTTP, un único nodo sin login
Elastic Stack (autogestionado, nivel gratuito)	Elasticsearch, Kibana, Elastic Agent, detección de seguridad con reglas out-of-the-box	Capa gratuita con RBAC, TLS, autenticación nativa y alertado de seguridad ya incluidos desde 2021	No hay una tabla oficial de requisitos mínimos como en Wazuh o Security Onion: depende del volumen que decidas indexar

Wazuh: manager, indexer y dashboard

La documentación oficial de Wazuh describe la plataforma como una solución de XDR y SIEM unificados compuesta por un agente universal y tres componentes centrales: el servidor (motor de reglas y decodificadores), el indexador (basado en OpenSearch) y el panel (un fork de OpenSearch Dashboards, según reconoce el propio repositorio del proyecto). La versión vigente en el momento de escribir esto es la 4.14.6, publicada el 1 de julio de 2026. El proyecto está licenciado bajo GPLv2.

Wazuh no exige un dominio de Windows ni una infraestructura compleja: el asistente de instalación todo-en-uno deja los tres componentes centrales funcionando en un único host Linux en pocos minutos, algo que ni Security Onion ni una pila de Elastic hecha a mano ofrecen de fábrica.

Security Onion 2.4

Security Onion se define en su propia documentación como «una plataforma libre y abierta construida por defensores para defensores». Integra captura y análisis de red (Suricata, Zeek, Stenographer, Strelka), visibilidad de host mediante Elastic Agent y osquery, y una consola propia (SOC) con pestañas de Alerts, Dashboards, Hunt, Cases, recuperación de PCAP y Detections. La mayor parte del software es de código abierto, pero los componentes que provienen de Elastic (Elasticsearch, Kibana) van bajo Elastic License 2.0, según la propia página de licencia del proyecto.

La razón por la que aparece en esta comparación aunque el resto del módulo instale Wazuh es una sola herramienta: so-import-evtx. Es una utilidad documentada que importa uno o varios ficheros .evtx directamente desde la consola web o por línea de comandos, algo que ni Wazuh ni una pila de Elastic sin trabajo adicional resuelven de serie. Si tu prioridad es importar volcados forenses de terceros sin escribir un decodificador, Security Onion te ahorra ese paso.

Splunk en su modalidad gratuita

La documentación oficial de Splunk deja los límites de la licencia Free por escrito: 500 MB de indexación al día; si se supera, se recibe un aviso de violación de licencia, y tres avisos en una ventana móvil de 30 días bloquean la búsqueda hasta bajar de ese umbral (la indexación sigue funcionando). No hay pantalla de login: se entra directamente como administrador. No hay clustering de búsqueda ni de indexadores, no hay alertado, y el reenvío por TCP o HTTP está deshabilitado. La propia página lo resume así: «The Free license is for a standalone, single-instance use only installation».

Un detalle que se pasa por alto con frecuencia: hoy no existe un instalador separado llamado «Splunk Free». Se descarga Splunk Enterprise y se le aplica la licencia gratuita. Eso significa que técnicamente tienes el mismo motor que en producción, con el grifo de datos cerrado a 500 MB diarios y sin forma de repartir la carga entre varios nodos, lo que lo deja fuera de un laboratorio de tres máquinas que reenvían telemetría a un nodo central.

La pila de Elastic

Elasticsearch y Kibana pasaron por dos giros de licencia relevantes para quien vaya a usarlos gratis. En 2021 se relicenciaron bajo Elastic License v2 y SSPL, dejando de ser código abierto en sentido estricto. En 2024 Elastic añadió AGPLv3 como tercera opción, con lo que el propio fabricante lo anunció como «Elasticsearch is open source. Again.» Hoy el código se distribuye bajo triple licencia (SSPL 1.0, AGPLv3 o Elastic License v2), a elección del usuario.

La capa gratuita autogestionada (Basic) incluye autenticación nativa, control de acceso basado en roles, TLS y detección de amenazas con alertado ya integrado, funciones que hasta 2021 eran de pago. Elastic no publica una tabla de requisitos mínimos fija como la de Wazuh o Security Onion: la recomendación oficial para el tamaño del heap de la JVM es no superar el 50% de la RAM total del nodo, con un techo práctico de entre 26 y 30 GB por el límite de los compressed ordinary object pointers, según la documentación de referencia de Elasticsearch. Para un laboratorio pequeño esto se traduce en que necesitas más memoria libre de la que sugiere un primer vistazo, porque Elasticsearch reserva la mitad de la RAM para el sistema operativo y el caché de disco.

Arquitectura mínima del laboratorio

Tres máquinas bastan para todo lo que viene en este curso: una con el SIEM, una Windows que genere telemetría y una Linux que haga de segundo endpoint. No hace falta un controlador de dominio: casi toda la telemetría que vas a analizar en los próximos módulos, y toda la de este, viene de máquinas aisladas o de ficheros ya grabados.

Máquina	Rol	Sistema operativo sugerido	Notas
Host del SIEM	Wazuh server + indexer + dashboard (todo-en-uno)	Ubuntu 22.04/24.04 o Red Hat Enterprise Linux 8/9 (recomendados por Wazuh)	Con dos agentes reales conectados te sobra con el perfil más bajo de la tabla de Wazuh (ver abajo)
Generador de telemetría Windows	Agente Wazuh instalado, endpoint donde más adelante activarás auditoría y Sysmon	Windows 10/11 o Windows Server 2019/2022	No necesita GPU ni disco grande; es el equipo donde «pasan cosas» para el resto del curso
Endpoint Linux	Agente Wazuh instalado, segundo origen de logs (auth.log, journald)	Ubuntu, Debian o cualquier distribución con systemd	Sirve también para practicar decodificadores de logs de servicios como SSH o sudo más adelante

El único dato oficial de dimensionado que existe es el de la documentación de Wazuh, referido al host del SIEM y a la cantidad de agentes conectados, no al número de máquinas físicas:

Agentes conectados	CPU	RAM	Almacenamiento (90 días de alertas)
1-25	4 vCPU	8 GiB	50 GB
25-50	8 vCPU	8 GiB	100 GB
50-100	8 vCPU	8 GiB	200 GB

Con dos agentes de laboratorio te quedas en el primer escalón sin problema: 4 vCPU y 8 GiB para el host del SIEM. Para la máquina Windows, calcula lo que ya pide el propio sistema operativo (Microsoft recomienda un mínimo que crece con cada versión) más un margen cómodo; en la práctica, 4 GB de RAM asignados a la VM Windows y 2 GB a la VM Linux funcionan bien para lo que este curso te va a pedir hacer en ellas. Esto último es una recomendación de dimensionado propia, no una cifra que salga de ningún documento de Wazuh, Microsoft o de las distribuciones Linux: ajústala si notas que se queda corta.

Si prefieres virtualizar todo en un único host físico, cuenta con al menos 16 GB de RAM libres para las tres VMs a la vez y unos 100 GB de disco, y activa la virtualización anidada solo si vas a correr las tres VMs a la vez desde una máquina que ya es en sí misma una VM (poco frecuente en portátiles personales).

Instalación de Wazuh paso a paso

Antes de instalar

Wazuh recomienda un procesador Linux de 64 bits (Intel, AMD o ARM) y, entre los sistemas operativos probados, cualquiera de estos: Amazon Linux 2, Amazon Linux 2023, CentOS Stream 10, Red Hat Enterprise Linux 7 a 10, o Ubuntu 16.04, 18.04, 20.04, 22.04 y 24.04. Para un laboratorio nuevo, Ubuntu 24.04 es la opción con más soporte a largo plazo.

Antes de tocar nada, saca una instantánea de la VM en blanco. Es el punto exacto al que vas a querer volver si algo del resto del curso deja el host en mal estado.

Instalación con el asistente todo-en-uno

El propio equipo de Wazuh publica un script que instala y configura los tres componentes centrales (indexer, server y dashboard) en el mismo host. Se descarga y se ejecuta así:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

El proceso dura entre varios minutos dependiendo del ancho de banda y de la potencia del host. Al terminar, muestra un resumen con la URL del panel y la contraseña de administrador. La documentación oficial reproduce el mensaje final tal cual lo imprime el instalador:

INFO: --- Summary ---
INFO: You can access the web interface https://<WAZUH_DASHBOARD_IP_ADDRESS>
    User: admin
    Password: <ADMIN_PASSWORD>
INFO: Installation finished.

Si cierras esa terminal antes de apuntar la contraseña, no hace falta reinstalar nada: todas las contraseñas generadas (indexador y usuarios de la API) quedan guardadas en wazuh-passwords.txt dentro de wazuh-install-files.tar, y se recuperan así:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Primer acceso y verificación de servicios

Abre https://<IP-DEL-HOST> desde el navegador. El certificado es autofirmado por defecto, así que el aviso de «conexión no privada» es esperable: acéptalo como excepción para el laboratorio (nunca hagas eso en un panel expuesto a Internet). Entra con el usuario admin y la contraseña que has recuperado.

Para comprobar que los tres servicios están arriba antes incluso de abrir el navegador, en el propio host del SIEM:

sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

Los tres deberían aparecer como active (running). Si alguno falla al arrancar justo después de la instalación, es casi siempre un problema de RAM insuficiente para el indexador (basado en una JVM, igual que Elasticsearch): sube la memoria de la VM antes de investigar nada más.

Añadir los otros dos equipos del laboratorio

Antes de enrolar nada, abre en tu red interna los tres puertos que la documentación de Wazuh exige para la comunicación agente-manager: 1514/TCP para el tráfico normal del agente, 1515/TCP para la enrolación automática y 55000/TCP para quien enrole a través de la API del servidor. En una red «solo anfitrión» de laboratorio, sin cortafuegos de por medio, no suele hacer falta tocar nada; en una red con más restricciones, es el primer sitio donde mirar si un agente se queda en estado «Never connected».

En la VM Windows, con el instalador MSI descargado desde el paquete de la versión correspondiente, la enrolación contra el manager se hace con una única línea que fija la IP del servidor como parámetro del propio instalador:

msiexec.exe /i wazuh-agent-4.14.6-1.msi /q WAZUH_MANAGER="<IP-DEL-HOST-SIEM>"

Y se arranca el servicio con:

NET START WazuhSvc

En la VM Linux (familia Debian/Ubuntu), la documentación oficial añade primero el repositorio de paquetes de Wazuh:

apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update

Y después instala y enrola el agente en un solo paso, pasando la IP del manager como variable de entorno:

WAZUH_MANAGER="<IP-DEL-HOST-SIEM>" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Con esto, en el panel, la sección de agentes debería mostrar dos entradas activas: la Windows y la Linux. No hace falta que generen tráfico todavía: eso llega con la activación de telemetría en un módulo posterior, que retoma exactamente estas dos máquinas.

Telemetría ya grabada: la parte que no necesita un dominio

Montar un controlador de dominio solo para tener eventos de Kerberos, o ejecutar malware real para tener eventos de inyección de proceso, es desproporcionado cuando lo que quieres es aprender a escribir y validar una regla. Por eso existen repositorios de eventos ya capturados, con licencias abiertas que permiten reutilizarlos con fines de estudio y prueba.

EVTX-ATTACK-SAMPLES

Mantenido por Samir Bousseaden, este repositorio guarda 278 ficheros .evtx (recuento hecho directamente sobre el árbol del repositorio el día de escritura de este módulo), organizados en carpetas que se corresponden con tácticas de MITRE ATT&CK: Command and Control, Credential Access, Defense Evasion, Discovery, Execution, Lateral Movement, Persistence, Privilege Escalation y una carpeta Other para lo que no encaja en una sola. El propio repositorio indica que «mapping has been done to the level of ATT&CK technique (not procedure)», así que cada nombre de fichero apunta a una técnica concreta, no a un grupo o campaña. Está licenciado bajo GPL-3.0.

Un ejemplo dentro de la carpeta Discovery es discovery_local_user_or_group_windows_security_4799_4798.evtx (68 KB), que vamos a usar en el ejercicio de este módulo.

Security-Datasets del Open Threat Research Forge

El proyecto (antes conocido como Mordor) lo describe su propia introducción como una iniciativa que «contributes malicious and benign datasets, from different platforms, to the infosec community to expedite data analysis and threat research». Organiza los datos por plataforma (Windows, Linux, AWS) y, dentro de cada plataforma, por táctica de ATT&CK (defense_evasion, credential_access, discovery, persistence, lateral_movement, execution…). Distingue entre datasets atómicos, que capturan una sola técnica, y datasets compuestos, que encadenan varias fases de un ataque completo. Los eventos de host se sirven en JSON, empaquetados en ficheros ZIP dentro del repositorio. El repositorio está licenciado bajo MIT.

BOTSv3 de Splunk

Boss of the SOC versión 3 es el dataset que Splunk usa para su propia competición de CTF y que después libera para todo el mundo. El repositorio en GitHub declara licencia CC0-1.0 (dominio público) y describe el contenido como evidencia de incidentes reales o de recreaciones de laboratorio realistas, con más de 100 sourcetypes distintos entre servicios de AWS, plataformas de Microsoft, dispositivos Cisco, Symantec Endpoint Protection y tráfico de red. El dataset en sí (no el repositorio de metadatos) pesa 320,1 MB en formato pre-indexado de Splunk y se descarga desde un bucket S3 público (botsv3_data_set.tgz), con hash MD5 publicado para verificar la descarga. Una vez importado en un Splunk con los add-ons correspondientes, se consulta con index=botsv3.

De los tres, BOTSv3 es el más pesado para tu laboratorio y el que menos encaja con Wazuh: está pensado para Splunk. Si más adelante quieres practicar con él, necesitarás una instancia de Splunk aparte (con las limitaciones de la licencia Free ya comentadas) o, más realista, subirlo a un Splunk de pago temporal o a una prueba gratuita en la nube.

Cómo meter un EVTX de muestra dentro de Wazuh

Aquí hay que ser honesto con una limitación real: el recolector de logs de Wazuh no lee ficheros .evtx directamente. Así lo confirma un issue abierto en el repositorio oficial del proyecto, donde se explica que la vía de trabajo es exportar el evento a otro formato (CSV, texto o XML) y construir un decodificador para ese formato. Es justo lo contrario de lo que hace so-import-evtx en Security Onion, que sí importa el binario tal cual.

El procedimiento, paso a paso:

1. Exportar el .evtx a texto

Copia el fichero de muestra a la VM Windows y expórtalo con la herramienta nativa wevtutil. La opción /lf:true le dice que el primer argumento es la ruta a un fichero de log, no el nombre de un canal en vivo:

wevtutil qe "<ruta>discovery_local_user_or_group_windows_security_4799_4798.evtx" /lf:true /f:text > C:wazuh-labsalida.txt

Antes de ingerir nada, mira cuántos eventos y de qué tipo trae el fichero, para tener un número con el que comparar después de la ingesta:

wevtutil gli "<ruta>discovery_local_user_or_group_windows_security_4799_4798.evtx" /lf:true

2. Apuntar el agente al fichero exportado

En el ossec.conf del agente Windows añade un bloque <localfile> que vigile ese fichero de texto. Wazuh admite varios formatos para logs planos (syslog, generic, json, multi-line); dado que la salida de wevtutil /f:text reparte cada evento en varias líneas, el formato adecuado es multi-line:

<localfile>
  <log_format>multi-line</log_format>
  <location>C:wazuh-labsalida.txt</location>
</localfile>

3. Escribir y validar un decodificador propio

Sin un decodificador que reconozca ese formato, Wazuh recibe las líneas pero no extrae ningún campo. La guía oficial de decodificadores personalizados muestra la estructura mínima: un decodificador «padre» que identifica el tipo de log y uno o varios «hijos» con expresiones regulares que capturan campos concretos. Se escriben en local_decoder.xml (no en el ruleset por defecto, para que no se sobrescriban en la próxima actualización) y se ajustan a las columnas reales de tu salida.txt: no hay una regex universal que sirva para cualquier exportación, así que constrúyela sobre tu propio fichero y valida cada cambio con la herramienta de pruebas antes de tocar la configuración en caliente:

/var/ossec/bin/wazuh-logtest

Pega una línea real de tu salida.txt cuando la herramienta te lo pida. Te devuelve tres fases (pre-decodificación, decodificación y evaluación de reglas) y te dice, antes de arriesgar nada en producción, si tu decodificador está extrayendo campos o si la línea pasa sin tocar ninguna regla.

4. Activar los archivos para no depender de que exista una regla que dispare alerta

Por defecto, Wazuh solo indexa eventos que hacen saltar una regla con nivel de severidad suficiente. Un evento decodificado pero sin regla propia puede no aparecer nunca en el panel. La solución documentada es activar el archivado completo en el ossec.conf del manager, dentro de <global>:

<global>
  <logall>yes</logall>
  <logall_json>yes</logall_json>
</global>

Solo logall_json genera el formato que se puede indexar y visualizar en el panel, según indica la propia documentación de Wazuh. Con esto activo, y con el módulo de archivos habilitado en la configuración de Filebeat del servidor, cada evento recibido (dispare o no una alerta) queda disponible bajo el patrón de índice wazuh-archives-*, distinto del wazuh-alerts-* que solo guarda coincidencias de reglas.

5. Comprobar que ha entrado

En el panel, ve a Explore > Discover (heredado de OpenSearch Dashboards) y crea, si todavía no existe, un patrón de índice wazuh-archives-* con timestamp como campo de tiempo. Filtra por el nombre del agente Windows y busca el texto 4798 o 4799. El número de coincidencias debería corresponder con lo que viste al ejecutar wevtutil gli antes de exportar: si el fichero original tenía, por ejemplo, dos eventos de ese tipo, deberías ver dos documentos en Discover con esos IDs. Esa comparación, entre el conteo original del .evtx y lo que aparece indexado, es la prueba real de que la ingesta ha funcionado, no una captura de pantalla de una alerta bonita.

Para contexto sobre lo que documentan esos dos identificadores: según la referencia archivada de Microsoft (con fecha de revisión de 2021, en el árbol de documentación retirada de Windows 10), el evento 4798 pertenece a la subcategoría «Audit User Account Management» y se genera cuando un proceso enumera los grupos locales de un usuario; el 4799, de la subcategoría «Audit Security Group Management», se genera cuando un proceso enumera los miembros de un grupo local con seguridad habilitada. Ambos son ruido habitual de herramientas de administración, y también el tipo de evento que aparece cuando alguien está reconociendo cuentas y grupos tras comprometer un equipo, de ahí que el propio Bousseaden lo haya clasificado bajo Discovery.

Higiene del laboratorio

Tres reglas que conviene aplicar desde el primer día, no cuando algo ya se ha roto:

• Las tres VMs deben vivir en una red interna o «solo anfitrión» de tu hipervisor, sin salida directa a tu red doméstica ni, mucho menos, a Internet salvo para descargar paquetes durante la instalación. Un laboratorio con malware de práctica (en módulos futuros) conectado a la misma red que tu portátil de trabajo es el tipo de error que solo se comete una vez.
• Saca una instantánea de las tres VMs justo después de tenerlas instaladas y enroladas, y otra antes de cada ejercicio que module la configuración (activar auditoría, instalar Sysmon, ejecutar una prueba atómica). Si algo deja el sistema en un estado raro, vuelves atrás en segundos en lugar de reinstalar.
• No reutilices contraseñas ni claves reales dentro de estas VMs: usa credenciales inventadas solo para el laboratorio, incluida la cuenta de administrador de Windows. Si alguna práctica futura te pide capturar o volcar credenciales, mejor que no sean las tuyas.
• Los datasets de este módulo son grabaciones; en módulos posteriores vas a generar tráfico y comandos ofensivos ligeros con herramientas como Atomic Red Team, y todo eso se ejecuta exclusivamente dentro de las VMs aisladas de tu laboratorio. Ejecutar cualquiera de estas técnicas contra una red, un dominio o un servicio que no te pertenece, con autorización o sin ella, no tiene relación con lo que enseña este curso. Si tu interés real es la respuesta ante un incidente ya ocurrido, con preservación de evidencia incluida, esa parte la cubre el curso de DFIR, no este módulo.

Cómo se usará este laboratorio en el resto del curso

A partir de aquí, cada módulo reutiliza estas tres máquinas. El siguiente activa la telemetría real en el generador Windows y en el endpoint Linux (auditoría avanzada, Sysmon, journald) para que dejen de depender de datasets grabados y empiecen a producir sus propios eventos. Con esa telemetría corriendo, los módulos posteriores recorren el mismo camino que has empezado hoy con el .evtx de muestra, pero de principio a fin y con una técnica elegida por ti: decidir qué campo hay que capturar, escribir la primera regla Sigma documentada (con su descripción, su nivel y su referencia a la técnica ATT&CK que cubre), validarla contra una prueba atómica de Atomic Red Team ejecutada en la propia VM Windows, y medir qué parte de la matriz de ATT&CK queda realmente cubierta y qué parte sigue siendo un hueco. Los últimos módulos dan el paso de convertir esa regla en algo desplegable por CI/CD, en lugar de un fichero XML suelto en el manager.

El host de Wazuh que acabas de levantar es el que recibe, indexa y evalúa todo eso durante el resto del curso. La comparación de plataformas de la primera parte de este módulo no cambia por eso: si terminas prefiriendo Security Onion o una pila de Elastic propia para tu SOC casero una vez acabado el curso, el trabajo de escribir y validar reglas que vas a aprender aquí se traslada a esas plataformas sin apenas fricción, porque Sigma como formato de reglas no está atado a ningún motor concreto.

Ejercicio de laboratorio

Con las tres VMs instaladas según este módulo:

1. Descarga discovery_local_user_or_group_windows_security_4799_4798.evtx desde la carpeta Discovery de EVTX-ATTACK-SAMPLES y cópialo a tu VM Windows.
2. Antes de tocar Wazuh, ábrelo con el Visor de eventos de Windows (eventvwr.msc, Acción > Abrir registro guardado) o con wevtutil gli y anota cuántos eventos contiene y de qué IDs.
3. Expórtalo a texto con wevtutil qe, configura el <localfile> del agente para vigilar esa exportación, y escribe un decodificador mínimo en local_decoder.xml que reconozca al menos la línea del Event ID.
4. Valida el decodificador con wazuh-logtest antes de reiniciar nada.
5. Activa logall_json en el manager y reinicia los servicios necesarios (wazuh-manager en el host del SIEM; el agente en la VM Windows).
6. Crea el patrón de índice wazuh-archives-* en el panel y localiza, en Discover, los eventos correspondientes a ese fichero.
7. Compara el número de eventos que ves en el panel con el que anotaste en el paso 2. Si coincide, la ingesta ha funcionado; si no, revisa el decodificador con wazuh-logtest antes de seguir.

No hay una salida «correcta» que puedas copiar: el resultado depende de tu propio decodificador y de tu propia exportación. Eso es intencional; es la primera vez en el curso en que tienes que verificar tú mismo, con tus propios datos, que una tubería de ingesta funciona de principio a fin, algo que en un puesto real de analista de SOC harás constantemente cada vez que llegue una fuente de datos nueva.

Preguntas frecuentes

¿Necesito comprar un dominio o alquilar un VPS para seguir este curso?

No. Las tres máquinas viven como VMs locales en tu propio equipo, sin salida a Internet salvo para instalar paquetes. Ni este módulo ni los siguientes requieren un dominio DNS público, un certificado real ni un proveedor de nube.

¿Por qué instalar Wazuh y no Security Onion, si Security Onion importa .evtx de forma nativa?

Porque el resto del curso trabaja con reglas de detección propias, decodificadores personalizados y validación con pruebas atómicas, y ese flujo de trabajo (escribir, decodificar, probar, medir cobertura) se enseña mejor sobre un motor de reglas abierto y ligero como el de Wazuh. Security Onion sigue siendo una opción muy razonable si tu prioridad es la visión de red o la importación cómoda de evidencia; nada te impide instalar ambos en paralelo si tienes RAM de sobra.

¿Puedo usar Splunk Free en lugar de Wazuh para todo el curso?

Con un único generador de telemetría y volúmenes bajos, probablemente sí, mientras te mantengas por debajo de los 500 MB diarios. En cuanto añadas un segundo agente que reenvíe datos por red, la licencia Free lo bloquea: el reenvío por TCP y HTTP está deshabilitado. Para un laboratorio de tres máquinas conectadas entre sí, Wazuh o Security Onion encajan mejor.

¿Necesito instalar Sysmon ya, en este módulo?

No. Este módulo se queda en el registro de seguridad estándar de Windows, que ya trae bastante señal (como los eventos 4798/4799 del ejercicio). La activación de auditoría avanzada y la instalación de Sysmon llegan en el siguiente módulo, cuando tu generador de telemetría empiece a producir sus propios eventos en lugar de depender de datasets grabados.

¿Es legal usar EVTX-ATTACK-SAMPLES, Security-Datasets o BOTSv3?

Sí, los tres se distribuyen con licencias abiertas que permiten su reutilización: EVTX-ATTACK-SAMPLES bajo GPL-3.0, Security-Datasets bajo MIT y BOTSv3 bajo CC0-1.0 (dominio público). Lo que no cambia es el ámbito de uso: son grabaciones para estudiar detección, no licencia para probar herramientas ofensivas contra sistemas de terceros.

Mi portátil no tiene 200 GB libres para el escalón más alto de la tabla de Wazuh. ¿Puedo seguir el curso?

Sí. Con dos agentes de laboratorio te quedas en el primer escalón de la tabla oficial (1-25 agentes): 4 vCPU, 8 GiB de RAM y 50 GB de disco para 90 días de alertas. Si reduces también la retención de índices o borras instantáneas antiguas que ya no necesites, 50-60 GB libres son suficientes para todo este módulo y los siguientes.