El Visor de sucesos de Windows, con la auditoría de seguridad activada a conciencia, cuenta quién inició sesión y cuándo cambió una política. Lo que no cuenta, salvo que hayas activado la creación de procesos con línea de comandos completa, es qué proceso lanzó a qué proceso, con qué argumentos, a qué IP se conectó después o qué clave de registro tocó al arrancar. Reconstruir una intrusión con esa información se parece más a adivinar que a investigar.
Sysmon lleva más de una década tapando ese hueco de forma gratuita, y sigue siendo el punto de partida casi obligatorio antes de plantearse un EDR de pago. Pero instalarlo con la configuración por defecto sirve de poco: hay que decidir qué tipos de evento activar, con qué filtros, y eso tiene una sintaxis propia con más de una trampa. Aquí se entra en esa sintaxis, en las dos configuraciones públicas que casi todo el mundo usa como punto de partida (las de SwiftOnSecurity y de Olaf Hartong) y en cómo medir el volumen que genera cada tipo de evento antes de mandarlo a producción.
Qué aprenderás
- Qué información añade Sysmon sobre el registro de eventos nativo de Windows, y de dónde se descarga, instala y actualiza
- Los tipos de evento de Sysmon, del 1 al 29, y qué campo de cada uno resulta útil para escribir una regla
- La sintaxis completa del fichero de configuración: schemaversion, EventFiltering, RuleGroup, groupRelation y las condiciones de filtrado disponibles
- Por qué la lógica de include/exclude y de AND/OR confunde a casi todo el mundo la primera vez, y cómo razonarla sin errores
- Cómo evaluar una configuración de referencia pública antes de adoptarla, en vez de copiarla sin mirarla
- Qué tipos de evento generan más volumen y cómo medirlo en tu propio laboratorio antes de desplegar
- Cómo se recoge el canal de Sysmon y se envía a un SIEM mediante Windows Event Forwarding
- Qué parte de la telemetría de endpoint solo cubre un EDR, y por qué eso no invalida usar Sysmon igualmente
Qué añade Sysmon sobre el registro nativo
Sysmon (System Monitor) es un servicio de Windows con un driver en modo kernel que se instala una vez y queda residente entre reinicios, escribiendo actividad del sistema en su propio canal del Visor de sucesos. Según la documentación oficial de Sysinternals, entre sus capacidades está registrar la creación de procesos con la línea de comandos completa (de ese proceso y de su padre), calcular el hash de los binarios que se ejecutan, incluir un ProcessGuid que sobrevive a la reutilización de PIDs por parte de Windows, registrar la carga de drivers y DLLs con su firma, detectar lecturas en crudo de disco, registrar conexiones de red con proceso, IP y puerto de origen y destino, y detectar cuándo se manipula la fecha de creación de un fichero (una técnica típica para hacer pasar un backdoor por un componente antiguo del sistema). El propio proyecto avisa de sus límites con una frase que conviene tener presente: Sysmon «no analiza los eventos que genera, ni intenta ocultarse de un atacante». Es una fuente de telemetría, no un motor de detección; el análisis pasa por un SIEM (si no tienes claro qué papel cumple esa pieza, hay una guía dedicada a qué es un SIEM).
Se descarga desde la página oficial de Sysinternals, en un único paquete comprimido que incluye los binarios de 32 y 64 bits. La última actualización anunciada en la página de novedades de Sysinternals, consultada en julio de 2026, es Sysmon v15.2, del 26 de marzo de 2026; la página de documentación del producto no publica el número de versión del binario, así que comprueba siempre cuál has descargado en lugar de fiarte de lo que diga un artículo (incluido este). El binario no exige versiones concretas del sistema operativo más allá de Windows 10 o Windows Server 2016 como mínimo. La instalación no pide reinicio ni en la instalación ni en la desinstalación, y el propio driver arranca en fase de arranque temprano (boot-start) para capturar actividad de malware sofisticado que se ejecute antes que el resto de servicios.
El ciclo de vida se maneja con un puñado de conmutadores de línea de comandos. Para instalar con una configuración concreta, aplicar un cambio de configuración a un Sysmon ya instalado, volcar la configuración activa o desinstalar:
sysmon64 -accepteula -i miconfig.xml
sysmon64 -c miconfig.xml
sysmon64 -c
sysmon64 -uActualizar de versión es tan sencillo como desinstalar el binario antiguo e instalar el nuevo apuntando a la misma configuración: el fichero XML no depende de la versión del binario, sino de un número de esquema independiente (schemaversion) que se explica en la siguiente sección. Sysmon también relee su configuración sola si detecta que el valor correspondiente cambió en el registro, sin necesidad de reiniciar el servicio. Cada cambio de configuración, se haga con -c o modificando el registro directamente, genera un evento de ID 16 (salvo que se manipule el valor binario del registro a mano, en cuyo caso no queda constancia por esa vía).
Existe también Sysmon para Linux, publicado bajo licencia MIT (con los componentes eBPF bajo GPL2 y las dependencias de SysinternalsEBPF bajo LGPL2.1), que reproduce buena parte de la misma filosofía de configuración por XML sobre auditd/eBPF. No es el objeto de este módulo, pero conviene saber que existe si tu SOC cubre servidores Linux, no solo endpoints Windows.
Los tipos de evento, uno por uno
Sysmon define 29 tipos de evento numerados, más un evento 255 de error interno del propio servicio. No todos pesan igual en un caso de detección: algunos son casi de uso obligado (creación de procesos, conexiones de red) y otros son de aplicación muy concreta (acceso al portapapeles, herramientas de shredding de ficheros). La tabla siguiente recoge los 29, con el nombre de la etiqueta que se usa para filtrarlos en la configuración y para qué suele mirarse cada uno en un flujo de trabajo de detección. Los IDs 4 y 16 no se pueden filtrar: son eventos de estado del propio servicio Sysmon, no de la actividad que vigila.
| ID | Etiqueta de configuración | Para qué se usa en detección |
|---|---|---|
| 1 | ProcessCreate | La columna vertebral de casi cualquier regla: línea de comandos completa, proceso padre, hash del binario. Es donde se busca ejecución de LOLBins, PowerShell ofuscado o binarios firmados fuera de su ruta habitual. |
| 2 | FileCreateTime | Cambios explícitos en la fecha de creación de un fichero. Útil para pillar malware que intenta parecer más antiguo de lo que es, aunque procesos legítimos también tocan esta marca con frecuencia. |
| 3 | NetworkConnect | Conexiones TCP/UDP salientes con proceso, IP y puerto. Desactivado por defecto por volumen. Se cruza con listas de IOC o con puertos poco habituales para un proceso dado. |
| 4 | (sin filtro) | Arranque o parada del propio servicio Sysmon. Sirve para detectar huecos en la telemetría, no para investigar al atacante. |
| 5 | ProcessTerminate | Fin de un proceso. Combinado con el 1 permite acotar cuánto tiempo estuvo vivo un proceso concreto. |
| 6 | DriverLoad | Carga de un driver, con hash y estado de firma. Relevante para detectar drivers vulnerables usados para escalar privilegios o para BYOVD (bring your own vulnerable driver). |
| 7 | ImageLoad | Carga de una DLL en un proceso. Desactivado por defecto: la propia documentación de Sysinternals avisa de que activarlo sin filtrar «generará un volumen de registro significativo». |
| 8 | CreateRemoteThread | Un proceso crea un hilo dentro de otro proceso, la firma clásica de inyección de código (ATT&CK T1055, Process Injection). Incluye dirección, módulo y función de inicio del hilo cuando Sysmon logra inferirlos. |
| 9 | RawAccessRead | Lectura en crudo de un volumen o disco mediante la notación \., evitando los controles normales del sistema de ficheros. Habitual en exfiltración de ficheros bloqueados o en evasión de auditoría de acceso a ficheros. |
| 10 | ProcessAccess | Un proceso abre un handle sobre otro proceso. Es el evento que permite ver quién intenta leer la memoria de lsass.exe para robar credenciales (T1003.001). Genera mucho ruido si no se filtra, porque cualquier antivirus o herramienta de diagnóstico abre procesos constantemente. |
| 11 | FileCreate | Creación o sobrescritura de un fichero. Muy usado para vigilar carpetas de arranque, descargas y directorios temporales, los sitios habituales donde cae el malware en la infección inicial. |
| 12 | RegistryEvent (creación/borrado de clave o valor) | Junto con el 13 y el 14, cubre el registro. Útil para persistencia por claves Run (T1547.001) y para servicios nuevos. |
| 13 | RegistryEvent (asignación de valor) | Registra el valor escrito cuando es de tipo DWORD o QWORD. Complementa al 12 cuando lo que importa no es que se creara la clave, sino qué se escribió en ella. |
| 14 | RegistryEvent (renombrado de clave o valor) | Cambios de nombre en claves o valores del registro, una vía menos vigilada que la creación directa. |
| 15 | FileCreateStreamHash | Creación de un flujo alternativo (ADS) y hash del contenido, incluido el flujo Zone.Identifier que marca ficheros descargados del navegador. Sirve para rastrear el origen de un binario que llegó por descarga. |
| 16 | (sin filtro) | Cambios en la propia configuración de Sysmon, por ejemplo cuando se actualizan las reglas de filtrado. |
| 17 | PipeEvent (creación de pipe) | Creación de una tubería con nombre, un mecanismo de comunicación entre procesos que usa con frecuencia malware y frameworks de post-explotación. |
| 18 | PipeEvent (conexión de pipe) | Conexión efectiva entre cliente y servidor sobre una tubería con nombre ya creada. |
| 19 | WmiEvent (WmiEventFilter) | Registro de un filtro de eventos WMI, junto con el 20 y el 21 cubre la persistencia por suscripción WMI (T1546.003). |
| 20 | WmiEvent (WmiEventConsumer) | Registro del consumidor WMI que ejecutará algo cuando el filtro se dispare. |
| 21 | WmiEvent (WmiEventConsumerToFilter) | El enlace entre consumidor y filtro, el paso que completa la cadena de persistencia por WMI. |
| 22 | DnsQuery | Consultas DNS realizadas por un proceso, éxito o fallo, cacheadas o no. Disponible desde Windows 8.1 en adelante. Se usa para C2 sobre DNS (T1071.004), aunque el propio volumen de tráfico DNS legítimo lo convierte en uno de los eventos más ruidosos si no se filtra. |
| 23 | FileDelete (con archivado) | Un fichero se borra y, a la vez, se guarda una copia en el directorio de archivado (por defecto C:Sysmon). Permite recuperar después el binario que un atacante intentó eliminar, a costa de espacio en disco. |
| 24 | ClipboardChange | Cambios en el contenido del portapapeles del sistema. Aplicación bastante concreta, típicamente para investigar exfiltración manual o pegado de comandos maliciosos. |
| 25 | ProcessTampering | Detecta técnicas de manipulación del propio proceso, como el «hollowing» o el «herpaderping», donde el binario en disco no coincide con lo que corre en memoria (relacionado con T1055.012, Process Hollowing). |
| 26 | FileDeleteDetected | Igual que el 23 pero sin guardar copia del fichero borrado, pensado para no llenar el disco cuando solo interesa el registro del evento. |
| 27 | FileBlockExecutable | Sysmon detecta y bloquea la creación de un fichero ejecutable (formato PE). A diferencia de casi todo lo demás en esta tabla, este evento va ligado a una acción de bloqueo real, no solo de registro. |
| 28 | FileBlockShredding | Sysmon detecta y bloquea el borrado seguro (shredding) de ficheros hecho con herramientas como SDelete. También es un bloqueo activo, no solo telemetría. |
| 29 | FileExecutableDetected | Se genera cuando se crea un nuevo fichero ejecutable (PE), sin bloquear nada. Es la versión de solo registro del 27. |
Conviene marcar la excepción a la fama de «Sysmon solo audita»: los eventos 27 y 28 sí bloquean. Es una capacidad limitada y muy específica (creación de ejecutables y shredding de ficheros), no un motor de prevención general, pero merece la pena tenerla en cuenta al comparar Sysmon con un EDR.
La sintaxis del fichero de configuración
El esqueleto: schemaversion y EventFiltering
Un fichero de configuración de Sysmon es XML con la raíz Sysmon, un atributo schemaversion y, dentro, un bloque EventFiltering donde va todo lo que filtra eventos. El número de esquema es independiente de la versión del binario: existe justamente para que una configuración escrita hace tiempo se siga cargando en un Sysmon más nuevo. Se puede consultar el esquema vigente para el binario instalado con sysmon64 -s. En el ejemplo que trae hoy la propia documentación oficial de Sysinternals se usa schemaversion="4.82", y es el valor que se mantiene en los ejemplos de este módulo.
El esqueleto mínimo, sin ningún filtro todavía, es este:
<Sysmon schemaversion="4.82">
<EventFiltering>
</EventFiltering>
</Sysmon>Fuera de EventFiltering también se pueden declarar entradas de configuración general, como HashAlgorithms (qué algoritmos de hash aplicar a los binarios, con * para todos), CheckRevocation (comprobar revocación de certificados de firma) o ArchiveDirectory (dónde guarda Sysmon las copias de los ficheros borrados que captura el evento 23, C:Sysmon por defecto). No son filtros de eventos, son parámetros del servicio.
Un solo filtro, sin RuleGroup
El caso más simple es un único tipo de evento con onmatch="include", sin envolverlo en nada más. Esto activa el evento 1 y solo registra procesos cuyo nombre de imagen termine en powershell.exe:
<Sysmon schemaversion="4.82">
<EventFiltering>
<ProcessCreate onmatch="include">
<Image condition="end with">powershell.exe</Image>
</ProcessCreate>
</EventFiltering>
</Sysmon>Aquí está el primer punto donde la gente se lía: onmatch="include" no significa «incluye estas reglas en la evaluación». Significa «de todos los eventos de este tipo, registra solo los que coincidan con estas condiciones; descarta el resto». Si en vez de include se pone exclude, el sentido se invierte por completo: se registra todo lo de ese tipo de evento excepto lo que coincida. La confusión viene de leer «include/exclude» como si hablara de las reglas (¿incluyo esta condición en la lógica?) cuando en realidad habla de los eventos resultantes (¿qué eventos terminan en el log?).
Cuando hay más de una condición: OR por defecto entre valores del mismo campo
Dentro de un mismo filtro de evento, varias etiquetas que repiten el mismo nombre de campo se combinan con lógica OR. Este ejemplo excluye la carga de cualquier driver cuya firma contenga «Microsoft Windows» o «Intel» (dos condiciones sobre el mismo campo, Signature):
<Sysmon schemaversion="4.82">
<EventFiltering>
<RuleGroup name="" groupRelation="or">
<DriverLoad onmatch="exclude">
<Signature condition="contains">Microsoft Windows</Signature>
<Signature condition="contains">Intel</Signature>
</DriverLoad>
</RuleGroup>
</EventFiltering>
</Sysmon>Cuando los campos son distintos entre sí (por ejemplo Image y CommandLine en el mismo filtro), la combinación por defecto pasa a ser AND: hace falta que coincidan las dos condiciones, no solo una. Esa es la regla base, con o sin RuleGroup alrededor.
Dónde entra realmente groupRelation
El atributo groupRelation de RuleGroup sirve para forzar una combinación distinta de la que sale por defecto. Y aquí está la segunda trampa habitual: como el AND entre campos distintos ya es el comportamiento por defecto, escribir groupRelation="and" sobre un filtro que solo mezcla campos distintos no cambia nada respecto a no ponerlo. Donde groupRelation="and" sí cambia el resultado es cuando se repite el mismo campo dos veces y se quiere que ambas condiciones se cumplan a la vez, en vez del OR que tocaría por defecto.
Un ejemplo de la versión que no funciona como parece a primera vista. La intención es «solo procesos cuya ruta empiece por la carpeta del actualizador y cuyo nombre de fichero termine en Updater.exe», pero sin forzar el AND, las dos condiciones sobre Image se evalúan con OR y el filtro termina incluyendo cualquier cosa que cumpla cualquiera de las dos, es decir, casi todo lo que arranca de esa carpeta más cualquier Updater.exe del sistema entero:
<ProcessCreate onmatch="include">
<Image condition="begin with">C:Program FilesUpdater</Image>
<Image condition="end with">Updater.exe</Image>
</ProcessCreate>La versión correcta envuelve el filtro en un RuleGroup con groupRelation="and", que fuerza que las dos condiciones sobre Image se cumplan a la vez en vez de bastar con una:
<RuleGroup name="updater legitimo" groupRelation="and">
<ProcessCreate onmatch="include">
<Image condition="begin with">C:Program FilesUpdater</Image>
<Image condition="end with">Updater.exe</Image>
</ProcessCreate>
</RuleGroup>Una restricción práctica que no siempre queda clara al empezar: cada RuleGroup admite un único tipo de evento dentro. Meter dos etiquetas de tipos distintos (por ejemplo ProcessCreate y NetworkConnect) en el mismo RuleGroup no da error, pero Sysmon solo carga las reglas del primer tipo que encuentra y descarta el resto en silencio. Para varios tipos de evento hacen falta varios RuleGroup, uno por tipo. Dentro de un mismo tipo sí caben dos instancias, una con onmatch="include" y otra con onmatch="exclude", donde las coincidencias de exclusión siempre ganan a las de inclusión.
Las condiciones disponibles
Cada campo se compara con un valor usando un atributo condition. Si se omite, el valor por defecto es is (coincidencia exacta). Todas son insensibles a mayúsculas y minúsculas.
| Condición | Qué hace |
|---|---|
| is | Coincidencia exacta (valor por defecto si se omite el atributo) |
| is not | El valor es distinto |
| is any | Coincide con alguno de varios valores separados por punto y coma |
| contains | El campo contiene esa cadena en cualquier parte |
| contains any | Contiene alguno de varios valores separados por punto y coma |
| contains all | Contiene todos los valores separados por punto y coma |
| excludes | El campo no contiene esa cadena |
| excludes any | No contiene ninguno de varios valores |
| excludes all | No contiene la totalidad de varios valores |
| begin with | El campo empieza por esa cadena |
| not begin with | El campo no empieza por esa cadena |
| end with | El campo termina en esa cadena |
| not end with | El campo no termina en esa cadena |
| less than / more than | Comparación lexicográfica menor o mayor que cero |
| image | Compara solo el nombre del ejecutable, ignorando la ruta (por ejemplo, lsass.exe coincide con c:windowssystem32lsass.exe) |
Un matiz de rendimiento que aparece en la guía comunitaria de configuración de Sysmon mantenida por TrustedSec: los operadores basados en subcadena (contains, contains any, contains all) consumen algo más de CPU que los de coincidencia exacta o de prefijo/sufijo, así que en un host con muchos filtros conviene preferir is, is any, begin with o end with cuando el caso lo permite.
Una configuración con varios tipos de evento a la vez
Juntando todo lo anterior, así se vería una configuración que vigila tres tipos de evento con lógica distinta cada uno: creación de procesos de binarios que se usan con frecuencia para ejecución indirecta (con OR, cualquiera de los tres dispara el registro), conexiones salientes a los puertos web habituales excluyendo el ruido de los navegadores, y accesos de otros procesos a lsass.exe:
<Sysmon schemaversion="4.82">
<EventFiltering>
<RuleGroup name="procesos sospechosos" groupRelation="or">
<ProcessCreate onmatch="include">
<Image condition="end with">regsvr32.exe</Image>
<Image condition="end with">mshta.exe</Image>
<Image condition="end with">rundll32.exe</Image>
</ProcessCreate>
</RuleGroup>
<RuleGroup name="conexiones salientes" groupRelation="or">
<NetworkConnect onmatch="include">
<DestinationPort condition="is">443</DestinationPort>
<DestinationPort condition="is">80</DestinationPort>
</NetworkConnect>
<NetworkConnect onmatch="exclude">
<Image condition="end with">msedge.exe</Image>
<Image condition="end with">chrome.exe</Image>
</NetworkConnect>
</RuleGroup>
<RuleGroup name="acceso a lsass" groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="end with">lsass.exe</TargetImage>
</ProcessAccess>
</RuleGroup>
</EventFiltering>
</Sysmon>Nótese que regsvr32.exe con carga remota de scriptlets (el patrón conocido como «Squiblydoo») es justo el ejemplo que usa MITRE para T1218.010, Regsvr32, dentro de la técnica más amplia de abuso de binarios firmados del propio sistema. Vigilar su ejecución no dice por sí solo que haya un ataque (regsvr32 también se usa de forma legítima), pero da la línea de comandos completa para decidirlo caso por caso, que es justo lo que el registro nativo de Windows no ofrece sin Sysmon.
Cómo se decide qué incluir y qué excluir
Activar los 29 tipos de evento sin ningún filtro es la forma más rápida de conseguir un canal de eventos inservible: crece a un ritmo que ningún analista revisa y que casi ningún SIEM de laboratorio aguanta sin degradarse. La pregunta no es «¿qué puedo registrar?» sino «¿qué necesito poder responder cuando alguien pregunte qué pasó en este host?», y esa pregunta se responde distinto en cada organización según qué software corre, qué asume ya cubierto un EDR si lo hay, y cuánto presupuesto de almacenamiento tiene el SIEM.
Por eso casi nadie escribe su configuración de Sysmon desde cero. Hay dos referencias públicas que se han convertido en el punto de partida de facto:
SwiftOnSecurity/sysmon-config
El repositorio sysmon-config de SwiftOnSecurity es un único fichero XML muy comentado (prácticamente cada línea lleva una explicación) pensado como punto de partida legible más que como producto listo para desplegar sin revisión. Su propio encabezado declara licencia Creative Commons Attribution 4.0, que permite privatizar, hacer fork, editar, enseñar, publicar o usar en comercial siempre que se mantenga la atribución en el texto; curiosamente, esa licencia vive solo en el comentario de cabecera del XML, no en un fichero LICENSE aparte, así que el detector automático de licencias de GitHub no la reconoce como tal. El fichero exige Sysmon 13 o superior por cambios de sintaxis, y su propio encabezado se identifica como «versión de origen 74, fecha 2021-07-08». El último cambio real registrado en el repositorio en GitHub es de julio de 2024, así que a día de hoy lleva ya un tiempo sin tocarse: su schemaversion declarado es 4.50, varias versiones por detrás del que trae la documentación oficial actual. El README describe su filosofía con una frase que resume bien el enfoque: es «un complemento a las capacidades nativas de registro de Windows, no un sustituto». Deliberadamente no cubre autenticación (esa parte se deja al registro de seguridad nativo) y espera que el software esté instalado a nivel de sistema, no en carpetas de usuario, así que en un entorno con mucho software portable o instalado por usuario dará bastante ruido hasta que se ajuste.
olafhartong/sysmon-modular
sysmon-modular, de Olaf Hartong, toma el camino contrario: en vez de un único XML monolítico, organiza cada regla en un fichero XML pequeño dentro de una carpeta numerada por ID de evento (una carpeta para el 1, otra para el 3, otra para el 22, y así sucesivamente), cada una con módulos de inclusión y de exclusión separados. Un script de PowerShell (Merge-SysmonXml.ps1) o uno de Python fusiona los módulos elegidos en un único fichero de configuración final. Está publicado bajo licencia MIT y, a diferencia del anterior, se mantiene con actividad reciente: el último cambio en el repositorio es de julio de 2026, apenas unas semanas antes de escribir esto. El propio proyecto declara que necesita Sysmon 15 o superior para funcionar con todas las garantías, con ramas separadas para versiones antiguas del binario. Su gran diferencial es que buena parte de los módulos llevan mapeo explícito a técnicas de MITRE ATT&CK, aunque el propio proyecto avisa de que esos mapeos son «posibles entradas de log que podrían llevar a una detección», no garantías de detección.
Cómo adoptar una sin copiarla a ciegas
Ni una ni otra están pensadas para bajarse, aplicar y olvidarse. Antes de desplegar cualquiera de las dos en algo que no sea un laboratorio conviene, como mínimo: revisar el schemaversion que declaran contra el que soporta el binario instalado (una configuración vieja no falla, pero puede dejar fuera campos o eventos que se añadieron en esquemas posteriores); leer al menos las secciones de exclusión, porque ahí es donde una configuración pública asume software que quizá no corre en tu parque (antivirus concreto, VPN concreta, ERP concreto) y donde puede excluir cosas que en tu entorno sí interesa ver; y medir el volumen resultante en un host de pruebas antes de tocar producción, del modo que se explica en la siguiente sección. También merece la pena mirar cuándo se tocó por última vez cada proyecto: no porque una configuración «vieja» esté necesariamente mal, sino porque los LOLBins y las técnicas de evasión que están de moda cambian con el tiempo, y una lista de exclusiones de hace varios años puede no cubrir binarios que se popularizaron después.
Volumen y rendimiento
Dos categorías de evento concentran casi siempre el grueso del ruido si se activan sin filtrar: la carga de imágenes (evento 7, ImageLoad) y las conexiones de red (evento 3, NetworkConnect). Ambas están desactivadas por defecto precisamente por eso, y la propia documentación de Sysinternals avisa explícitamente sobre ImageLoad: «monitorizar todos los eventos de carga de imagen generará un volumen de registro significativo». Las resoluciones DNS (evento 22) van en la misma categoría por un motivo distinto: no es que el evento en sí sea caro de generar, es que casi todo lo que corre en un endpoint moderno hace resoluciones DNS todo el rato, publicidad web incluida. La propia configuración de SwiftOnSecurity lo señala en un comentario dentro de la sección de DNS: «debido al volumen de eventos que generan las consultas DNS, algunas organizaciones querrán quitar esta sección de su configuración para reducir la rotación del log de Sysmon».
No hay una cifra universal de «tantos eventos por segundo produce tal tipo de evento», porque depende por completo del software instalado, del número de procesos activos y del perfil de red de cada host: cualquier cifra que se dé sin medirla en el entorno real sería inventada, así que aquí no se da ninguna. Lo que sí se puede hacer es medirlo antes de desplegar. Con Sysmon ya aplicando una configuración de prueba en un host de laboratorio, PowerShell permite contar cuántos eventos de cada tipo se generaron en un periodo dado:
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' |
Group-Object -Property Id -NoElement |
Sort-Object -Property Count -DescendingEse comando (usando el cmdlet Get-WinEvent documentado por Microsoft, con Group-Object para contar por ID de evento y Sort-Object para ver primero los tipos que más volumen aportan) da una foto real de qué está generando ruido en ese host concreto, antes de decidir si hace falta un filtro de exclusión más agresivo para ese tipo de evento. Repetirlo tras cada cambio de configuración, en un host que reproduzca el uso normal (no uno recién instalado y sin usar), es la única forma fiable de saber si un filtro nuevo redujo el volumen que se pretendía reducir.
Cómo se recoge el canal y se envía al SIEM
Sysmon escribe en su propio canal del Visor de sucesos, Microsoft-Windows-Sysmon/Operational (en sistemas anteriores a Vista, que hoy ya no aplican a ningún entorno real, iba al log System). De ahí hay que sacarlo hacia el SIEM por algún mecanismo de recolección; el que ya trae Windows sin instalar nada adicional es Windows Event Forwarding (WEF), basado en el protocolo WS-Management. WEF admite dos modos de suscripción: source-initiated, donde el colector define la suscripción sin conocer de antemano qué equipos van a reenviar (los clientes se configuran por GPO para apuntar a él, cómodo cuando el parque de endpoints es grande o cambia), y collector-initiated, donde el colector conoce y define explícitamente cada equipo origen, más manejable cuando se trata de vigilar un conjunto reducido y conocido de máquinas.
La propia guía de Microsoft sobre uso de WEF para apoyo a la detección de intrusiones incluye, entre los ejemplos de consulta de suscripción, uno específico para el canal de Sysmon:
<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
</Query>
</QueryList>Una vez creada la suscripción (con el asistente de Event Viewer o con el propio comando wecutil), los eventos de Sysmon llegan renderizados al log del colector, desde donde ya sea un agente (Winlogbeat, NXLog o el conector que use tu SIEM) o una integración directa del propio SIEM con el Visor de sucesos los recoge y los ingesta. Gestionar y consultar el estado de las suscripciones se hace con wecutil:
wecutil cs suscripcion-sysmon.xml
wecutil gs "Suscripcion Sysmon"
wecutil ss "Suscripcion Sysmon" /cf:EventsEl último de esos comandos cambia el formato de entrega a «Events» (XML binario tal cual se escribiría en el .evtx), más compacto que el formato «Rendered Text» por defecto, que incluye la descripción textual del evento y por eso puede llegar a doblar o triplicar el tamaño de cada mensaje. En entornos con muchos hosts, esa diferencia de formato afecta de forma directa a cuántos eventos por segundo aguanta un único servidor colector antes de necesitar repartir la carga entre varios.
Qué no cubre Sysmon
Sysmon es telemetría pasiva casi en su totalidad: registra lo que ve, con las excepciones puntuales de bloqueo de ejecutables y de shredding ya mencionadas, pero no analiza, no correlaciona y (salvo esas dos excepciones) no interviene sobre lo que observa. La propia documentación de Sysinternals lo deja dicho sin adornos: tampoco intenta ocultarse de un atacante. Eso tiene consecuencias prácticas: un atacante con privilegios de administrador puede ver que Sysmon está instalado (nombre de servicio, nombre de driver, ruta de configuración en el registro, todo consultable con herramientas estándar) y, con más trabajo, puede llegar a desinstalarlo o alterar su configuración; lo único que no puede cambiar sin dejar rastro son el número de altitud del driver y la ruta y nombre del propio canal de log, que quedan fijados por el sistema. Es una asimetría real frente a un EDR, que normalmente sí se protege activamente contra manipulación desde el propio endpoint.
Más allá de la manipulación, hay categorías enteras de visibilidad que un EDR aporta y que Sysmon, por diseño, no cubre: análisis de comportamiento en memoria más allá de lo que capturan sus propios eventos puntuales, correlación entre hosts en tiempo real sin pasar por un SIEM externo, capacidades de respuesta activa como aislamiento de red o reversión de cambios, y por lo general una base de reputación en la nube que contraste hashes y dominios contra inteligencia actualizada constantemente. Nada de eso invalida usar Sysmon: para un SOC que empieza, o que necesita cubrir hosts donde un EDR de pago no es viable, sigue siendo la telemetría de endpoint gratuita más completa que existe, y en muchos casos convive con un EDR en el mismo host en vez de sustituirlo. Lo que conviene tener claro es que la respuesta activa ante lo que Sysmon deja ver (aislar un equipo, recoger evidencia forense, reconstruir la línea de tiempo completa de un incidente) es ya trabajo del curso de DFIR y respuesta a incidentes, no de este módulo.
Ejercicio de laboratorio
El objetivo es cerrar el ciclo completo: escribir una configuración propia centrada en tres tipos de evento, aplicarla, generar actividad real y comprobar en tu SIEM (o, a falta de uno montado, directamente en el Visor de sucesos filtrando por canal) que llega lo que se pretendía y no llega el resto. Necesitas una máquina Windows de pruebas con permisos de administrador y el instalador de Sysmon descargado de Sysinternals; nada de pago.
- Escribe un fichero
miconfig-lab.xmlque active solo tres tipos de evento:ProcessCreate(evento 1),NetworkConnect(evento 3) yProcessAccess(evento 10), cada uno en su propioRuleGroup, siguiendo el patrón del ejemplo compuesto de la sección de sintaxis. Para empezar puedes dejar los tres en modoincludemuy abierto (por ejemplo, todos los procesos para el 1) y ya ajustarás después de ver el volumen. - Instala Sysmon con esa configuración, o aplícala si ya lo tenías instalado:
sysmon64 -accepteula -i miconfig-lab.xmlo, si ya estaba instalado con otra configuración:
sysmon64 -c miconfig-lab.xml - Genera actividad real y benigna para cada uno de los tres tipos de evento. Para
ProcessCreate, basta con abrir y cerrar un par de aplicaciones normales del sistema. ParaNetworkConnect, una petición HTTP cualquiera:Invoke-WebRequest -Uri https://www.microsoft.com -UseBasicParsing | Out-NullPara
ProcessAccess, abre el Administrador de tareas o, si lo tienes instalado, Process Explorer de la propia suite de Sysinternals, y consulta los detalles de un par de procesos en ejecución; el simple hecho de inspeccionarlos desde esas herramientas abre un handle sobre ellos y genera el evento. - Comprueba en el canal de Sysmon, con PowerShell, que llegaron los tres tipos de evento esperados y no llegó ningún otro:
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-Sysmon/Operational'; Id=1,3,10 } -MaxEvents 20 | Select-Object TimeCreated, Id, Message - Repite la medición de volumen de la sección anterior (
Group-Object -Property Id) y, si algún tipo de evento aporta más ruido del esperable para tu actividad de prueba, añade una condiciónexcluderazonada, no una exclusión al azar. Documenta en el propio fichero XML, en un comentario, por qué excluiste lo que excluiste. - Si tienes un SIEM de laboratorio montado y una suscripción WEF apuntando a él, confirma que los mismos eventos aparecen allí con el mismo conteo que en el paso 4. Si la cifra no cuadra, el problema está en la recolección, no en la configuración de Sysmon.
Preguntas frecuentes
¿Sysmon sustituye al registro de eventos de seguridad nativo de Windows?
No. La propia configuración de referencia de SwiftOnSecurity lo resume con precisión: es un complemento a las capacidades nativas de registro, no un sustituto. Cosas como el inicio de sesión, los cambios de política de auditoría o la gestión de cuentas siguen viviendo en el log de Seguridad nativo; Sysmon aporta la capa de detalle de proceso, red y ficheros que ese log no cubre.
¿Con qué frecuencia hay que actualizar Sysmon y qué pasa con la configuración al hacerlo?
Sysinternals publica actualizaciones de Sysmon sin un calendario fijo y no mantiene un historial de versiones completo, así que la única forma fiable de saber cuál tienes delante es descargar el paquete y ejecutar sysmon -? config. La última actualización de Sysmon anunciada en la página de novedades de Sysinternals, consultada en julio de 2026, es la v15.2 del 26 de marzo de 2026, que mejoró el manejo de la cola interna de eventos para perder menos bajo carga alta. Actualizar consiste en desinstalar el binario antiguo e instalar el nuevo apuntando al mismo fichero de configuración: como el schemaversion es independiente de la versión del binario, una configuración antigua se sigue cargando sin tocarla, aunque conviene revisar si el nuevo binario soporta tipos de evento o campos que la configuración vieja no contempla.
¿Puedo usar la configuración de SwiftOnSecurity o de sysmon-modular tal cual, sin revisarla?
Técnicamente sí carga y funciona, pero no es buena idea desplegarla sin revisión en nada que no sea un laboratorio. Cada una asume un contexto (qué software corre, qué se considera ruido aceptable) que puede no coincidir con el tuyo, y una de las dos (SwiftOnSecurity) lleva ya un tiempo sin actualizarse. Adoptarla bien implica leerla, medir el volumen que produce en tu entorno concreto y ajustar antes de tocar producción.
¿Por qué mi regla con dos condiciones no filtra como esperaba?
Casi siempre es la combinación por defecto: dos condiciones sobre el mismo campo se combinan con OR (basta una para que coincida), y dos condiciones sobre campos distintos se combinan con AND (hacen falta las dos). Si necesitas que dos condiciones sobre el mismo campo se cumplan a la vez, hace falta envolver el filtro en un RuleGroup con groupRelation="and" explícito; sin ese envoltorio, Sysmon aplicará el OR por defecto y el filtro dejará pasar más de lo que pretendías.
¿Sysmon puede bloquear actividad, o solo audita?
Casi todo lo que hace es auditoría pura, sin intervención. La excepción son los eventos 27 (FileBlockExecutable) y 28 (FileBlockShredding), que sí bloquean la acción que detectan (creación de un ejecutable y borrado seguro de ficheros, respectivamente), no solo la registran. Es una capacidad de prevención muy acotada, no un reemplazo de un producto de bloqueo en tiempo real de propósito general.
¿Cuál es la diferencia real entre Sysmon y un EDR comercial?
Sysmon es una fuente de telemetría gratuita y muy detallada, pero no analiza lo que registra, apenas tiene capacidad de bloqueo y no se protege de forma activa contra manipulación por parte de un atacante con privilegios suficientes. Un EDR añade análisis de comportamiento, correlación entre hosts, respuesta activa (aislamiento, reversión) y protección propia contra manipulación. En la práctica, muchos SOC usan ambos a la vez: Sysmon como fuente barata y flexible de eventos para el SIEM, y el EDR como capa de bloqueo y respuesta en el propio endpoint.