- Sysmon permite una visibilidad profunda de la actividad del sistema mediante el registro de procesos, conexiones de red y cambios en el registro.
- Su despliegue puede centralizarse mediante GPO y la recopilación de eventos de Windows (WEC) para monitorizar múltiples clientes desde un servidor.
- La eficacia de la herramienta depende críticamente de un archivo de configuración XML que filtre el ruido y resalte eventos de alta fidelidad.
Si alguna vez te has preguntado qué demonios estaba pasando en tu servidor a las tres de la mañana cuando saltó una alerta de CPU, sabrás que los registros estándar de Windows se quedan cortísimos. Aquí es donde entra en juego System Monitor (Sysmon), una joya de la suite Sysinternals que actúa como un ojo que todo lo ve, registrando detalles que normalmente pasarían desapercibidos, como la línea de comandos exacta de un proceso o los hashes de los archivos ejecutados.
No nos engañemos: Sysmon no es un antivirus ni un sistema de prevención que bloquee ataques por sí solo. Su fuerte es la telemetría de seguridad detallada, proporcionando la materia prima necesaria para que un analista o un SIEM puedan reconstruir el rompecabezas de una intrusión. Básicamente, se instala como un servicio y un controlador que sobreviven a los reinicios, escribiendo todo el movimiento sospechoso en el visor de eventos de Windows.
Capacidades principales de Sysmon
Esta herramienta no se anda con chiquitas y monitoriza una cantidad ingente de actividades. Entre sus funciones más destacadas, podemos encontrar el registro de la creación de procesos, incluyendo la línea de comandos completa y los hashes (SHA1, MD5, SHA256 o IMPHASH), lo que permite identificar malware aunque cambie el nombre del archivo. Además, introduce un GUID de proceso y de sesión, evitando que nos liemos cuando Windows reutiliza los IDs de proceso.
También es capaz de detectar cuando un atacante intenta jugar con las fechas de creación de los archivos (técnica de timestomping) para ocultar sus huellas. Si lo configuramos, podemos vigilar la carga de controladores y DLLs, el acceso bruto a discos y volúmenes, y por supuesto, todas las conexiones de red, detallando el proceso de origen, las IPs y los puertos involucrados.
Comandos esenciales para la gestión
Para manejar Sysmon no necesitamos una interfaz gráfica compleja, todo se hace mediante la consola. Para ponerlo en marcha, el comando sysmon64 -i es el punto de partida, pudiendo añadir un archivo de configuración XML para no empezar desde cero. Si queremos actualizar las reglas sin reinstalar todo, usamos sysmon64 -c, mientras que para limpiar el sistema y borrar el servicio recurrimos a sysmon64 -u.
Un detalle importante es el uso del parámetro -accepteula, que nos ahorra tener que aceptar los términos de licencia de forma interactiva, algo fundamental si estamos desplegando la herramienta de forma automatizada en decenas de servidores.
Despliegue avanzado: Recolección centralizada en Windows Server
Montar Sysmon en un solo equipo está bien, pero en un entorno empresarial lo ideal es centralizarlo todo. Para convertir un Windows Server en un recolector de eventos (WEC), primero debemos ejecutar el comando wecutil.exe qc /q y abrir el puerto 5985 en el cortafuegos para permitir el tráfico de WinRM.
Para que el servidor acepte los eventos de los clientes, es necesario crear una suscripción de eventos mediante un archivo XML. Este archivo define qué eventos queremos recibir y cómo. Una vez configurado, podemos publicar el archivo de configuración de Sysmon (como el famoso set de SwiftOnSecurity) en la carpeta NETLOGON del controlador de dominio, asegurando que todos los equipos de la red tengan acceso a las mismas reglas de filtrado.
Automatización mediante Directivas de Grupo (GPO)
Para no ir máquina por máquina, lo más inteligente es usar una GPO. En la sección de Reenvío de Eventos, configuramos la dirección del servidor recolector. Asimismo, es vital ajustar la auditoría avanzada de Windows para forzar la configuración de subcategorías y monitorizar los inicios y cierres de sesión, así como la administración de cuentas de usuario.
En los equipos clientes, debemos asegurarnos de que el servicio WinRM esté en automático y que la cuenta NETWORK SERVICE tenga permisos de lectura en el registro de eventos de seguridad, de lo contrario, los datos jamás llegarán al servidor central.
Entendiendo los IDs de Eventos y su utilidad
Sysmon genera una cantidad enorme de datos, por lo que conocer los IDs es fundamental para no volverse loco. El ID 1 (Creación de Proceso) es el rey, ya que nos dice quién ejecutó qué y cómo. El ID 3 es crucial para detectar comunicaciones con servidores de comando y control (C2) al registrar las conexiones de red, mientras que el ID 11 nos avisa cuando se crean archivos en carpetas críticas como las de inicio automático.
Para los más detallistas, el ID 8 (CreateRemoteThread) y el ID 10 (ProcessAccess) son oro puro, ya que detectan técnicas de inyección de código y el robo de credenciales desde procesos como lsass.exe. Por otro lado, el ID 22 nos permite rastrear consultas DNS sospechosas, revelando si un equipo está intentando contactar con dominios maliciosos.
El arte de la configuración XML
Si dejamos Sysmon con la configuración por defecto, el visor de eventos se llenará de ruido inútil. La clave está en el archivo XML, donde podemos definir reglas de inclusión (include) y exclusión (exclude). Por ejemplo, podemos decirle que registre todas las conexiones de red, pero que ignore las que provengan del navegador web para evitar miles de eventos irrelevantes.
El filtrado puede ser muy preciso utilizando condiciones como contains, begins with o ends with. Podemos agrupar reglas mediante etiquetas de RuleGroup para aplicar una lógica AND u OR, permitiéndonos capturar eventos solo cuando se cumplan varias condiciones simultáneamente, como un proceso específico ejecutado con un argumento concreto.
Casos de uso reales en seguridad
Imagina que un usuario lanza un comando de PowerShell codificado en Base64 para ocultar sus intenciones; Sysmon lo pillará mediante el ID 1, mostrándonos el comando real. O piensa en un malware que intenta ganar persistencia creando una clave en el registro de Windows; esto saltará inmediatamente como un evento ID 13.
Incluso podemos detectar cuando alguien intenta crear un usuario nuevo en el dominio (ID 4720) o cuando hay fallos repetidos de inicio de sesión (ID 4625), lo que podría indicar un ataque de fuerza bruta. Esta visibilidad transforma la seguridad de una postura reactiva a una capacidad de análisis forense real y detallada.
La implementación de esta herramienta, especialmente cuando se integra en un SIEM, permite transformar datos crudos en inteligencia accionable. Al combinar la instalación nativa o independiente con configuraciones comunitarias optimizadas y un sistema de reenvío de eventos bien estructurado, cualquier administrador de sistemas puede elevar drásticamente la capacidad de detección de amenazas en su infraestructura de Windows Server.