Monitorización nativa de Windows
En artículos anteriores hemos repasado varias herramientas de monitorización, comerciales y opensource, para saber qué pasa en nuestra infraestructura. Pero hay una pregunta que en muchas empresas se queda sin respuesta, ¿qué ejecutó exactamente ese proceso "raro" del servidor de anoche?
Centreon o Nagios te dicen que el servidor está vivo, que la CPU va al 90 % o que el disco se está llenando. No te dicen quién lanzó un PowerShell con un comando X ni a qué IP se conectó justo después. Ahí es donde entra Sysmon.
Es una utilidad de Sysinternals, que si no conoces deberías conocer, que se instala como servicio y driver, y apunta en el visor de eventos lo que Windows de serie no cuenta, creación de procesos con su línea de comandos y su hash, conexiones de red, carga de drivers y DLL, cambios en el registro. Observa y anota sin tocar nada, con un impacto razonable si la configuración está bien afinada. No sustituye a esas herramientas, las complementa, porque mira "otras cosas" que son básicas para la seguridad de tu empresa.
Si tu empresa todavía no está lista para una solución completa de monitorización, tampoco pasa nada. Sysmon es un buen punto de partida, no cuesta dinero y te enseña rápido por qué no conviene dejar este tema para más adelante.
Hoy lo vamos a montar en un laboratorio sobre Proxmox, un Windows 11 como equipo cliente a vigilar y un Windows Server 2025 que hará de recolector de eventos. Intentaré poner varios ejemplos para que entendáis el poder de la herramienta.
Laboratorio Monitorización: Windows Server 2025 y Windows 11 con Sysmon
Para el laboratorio usaremos un Windows Server 2025 (que será el recolector de eventos, y en mi red tiene role de controlador de dominio) y un Windows 11 como cliente, bajo Proxmox, pero esto no difiere en la práctica de otro tipo de infraestructura:
Para comenzar, podemos comprobar si está instalado en el sistema de nuestras máquinas virtuales con el comando "Get-Service sysmon*":
También podríamos comprobar la compatibilidad con "Get-WindowsOptionalFeature -Online -FeatureName Sysmon":
Si no devuelve nada, probablemente tendréis que actualizar el sistema operativo.
Preparar Windows Server 2025 para Sysmon
Vamos a preparar el entorno pieza a pieza. Comenzamos con Windows Server 2025.
Al tener el role de controlador de dominio, es una pieza de la infraestructura clave, así que la monitorizaremos también. Aunque su role principal es de recolector de eventos.
Antes de comenzar, hay que entender que Sysmon viene desactivado por defecto, así que necesitamos preparar el entorno por completo.
Activar recopilación de eventos en Windows Server 2025
Para activar el servicio de recopilación de eventos de Windows lanzaremos en Windows Server "wecutil.exe qc /q"
Opcionalmente, si disponemos de cortafuegos de Windows, configuramos regla WinRM bajo el puerto 5985:
New-NetFirewallRule -DisplayName "WEF 5985" -Direction Inbound -Protocol TCP -LocalPort 5985 -Action Allow
Como vamos a monitorizar adicionalmente un servidor que es controlador de dominio, tendremos que darle permisos al grupo local:
## EN INGLES:
net localgroup "Event Log Readers" "NT AUTHORITY\NETWORK SERVICE" /add
## EN ESPAÑOL:
net localgroup "Lectores del registro de eventos" "NT AUTHORITY\SERVICIO DE RED" /addComo no queremos todos los eventos, creamos una regla bajo un fichero XML que podemos colocar en "C:". El contenido del fichero:
LabSysmon
SourceInitiated
Sysmon y logins del dominio
true
http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
MinLatency
1 10000
]]>false
HTTP
RenderedText
ForwardedEvents
O:NSG:BAD:P(A;;GA;;;DC)(A;;GA;;;DD)S:
Y lanzamos los comandos para crear la subscripción (que es la regla que dice qué eventos se aceptan):
##cs = create subscription.
##es = enumerate subscriptions, lista las que existen. Debe aparecer LabSysmon.
##gs = get subscription, muestra su configuración.wecutil cs C:\sysmon-sub.xml
wecutil eswecutil gs LabSysmon
Preparar la configuración de Sysmon en el controlador de dominio
Publica la configuración en NETLOGON para que todos los equipos la lean. Creamos una carpeta:
$dir = "C:\Windows\SYSVOL\sysvol\negu.local\scripts\sysmon"
New-Item -ItemType Directory -Path $dir -Force
Descargamos configuración que mantiene la comunidad como "SwiftOnSecurity" que nos ahorrá muchos dolores de cabeza:
Invoke-WebRequest "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "$dir\sysmonconfig.xml"
Comprobamos que el fichero tenga el contenido correcto:
Instalar Sysmon en Windows Server 2025
Lanzamos los siguientes comandos:
Get-WindowsOptionalFeature -Online -FeatureName Sysmon
Enable-WindowsOptionalFeature -Online -FeatureName Sysmon
Ahora comprobamos la ruta física de nuestro NETLOGON, y la adaptamos. Lo hacemos con "Get-SmbShare NETLOGON" o revisando con un explorador de Windows:
Ahora con el siguiente comando vemos si el servicio está arrancado:
sysmon -i "\\negu.local\NETLOGON\sysmon\sysmonconfig.xml"
Y comprobamos que funciona bien (lee los tres últimos eventos del registro de Sysmon, ya debería haber eventos):
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 3
GPO para Sysmon
Para que los clientes que estén en directorio activo integrados sepan donde dejar los eventos que recopilen, necesitaremos indicarles quién es el recolector de eventos en nuestra red. Para eso creamos una GPO.
Abrimos el administrador de directivas de grupo:
Creamos una nueva directiva o GPO:
Le damos un nombre significativo:
La editamos:
Vamos a "Configuración del equipo > Directivas > Plantillas administrativas > Componentes de Windows > Reenvío de eventos":
Habilitamos la configuración y agregamos los datos del servidor que hace de recolector:
Server=http://neguad01.negu.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
Adicionalmente, en la misma directiva, "Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad":
Desde ahí, los tres apartados quedan así:
Paso 1: Forzar subcategorías
- Despliega Directivas locales -> Opciones de seguridad
- En la lista de la derecha busca Auditoría: forzar la configuración de subcategorías... (la más larga de la lista)
- Doble clic -> marca Definir esta configuración de directiva -> Habilitada -> Aceptar
Paso 2: auditar inicios de sesión
- Más abajo, en el mismo árbol, despliega Configuración de directiva de auditoría avanzada -> Directivas de auditoría
- Entra en Inicio/cierre de sesión y haz doble clic en Auditar inicio de sesión
- Marca Configurar los siguientes eventos de auditoría, y activa Correcto y Error
Paso 3: Auditar altas de usuario
- En esa misma rama (Directivas de auditoría), entra en Administración de cuentas, no en las "Directivas locales"
- Doble clic en Auditar administración de cuentas de usuario, marca Configurar... y activa Correcto
Cómo instalar y configurar Sysmon en Windows 11
Antes de instalar Sysmon, nos aseguramos que el servicio WinRM está Inicio y en automático, sino no podrá enviar eventos:
En los clientes (no en el DC), la cuenta que envía necesita leer el registro de seguridad. Así que vamos a "Administración de equipos > Usuarios y grupos locales" y buscaremos el grupo "Lectores del registro de eventos", y le daremos permisos a "NT AUTHORITY\SERVICIO DE RED (en inglés, NETWORK SERVICE)". Lo buscaremos en la ubicación del propio PC:
Para instalar el cliente de Sysmon en el cliente Windows 11, abrimos la consola y lanzamos la instalación vía comandos:
Enable-WindowsOptionalFeature -Online -FeatureName Sysmon
sysmon -i "\\lab.local\NETLOGON\sysmon\sysmonconfig.xml"Get-Service *sysmon*
Para terminar forzamos las políticas en el cliente y en el servidor para que se apliquen:
gpupdate /forceauditpol /get /category:*
Validar configuraciones Sysmon
Para verificar que todo está correcto, haremos unas pequeñas validaciones:
Verificar que se ha aplicado GPO en Cliente
Desde el Windows 11:
gpresult /r /scope computer
Comprobar servicio WinRM y grupo local
WinRM debe estar "Running" y el grupo anteriormente configurado mostrarse:
Comunicación Cliente - Servidor
Revisamos que llegamos al servidor desde el cliente:
Test-NetConnection NEGUAD01.negu.local -Port 5985
Resolve-DnsName NEGUAD01.negu.local
Comprobaciones en el servidor
winrm enumerate winrm/config/listener
Get-NetFirewallRule -DisplayName "WEF 5985" | Select DisplayName, Enabled, Direction, Action
Comprobamos la subscripción con "wecutil gr LabSysmon":
Validar que se crea la clave de registro de la GPO
Otra posible causa de errores, es que la clave de registro no se cree adecuadamente con la GPO. Podéis crearla manualmente hasta que lo solucionéis:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager" /v 1 /t REG_SZ /d "Server=http://neguad01.negu.local:5985/wsman/SubscriptionManager/WEC,Refresh=60" /f
Restart-Service WinRMVer eventos Sysmon vía gráfica
Desde el visor de eventos del "Server -> Registros de Windows -> Eventos reenviados" podréis ver los eventos visualmente:
Casos de Uso Prácticos para Sysmon
Con todo preparado vamos a exponer varios casos de uso prácticos. Accedemos al cliente con las credenciales de directorio activo:
Caso 1: Saber qué aplicaciones abre un usuario
Por ejemplo, lanzamos "regedit.exe" en el Windows 11. Una vez abierto, podemos ir a Windows Server y buscar el evento con ID -> 1, que nos registrará el usuario que lo ha lanzado y la linea de comando usada:
Caso 2: Alta de un usuario nuevo en el dominio
Vigilar los usuarios de dominio tendría que ser algo crítico para cualquier empresa. Con Sysmon podemos hacer vigilancia de ello.
Lanzamos en Windows Server el siguiente comando:
New-ADUser -Name "Prueba Sysmon" -SamAccountName pruebasysmon.negu -AccountPassword (Read-Host "Contraseña" -AsSecureString) -Enabled $true
Buscamos un ID -> 4720 y observamos que lo ha auditado:
Caso 3: Inicios de sesión correctos y fallidos
¿Cuántas veces te ha llamado un usuario con problemas en su login? Podemos encontrar el problema también fácilmente.
Cerramos la sesión del Windows 11 y fallamos al intentar meter las credenciales:
Nos aparecerá un mensaje de este estilo:
Ahora buscamos el ID -> 4625 que nos muestra el problema en el logon:
Caso 4: PowerShell con comando codificado
Si queremos detectar el lanzamiento de PowerShell sospechoso, os pongo otro ejemplo.
Lanzar en Windows 11 este comando, que "ofusca / oculta" el comando "whoami" porque está codificado en base64:
powershell -enc dwBoAG8AYQBtAGkA
También lo encontraremos con ID -> 1:
Caso 5: Persistencia al arrancar (carpeta de inicio y clave Run)
Cuando un equipo se ve infectado, es normal que se queden ficheros de forma persistente en el arranque, para que sea muy complicado limpiarlos. Con Sysmon también podemos detectarlos.
Podemos generarlos en Windows 11 de la siguiente forma:
New-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\prueba.txt" -ItemType File
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v PruebaLab /d notepad.exe
Se mostrarán bajo evento ID > 13:
Caso 7: Consulta DNS de un proceso
Si queremos descubrir resoluciones de nombres "raras", que es un comportamiento habitual de ordenadores infectados, también podemos detectarlos.
Lanzamos el siguiente comando para la prueba "Resolve-DnsName maquinasvirtuales.eu":
El ID -> 22 nos reflejará el comportamiento y el usuario asociado:
Existen más casos de uso, pero como veis es una herramienta muy potente, que puede complementar cualquier SIEM.
Tabla ID de Eventos
Os dejo la tabla oficial con otros ID´s de Eventos:
| ID | Etiqueta | Evento |
|---|---|---|
| 1 | ProcessCreate | Crear proceso |
| 2 | HoraDeCreaciónDelArchivo | Hora de creación del archivo |
| 3 | NetworkConnect | Conexión de red detectada |
| 4 | N/D | Cambio de estado del servicio Sysmon (no se puede filtrar) |
| 5 | ProcessTerminate | Proceso terminado |
| 6 | DriverLoad | Controlador cargado |
| 7 | ImageLoad | Imagen cargada |
| 8 | CreateRemoteThread | CreateRemoteThread detectado |
| 9 | RawAccessRead | RawAccessRead detectado |
| 10 | ProcessAccess | Proceso al que se accede |
| 11 | FileCreate | Archivo creado |
| 12 | RegistryEvent | Objeto del Registro agregado o eliminado |
| 13 | RegistryEvent | Conjunto de valores del Registro |
| 14 | RegistryEvent | Se ha cambiado el nombre del objeto del Registro |
| 15 | FileCreateStreamHash | Secuencia de archivos creada |
| 16 | N/D | Cambio de configuración de Sysmon (no se puede filtrar) |
| 17 | PipeEvent | Canalización con nombre creada |
| 18 | PipeEvent | Canalización con nombre conectada |
| 19 | WmiEvent | Filtro WMI |
| 20 | WmiEvent | Consumidor WMI |
| 21 | WmiEvent | Filtro de consumidor WMI |
| 22 | DnsQuery | Consulta de DNS |
| 23 | FileDelete | Eliminación de archivos archivados |
| 24 | ClipboardChange | Nuevo contenido en el Portapapeles |
| 25 | Manipulación de Procesos | Cambio de imagen de proceso |
| 26 | FileDeleteDetected | Eliminación de archivos registrada |
| 27 | FileBlockExecutable | Bloqueo de archivos ejecutables |
| 28 | FileBlockShredding | Fragmentación de bloques de archivos |
| 29 | FileExecutableDetected | Archivo ejecutable detectado |
De Sysmon al SIEM
Hemos desplegado Sysmon en un Windows 11 y centralizado sus eventos en un Windows Server 2025. Con ello cubrimos algo que las herramientas de monitorización tradicionales no abordan, la visibilidad sobre lo que ocurre dentro de los equipos. Saber que un servicio responde no equivale a saber qué se está ejecutando en él.
Aunque es una herramienta muy potente, e integrada en Windows, conviene ser realistas con el alcance. Sysmon no es una solución de monitorización ni sustituye a Centreon o Nagios, es una fuente de telemetría que los complementa. Su utilidad depende casi por completo de la configuración.
Con los valores por defecto genera un volumen de eventos difícil de manejar, mientras que una base mantenida, como os entregamos en esta guía, con la gran ayuda de la comunidad (SwiftOnSecurity o sysmon-modular), filtra mucho el ruido y deja lo importante.
Recolectar los eventos es solo la primera mitad del trabajo. Sin alguien o algo que los analice y genere alertas, siguen siendo un registro que se consulta cuando el incidente ya ha ocurrido.
Todo evento necesita la respuesta del equipo humano que está detrás. El paso natural es integrarlos en un SIEM, y tener el control total de tu infraestructura IT.
Fin del Artículo. ¡Cuéntanos algo en los Comentarios!
