Desplegar y ajustar Sysmon a escala

La línea base de directiva de auditoría y Sysmon explica qué registra Sysmon y por qué lo quieres. Instalarlo en una máquina lleva un minuto. Ejecutarlo en miles de máquinas, con una configuración que detecte ataques sin sepultar tu SIEM, es otro trabajo. Esta guía trata de ese trabajo: elegir una configuración, ajustarla con datos, desplegarla y actualizarla a escala, y asegurarte de enterarte cuando deja de funcionar.

Antes de empezar: independiente o integrado

Sysmon viene ahora también integrado en Windows 11 y Windows Server 2025 como característica opcional, desactivada de forma predeterminada. En Windows 11 24H2 y 25H2 llegó con la actualización de vista previa del 24 de febrero de 2026 (KB5077241) y las actualizaciones acumulativas posteriores. Se habilita con Enable-WindowsOptionalFeature -Online -FeatureName Sysmon (o Dism /Online /Enable-Feature /FeatureName:Sysmon) y después se ejecuta sysmon -i con tu configuración. Usa el mismo formato de configuración XML, escribe en el mismo canal Sysmon Operational y Windows Update mantiene sus binarios. Tres puntos prácticos:

• Sysmon independiente y la característica integrada no pueden ejecutarse en el mismo equipo. Desinstala la versión de Sysinternals antes de habilitar la integrada.
• La versión integrada localiza el mensaje del evento. Analiza los campos XML del evento, no el texto del mensaje, o tu canalización fallará en sistemas que no estén en inglés.
• Todo lo que sigue sobre configuración, ajuste y supervisión se aplica a ambas.

Paso 1: elige una estrategia de configuración

La mayoría de los equipos hacen un fork de sysmon-modular o SwiftOnSecurity en su propio repositorio, mantienen el proyecto original como remoto y aplican los cambios locales como una capa fina encima. Si Defender for Endpoint está desplegado, la variante de sysmon-modular pensada para complementar MDE evita recopilar lo que MDE ya registra bien. Consulta modo de bloqueo y modo pasivo de EDR para ver cómo encaja MDE junto a otras herramientas.

Mantén una configuración base y añade capas por rol: estaciones de trabajo, servidores miembro, controladores de dominio y servidores expuestos a Internet tienen comportamientos normales distintos. Un controlador de dominio no debería lanzar nunca un navegador; un portátil de desarrollo lanza compiladores todo el día.

Ejemplos de lo que suelen cambiar esas capas:

• Estaciones de trabajo: mantén amplios los eventos de creación de procesos, red y DNS; excluye con precisión el ruido del navegador y de las aplicaciones de colaboración.
• Controladores de dominio: incluye en detalle el acceso a procesos sobre lsass.exe, conserva los eventos de red de procesos inusuales y excluye el tráfico LDAP y de replicación, abundante pero esperado, de los procesos del sistema.
• Servidores web y de aplicaciones: registra todos los procesos hijo del servicio web o de base de datos, porque casi nunca lanzan shells de forma legítima.
• Servidores de salto y PAW: más detalle que en ningún otro sitio, porque su actividad es por definición actividad de administración y merece revisión.

Comprueba que el schemaversion del archivo coincide con lo que admite tu binario:

Sysmon64.exe -s | Select-Object -First 5   # muestra el esquema que admite este binario

Paso 2: entiende el motor de reglas antes de ajustar

Los errores de ajuste suelen venir de interpretar mal cómo evalúa Sysmon las reglas:

• Cada tipo de evento tiene un filtro onmatch="include" u onmatch="exclude". Un tipo de evento con un filtro include vacío no registra nada; uno con un filtro exclude vacío lo registra todo.
• Dentro de un RuleGroup, groupRelation="or" significa que basta con que se cumpla una condición; groupRelation="and" significa que deben cumplirse todas. Usa grupos and para que las exclusiones sean precisas.
• Pon nombre a tus reglas. El atributo name aparece como RuleName en el evento, y así ven los analistas por qué se registró algo (por ejemplo, un ID de técnica).

Una exclusión precisa tiene este aspecto:

<RuleGroup name="Exclude agent update checks" groupRelation="and">
  <NetworkConnect onmatch="exclude">
    <Image condition="is">C:\Program Files\Contoso Agent\agent.exe</Image>
    <DestinationPort condition="is">443</DestinationPort>
  </NetworkConnect>
</RuleGroup>

Y una inclusión dirigida al robo de credenciales:

<RuleGroup name="" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage name="technique_id=T1003.001,technique_name=LSASS Memory" condition="is">C:\Windows\system32\lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

Combina esa regla sobre LSASS con la protección LSA y Credential Guard: la configuración te dice que alguien lo intentó, la protección hace que el intento fracase.

Paso 3: mide y después recorta el ruido

Haz un piloto de una semana con 20 a 50 máquinas por rol, con el registro de Sysmon bastante por encima de su pequeño tamaño predeterminado:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824   # 1 GB

Después averigua de dónde viene el volumen:

$ev = Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 50000

# Volumen por ID de evento
$ev | Group-Object Id | Sort-Object Count -Descending | Select-Object Count, Name

# Procesos con más conexiones de red (evento 3)
$ev | Where-Object Id -eq 3 | ForEach-Object {
  ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'Image' | ForEach-Object '#text'
} | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Haz lo mismo en tu SIEM sobre todo el piloto. Los culpables habituales son los eventos 3 (red), 7 (carga de imágenes), 10 (acceso a procesos), 11 (creación de archivos), 12/13 (registro) y 22 (DNS), generados por navegadores, agentes de seguridad, software de copia de seguridad y actualizadores.

Reglas para recortar el ruido con seguridad:

1. Excluye por ruta completa, nunca por nombre. Image end with chrome.exe excluye cualquier archivo que un atacante llame chrome.exe. Image is C:\Program Files\Google\Chrome\Application\chrome.exe no.
2. No excluyas nunca ubicaciones en las que el usuario puede escribir, como C:\Users\, C:\ProgramData\ o %TEMP%. Es ahí donde los atacantes preparan sus herramientas.
3. Combina campos. Excluye un proceso y un puerto de destino, o una imagen de origen y una de destino para el acceso a procesos, no solo el proceso.
4. Prefiere las firmas para las cargas de imágenes. El evento 7 incluye Signed y Signature; excluir las DLL firmadas por Microsoft cargadas por procesos firmados por Microsoft elimina la mayor parte del volumen.
5. Prioriza el valor de seguridad. Antes de eliminar un tipo de evento, anota qué detección depende de él. Los eventos 1, 3, 10, 11, 13 y 22 de Sysmon alimentan la mayor parte del contenido de detección.
6. Cuidado con la eliminación de archivos. FileDelete (evento 23) con un directorio de archivo copia cada archivo eliminado y puede llenar discos. FileDeleteDetected (evento 26) registra sin archivar y suele bastar.

Paso 4: despliega y actualiza a escala

Sysmon instala un controlador y un servicio, y se copia a sí mismo en %windir%. Despliégalo con la herramienta en la que ya confías para el software: Configuration Manager, una aplicación Win32 de Intune o una tarea programada lanzada por GPO. La lógica es la misma: instalar si falta, actualizar si el binario cambió, recargar la configuración si el archivo cambió.

$pkg    = 'C:\ProgramData\CorpSysmon'
$binary = Join-Path $pkg 'Sysmon64.exe'
$config = Join-Path $pkg 'sysmonconfig.xml'
$marker = Join-Path $pkg 'applied.sha256'

if (-not (Get-Service -Name Sysmon64 -ErrorAction SilentlyContinue)) {
    & $binary -accepteula -i $config
} elseif ((Get-Item "$env:windir\Sysmon64.exe").VersionInfo.FileVersion -ne
          (Get-Item $binary).VersionInfo.FileVersion) {
    & "$env:windir\Sysmon64.exe" -u force
    & $binary -accepteula -i $config
}

$hash = (Get-FileHash $config).Hash
if (-not (Test-Path $marker) -or (Get-Content $marker) -ne $hash) {
    & $binary -c $config
    Set-Content -Path $marker -Value $hash
}

Los cambios de configuración con -c se aplican sin reinicio ni interrupción. Las actualizaciones del binario mediante desinstalación y reinstalación dejan un breve hueco de supervisión; consulta las notas de cada versión para conocer la ruta de actualización admitida y planifica las actualizaciones en lugar de dejar que ocurran al azar.

Proceso de publicación:

• Configuración en control de código fuente, revisada como si fueran reglas de firewall.
• Valida el XML en una máquina de prueba con -c antes de publicarlo; un archivo incorrecto se rechaza y la configuración anterior sigue activa, lo que puede ocultar que tu cambio nunca llegó a aplicarse.
• Despliega por anillos: piloto, después el 10 % y después todos, vigilando el volumen de eventos en cada paso.
• Evita dejar la configuración en un recurso compartido que pueda leer cualquier usuario. Le dice a un atacante exactamente qué no registras.

El modificador -d instala el controlador con otro nombre, y cambiar el nombre del ejecutable cambia el nombre del servicio. Eso solo oculta Sysmon a los scripts más perezosos; no es un control y complica tus propias comprobaciones de estado.

Qué se rompe

• Los costes de ingesta del SIEM se disparan si la primera configuración es demasiado detallada. Haz siempre un piloto antes de desplegar en todo el parque.
• Los problemas de rendimiento son raros pero reales con inclusiones amplias de carga de imágenes o de registro en servidores con mucha actividad, como Exchange, SQL o servidores de archivos.
• Coexistencia: algunos productos de seguridad supervisan las mismas devoluciones de llamada del kernel. Prueba con tus agentes de EDR y de copia de seguridad.
• Configuraciones obsoletas: los equipos que se perdieron una actualización siguen ejecutando reglas antiguas en silencio, salvo que lo compruebes.

Paso 5: supervisa el propio Sysmon

Un Sysmon que se detuvo hace dos semanas es indistinguible de un equipo tranquilo. Detecta:

• Los eventos de Sysmon 4 (cambio de estado del servicio), 16 (cambio de configuración) y 255 (error).
• Las detenciones del servicio registradas por el Service Control Manager en el registro System.
• Los equipos sin eventos de Sysmon en las últimas horas que siguen enviando otros registros.
• La deriva de configuración: añade el hash de la configuración a tu inventario y compáralo en todo el parque.

Verificación

En un equipo de prueba, comprueba la configuración en ejecución y provoca eventos conocidos:

Sysmon64.exe -c                                   # muestra la configuración activa y su hash
Resolve-DnsName example.com                       # se espera el evento 22
Test-NetConnection example.com -Port 443          # se espera el evento 3 si no está excluido

Confirma que esos eventos llegan al SIEM con el RuleName correcto, a través de Windows Event Forwarding o de tu agente. Después pasa la misma prueba por tu contenido de detección, por ejemplo la regla de PowerShell no administrado de detección de PowerShell malicioso. Para los ID de evento que Windows registra sin Sysmon, consulta la referencia de ID de eventos de seguridad; encontrarás más sobre Sysmon y el registro en la página temática de auditoría y registro.

Lista de comprobación

• Decidido Sysmon independiente o integrado para cada compilación del sistema operativo
• Configuración derivada de un proyecto mantenido, en control de código fuente, con capas por rol
• Piloto medido por ID de evento y por proceso antes del despliegue en todo el parque
• Exclusiones con rutas completas y campos combinados; ninguna carpeta en la que pueda escribir el usuario
• Registro de Sysmon dimensionado como búfer local; eventos reenviados
• Instalación, actualización y recarga de configuración automatizadas, con despliegue por anillos
• Estado de Sysmon supervisado (4, 16, 255, detenciones del servicio, equipos silenciosos, hash de configuración)
• Ajuste revisado cada trimestre frente al contenido de detección