Sysmon:
telemetría avanzada en Windows para detectar amenazas
Serie Blue Team | unfantasmaenelsistema.com
El registro de eventos nativo de Windows es útil, pero fue diseñado para diagnosticar el sistema, no para cazar intrusos. Cuando un atacante lanza un proceso, inyecta código en otro o abre una conexión hacia su servidor de mando, el log estándar deja huellas parciales, dispersas y a menudo apagadas por defecto. Ese es exactamente el hueco que rellena Sysmon.
Sysmon (System Monitor) es una herramienta gratuita de Microsoft, parte de la suite Sysinternals, que se instala como servicio y controlador y registra actividad del sistema con un nivel de detalle pensado para la detección. Es, hoy, una de las fuentes de telemetría más valiosas —y más baratas— que puede tener un SOC. En este artículo vemos qué aporta, cómo se despliega, qué eventos importan de verdad y cómo se traducen en detecciones concretas mapeadas a MITRE ATT&CK.
Qué aprenderás en este artículo
Qué registra Sysmon que el log nativo de Windows no cubre bien · Cómo instalarlo, configurarlo y mantenerlo actualizado · Los Event ID clave (1, 3, 7, 8, 11, 12/13, 22) y qué actividad revelan · Por qué la configuración lo es todo, y qué plantillas usar (SwiftOnSecurity, Olaf Hartong) · Cómo enviar la telemetría a un SIEM y ejemplos de detección mapeados a ATT&CK
1. Por qué el log nativo no basta
Windows puede auditar creación de procesos (Event ID 4688) y otras acciones, pero con limitaciones importantes: hay que activarlo por directiva, no registra el hash del ejecutable, no incluye de forma fiable la línea de comandos completa sin ajustes adicionales, y no cubre en absoluto ciertas técnicas —inyección de hilos remotos, carga de DLL, consultas DNS por proceso— que son la base de muchos ataques modernos.
Sysmon añade una capa de instrumentación específica para seguridad. Cada evento que genera va con contexto rico: proceso padre, línea de comandos, usuario, hashes múltiples, GUID de proceso que permite correlacionar toda la cadena, e integridad de la firma digital. Y, sobre todo, sus eventos sobreviven a un reinicio y son difíciles de desactivar sin privilegios elevados y sin dejar rastro.
Sysmon no es un antivirus
Sysmon no bloquea nada: solo observa y registra · Su valor aparece cuando esa telemetría se envía a un SIEM o EDR y se le aplican reglas de detección · Sin recogida centralizada y sin reglas, Sysmon es solo un log más en cada equipo
2. Instalación y configuración
Sysmon se descarga de la web oficial de Sysinternals (live.sysinternals.com o learn.microsoft.com/sysinternals). Se instala desde una consola con privilegios de administrador, casi siempre apuntando a un fichero de configuración XML.
REM Instalacion inicial con un fichero de configuracion sysmon64.exe -accepteula -i sysmonconfig.xml REM Actualizar la configuracion sin reinstalar el servicio sysmon64.exe -c sysmonconfig.xml REM Ver la configuracion activa sysmon64.exe -c REM Desinstalar sysmon64.exe -u
Los eventos aparecen en el Visor de eventos, en Registros de aplicaciones y servicios > Microsoft > Windows > Sysmon > Operational. En un despliegue real no se miran ahí: se reenvían a un colector (Windows Event Forwarding, Winlogbeat, el agente del SIEM, etc.).
2.1 La configuración lo es todo
Sysmon sin fichero de configuración registra muy poco y con criterios pobres. Con una configuración demasiado abierta genera un volumen de eventos que ahoga el SIEM y dispara los costes de almacenamiento. El equilibrio se consigue con plantillas mantenidas por la comunidad, que se toman como punto de partida y se ajustan al entorno:
- SwiftOnSecurity/sysmon-config: la plantilla clásica, muy comentada, excelente para aprender qué hace cada regla. Filosofía de lista de exclusión (registra casi todo menos ruido conocido)
- Olaf Hartong/sysmon-modular: configuración modular por técnica de ATT&CK; permites o silencias módulos concretos y generas el XML final. Es el estándar de facto en despliegues grandes
- Ambas se actualizan con frecuencia: conviene revisar cambios cada pocos meses y versionar tu propio XML en un repositorio
Ajusta antes de desplegar en toda la flota
Prueba la configuración en un grupo piloto y mide el volumen de eventos por equipo y día · Excluye ruido legítimo de tu entorno (software de backup, agentes de gestión, EDR) pero documenta cada exclusión: un atacante que conozca tu config intentará esconderse justo en esas rutas · Mantén Sysmon y la configuración actualizados: cada versión añade cobertura de nuevas técnicas
3. Los Event ID que de verdad importan
Sysmon define más de 25 tipos de evento. Estos son los que aparecen una y otra vez en detecciones reales:
| Event ID | Evento | Qué revela |
|---|---|---|
| 1 | Process Create | Ejecución de procesos con línea de comandos, padre, hashes y firma. La base de casi todo |
| 3 | Network Connection | Conexión de red asociada a un proceso concreto: IP, puerto y ejecutable de origen |
| 7 | Image Loaded | Carga de DLL en un proceso: detecta DLL sin firmar o desde rutas anómalas (sideloading) |
| 8 | CreateRemoteThread | Un proceso crea un hilo en otro: firma clásica de inyección de código |
| 10 | Process Access | Un proceso abre un handle a otro con permisos amplios: típico de volcado de credenciales contra LSASS |
| 11 | File Create | Creación de ficheros: droppers, webshells, herramientas escritas en disco, tareas en carpetas de inicio |
| 12/13/14 | Registry | Creación/modificación de claves y valores del registro: persistencia y cambios de configuración |
| 15 | FileCreateStreamHash | Ficheros con flujo de datos alternativo (ADS) y su marca de zona (descargados de internet) |
| 17/18 | Pipe Created / Connected | Named pipes: canal habitual de comunicación de balizas de C2 y de movimiento lateral |
| 22 | DNS Query | Consultas DNS por proceso: dominios de C2, algoritmos de generación de dominios (DGA), exfiltración por DNS |
| 23 | File Delete | Borrado de ficheros con posibilidad de archivarlos: antiforense y limpieza de herramientas |
| 25 | Process Tampering | Manipulación de imagen en memoria: process hollowing y herding |
3.1 El GUID de proceso: el pegamento
Cada evento de Sysmon incluye un ProcessGuid único. A diferencia del PID, que Windows reutiliza, el GUID identifica de forma inequívoca una ejecución concreta. Eso permite reconstruir un árbol completo: qué proceso lanzó qué, qué conexión abrió cada uno, qué DLL cargó y qué escribió en disco. En una investigación, seguir el GUID es lo que convierte eventos sueltos en una historia.
4. De eventos a detecciones: ejemplos mapeados a ATT&CK
La telemetría solo sirve si se le aplican reglas. Estos son patrones de detección habituales que se construyen sobre eventos de Sysmon. Las expresiones son ilustrativas, no sintaxis de un SIEM concreto.
| Técnica (ATT&CK) | Evento base | Señal que se busca |
|---|---|---|
| T1059.001 — PowerShell | 1 | powershell.exe con -enc, -nop, -w hidden, IEX, DownloadString en la línea de comandos |
| T1055 — Process Injection | 8, 25 | CreateRemoteThread hacia procesos que normalmente no lo reciben; manipulación de imagen en memoria |
| T1003.001 — LSASS Memory | 10 | Process Access a lsass.exe con GrantedAccess 0x1010 / 0x1410 desde un proceso no habitual |
| T1547.001 — Run Keys | 13 | Escritura en …\CurrentVersion\Run o Winlogon\Shell por un proceso de usuario |
| T1053.005 — Scheduled Task | 1, 11 | schtasks.exe /create o ficheros nuevos en C:\Windows\System32\Tasks |
| T1574.002 — DLL Side-Loading | 7 | Carga de DLL sin firmar desde la carpeta de la aplicación en lugar de System32 |
| T1071.004 — DNS C2 | 22 | Volumen alto de consultas a subdominios de un mismo dominio, o dominios con entropía elevada (DGA) |
| T1218 — LOLBins | 1 | rundll32.exe, regsvr32.exe, mshta.exe con argumentos de red o rutas de scripts remotos |
| T1070.004 — File Deletion | 23 | Borrado masivo de logs o de herramientas desde rutas temporales tras actividad sospechosa |
Empieza por lo que da más señal con menos ruido
Event ID 1 con líneas de comando sospechosas y relaciones padre-hijo anómalas (Office lanzando PowerShell, w3wp.exe lanzando cmd.exe) es donde más ataques se detectan con menos falsos positivos · Event ID 10 contra LSASS y Event ID 22 con dominios raros son dos reglas de alto valor y bajo coste · CreateRemoteThread (8) es potente pero ruidoso: necesita afinado por entorno
5. Enviar la telemetría a un SIEM
Sysmon genera los eventos en local; hace falta un mecanismo de recogida. Las opciones habituales:
- Windows Event Forwarding (WEF): nativo, sin agente, reenvía a un colector Windows por WinRM. Económico y suficiente para muchos entornos, aunque menos flexible en el parseo
- Winlogbeat / Elastic Agent: envía a Elasticsearch/OpenSearch; incluye módulos que ya normalizan los campos de Sysmon al Elastic Common Schema
- Agente del SIEM (Splunk Universal Forwarder, Wazuh, agente de Sentinel/AMA, etc.): la vía más común en SOC comerciales, con parsing y campos ya mapeados
Vigila el volumen y la retención
Sysmon bien configurado puede generar de decenas a cientos de MB por equipo y día según el rol · Calcula el coste de ingesta y almacenamiento antes de desplegar a miles de endpoints · Prioriza retención larga para Event ID 1, 3, 11, 13 y 22; el resto puede tener retención más corta
5.1 Protege la propia telemetría
Un atacante con privilegios intentará cegar Sysmon: detener el servicio, descargar el controlador o modificar la configuración. Contramedidas: reenviar los eventos en tiempo casi real (para que lo capturado antes del sabotaje ya esté fuera del equipo), alertar sobre el Event ID 4 de Sysmon (cambio de estado del servicio) y sobre paradas de servicio, restringir por directiva quién puede gestionar servicios, y monitorizar cambios en las claves de registro del propio Sysmon.
6. Buenas prácticas de despliegue
- Versiona tu XML de configuración en un repositorio y despliega los cambios de forma controlada (GPO, Intune, herramienta de gestión)
- Revisa las plantillas de la comunidad cada 2-3 meses e incorpora la cobertura nueva
- Documenta cada exclusión con su motivo y su fecha; audítalas periódicamente
- Mide el ratio señal/ruido de cada regla y retira o afina las que solo generan falsos positivos
- Combina Sysmon con el log nativo (4688 con línea de comandos, 4624/4625 de autenticación, 4720 de creación de cuentas): Sysmon complementa, no sustituye
- Prueba tus detecciones con un framework de emulación (Atomic Red Team) en un entorno de laboratorio aislado antes de confiar en ellas
Uso responsable de la telemetría de endpoint
Despliega Sysmon solo en sistemas de tu organización o de tu laboratorio, con la cobertura legal y la política interna correspondientes · La monitorización de actividad de los empleados está sujeta a normativa laboral y de protección de datos: informa según exija tu jurisdicción y limita la recogida a fines de seguridad · Las pruebas de emulación de adversario (Atomic Red Team, Caldera) deben hacerse en máquinas aisladas y nunca contra sistemas de terceros
Referencias
learn.microsoft.com/sysinternals/downloads/sysmon — Documentación oficial y descarga · github.com/SwiftOnSecurity/sysmon-config — Plantilla comentada para empezar · github.com/olafhartong/sysmon-modular — Configuración modular por técnica de ATT&CK · attack.mitre.org — Matriz de técnicas para mapear detecciones · github.com/redcanaryco/atomic-red-team — Pruebas de detección en laboratorio
Conclusión
Sysmon es la forma más accesible de dar a un equipo de defensa la visibilidad que el log nativo de Windows no ofrece: ejecución de procesos con contexto completo, conexiones de red por proceso, inyección de código, persistencia en el registro y consultas DNS, todo correlacionable por el GUID de proceso.
Pero la herramienta es solo el sensor. El valor real está en tres cosas que dependen de ti: una configuración ajustada a tu entorno, una recogida centralizada fiable, y un catálogo de detecciones mapeado a ATT&CK y probado en laboratorio. Con esas tres piezas, Sysmon convierte cada endpoint en una fuente de telemetría que cuenta la historia completa de lo que pasó.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)