Estimados amigos de Inseguros !!!
Seguimos con la serie sobre Wazuh, y hoy vamos a tocar una funcionalidad que no suele ser de las más famosas, pero que tiene bastante miga cuando entiendes para qué sirve: el Command Monitoring. Si quieres aprender más en serio, pégale un vistazo al curso de Wazuh.
Dicho de forma simple, se trata de ejecutar comandos en un sistema, recoger su salida y tratar ese resultado como si fuera una fuente de logs más dentro de Wazuh. Es decir, no estamos esperando únicamente a que el sistema operativo o una aplicación nos deje eventos preparados. También podemos decirle a Wazuh: ejecuta esto cada cierto tiempo, mira lo que devuelve y analiza ese contenido.
Porque en seguridad muchas veces pensamos en monitorización como algo pasivo. Logs que llegan, alertas que saltan, reglas que comparan eventos y listo. Pero hay casos en los que a ti te interesa saber cómo cambia el estado del sistema aunque nadie te esté generando un evento bonito para consumir. Ahí es donde esta idea gana bastante valor.
En la lección se pone un ejemplo muy claro: supervisar el resultado de ciertos comandos para detectar cambios. Por ejemplo, comandos que muestren listeners de red, rutas, conexiones o procesos en ejecución. Si cambia la salida, puede significar que ha aparecido un nuevo servicio escuchando, una nueva ruta, una VPN inesperada o un proceso que no debería estar ahí.
Eso, llevado al mundo real, da bastante juego.
Porque no siempre vas a tener una regla perfecta preparada para decirte “ha aparecido esto raro”. A veces lo útil es preguntar periódicamente al sistema cómo está y comparar. Y si algo cambia donde no debería, entonces sí levantar una alerta.
En el caso práctico del curso se usa un ejemplo muy sencillo pero muy didáctico: monitorizar procesos en ejecución en un Windows mediante tasklist. La salida de ese comando se captura y se trata como contenido de logs, y luego se crean reglas para detectar si un proceso concreto aparece en ejecución. En el ejemplo elegido, ese proceso es notepad.exe, pero evidentemente la idea no va de vigilar el bloc de notas. Va de entender el mecanismo para luego aplicarlo a procesos que sí tengan interés real.
Y esto es justo lo importante.
No se trata de memorizar que alguien ha vigilado notepad.exe. Se trata de entender que puedes usar este método para detectar procesos inesperados, herramientas que no deberían ejecutarse, binarios concretos, utilidades administrativas fuera de contexto o cualquier otra cosa que te interese seguir.
La forma de montarlo también es bastante ilustrativa. Primero se crea un script .bat en Windows que ejecuta tasklist y añade una cabecera al principio del resultado. Esa cabecera sirve para que Wazuh sepa interpretar bien la salida y pueda procesarla correctamente más adelante. Es una idea sencilla, pero útil: si vas a convertir la salida de un comando en pseudo-logs, conviene darles una estructura reconocible.
Después, en el agente, se configura la ejecución periódica de ese script desde ossec.conf, en este caso a través de PowerShell y con un intervalo de dos minutos. Es decir, el agente va lanzando el comando, capturando el resultado y enviándolo para su tratamiento. A continuación, en el servidor de Wazuh se prepara la parte que interpreta esa salida, ajustando el decoder para leer el contenido a partir del prefijo definido en el script. Y finalmente se añade una regla que busca la aparición del proceso deseado dentro de ese output.
Traducido al castellano de trinchera: generas tu propia telemetría, le enseñas a Wazuh cómo leerla y luego construyes detección encima.
A mí esta parte me gusta especialmente porque obliga a pensar un poco mejor.
No solo en “qué logs tengo”, sino en “qué información me gustaría tener”. Y esa diferencia es bastante grande. Porque cuando trabajas monitorización de forma seria, muchas veces el problema no es solo interpretar eventos existentes. Es decidir qué estado del sistema quieres observar para enterarte antes de que algo vaya mal.
En el ejemplo, cuando notepad.exe aparece en ejecución, Wazuh genera la alerta correspondiente y la muestra en el dashboard con la descripción configurada, la severidad y el agente donde se ha detectado. Es un caso muy simple, sí, pero suficiente para enseñar el patrón completo: comando, salida, decoder, regla y alerta.
Y a partir de ahí ya puedes imaginar bastantes usos mejores que el ejemplo de laboratorio.
Procesos que no deberían existir en servidores concretos. Herramientas administrativas lanzadas fuera de ventana de mantenimiento. Binarios sospechosos. Aparición de determinados hijos de proceso. Cambios en rutas o conexiones. Incluso pequeñas comprobaciones orientadas a threat hunting o a validaciones de hardening.
Además, esto tiene otra lectura interesante: te enseña que Wazuh no es solo un sitio donde mirar alertas, sino una plataforma a la que puedes alimentar con lógica propia. Y eso es precisamente lo que marca la diferencia entre usar una herramienta y exprimirla.
Porque aprender este tipo de cosas no va solo de instalar un agente y abrir un dashboard. Va de entender cómo sacar visibilidad útil, cómo construir detección y cómo adaptar la monitorización a lo que realmente te importa en un sistema.
Seguiremos con más posts de la serie, porque Wazuh tiene bastantes piezas que, vistas por separado, parecen pequeñas, pero juntas ayudan mucho a entender cómo se trabaja de verdad en monitorización, análisis y operación de seguridad.
Gracias por leerme !!!
