Directiva de auditoría de Windows y Sysmon: línea base

Cuando algo sale mal en una red Windows, las primeras preguntas son siempre las mismas: ¿qué cuenta inició sesión y dónde, qué se ejecutó, qué cambió y adónde se conectó? Con la configuración predeterminada, Windows responde a pocas de ellas. La creación de procesos no se registra, las líneas de comandos no se capturan, el registro de seguridad se sobrescribe en cuestión de horas en un servidor con mucha actividad y nada sale del equipo.

Esta guía construye una línea base de registro en cuatro capas: directiva de auditoría avanzada, algunas configuraciones adicionales, Sysmon y reenvío.

Capa 1: directiva de auditoría avanzada

Primero, haz que la directiva de auditoría avanzada sea la que manda. En Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, habilita Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings (forzar que la configuración de subcategorías invalide la de categorías).

Después configura las subcategorías en Security Settings > Advanced Audit Policy Configuration > Audit Policies. Un buen punto de partida, alineado a grandes rasgos con las recomendaciones de la línea base de Microsoft:

Comprueba la directiva efectiva en un equipo:

auditpol /get /category:*
auditpol /get /subcategory:"Process Creation"

En un laboratorio puedes configurar subcategorías individuales directamente (en producción, la GPO sigue siendo la fuente de verdad):

auditpol /set /subcategory:"Process Creation" /success:enable

Capa 2: las configuraciones que hacen útiles los eventos

Las líneas de comandos pueden contener secretos (contraseñas pasadas como parámetros). Eso es motivo para restringir quién lee los registros y para corregir esos scripts, no para dejar desactivado el registro de la línea de comandos.

Vigila también la destrucción de evidencias: el 1102 (registro de seguridad borrado) y el 104 (otro registro borrado, en System) deben generar siempre una alerta.

Capa 3: Sysmon

Sysmon (System Monitor, de Microsoft Sysinternals) es un controlador y servicio gratuito que registra con detalle la actividad de procesos, red, archivos y registro en Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. Desde 2026 es también una característica opcional integrada en Windows 11 y Windows Server 2025, desactivada de forma predeterminada y configurada con el mismo XML; la guía de despliegue de Sysmon explica cómo elegir entre ambas opciones. Sus eventos más útiles:

Sysmon vale lo que vale su configuración: una configuración vacía registra muy poco y una ingenua inunda tu SIEM. Parte de una configuración comunitaria mantenida, como sysmon-config de SwiftOnSecurity o sysmon-modular de Olaf Hartong, y ajústala a tu entorno.

# Instalar con una configuración
Sysmon64.exe -accepteula -i sysmonconfig.xml
# Actualizar la configuración más adelante
Sysmon64.exe -c sysmonconfig.xml
# Mostrar la configuración activa
Sysmon64.exe -c

Despliega Sysmon con tu herramienta de distribución de software, fija la versión y supervisa que el servicio Sysmon64 esté en ejecución: detenerlo es un movimiento obvio de un atacante (Sysmon registra el evento 4 para cambios de estado del servicio y el 16 para cambios de configuración).

Capa 4: saca los eventos del equipo

Cualquiera con derechos de administrador puede borrar los registros locales. Reenvíalos.

Windows Event Forwarding (WEF) viene integrado y no necesita agente:

1. En un servidor recopilador: wecutil qc para configurar el servicio Windows Event Collector.
2. Crea suscripciones iniciadas por el origen (consultas XPath que seleccionen los ID de evento anteriores).
3. Por GPO en los orígenes: Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager = Server=http://wec01.corp.example:5985/wsman/SubscriptionManager/WEC,Refresh=60.
4. Concede a la cuenta Network Service acceso de lectura al registro de seguridad en los orígenes, agregándola al grupo Event Log Readers mediante Restricted Groups o Group Policy Preferences.

Desde el recopilador, envía ForwardedEvents a tu SIEM. Si ya usas un agente de SIEM o de EDR, apúntalo a los mismos ID de evento; lo importante es que los eventos salgan del equipo en cuestión de minutos.

Cómo es un buen resultado

Una forma rápida de probar la línea base es plantear las preguntas de un incidente imaginario y ver si tus registros las responden:

• ¿Quién inició sesión en el servidor X el martes pasado y desde dónde? 4624 con tipo de inicio de sesión e IP de origen, reenviado.
• ¿Qué ejecutó esa sesión? 4688 con líneas de comandos, Sysmon 1, PowerShell 4104.
• ¿Algo tocó LSASS? Sysmon 10 filtrado por lsass.exe.
• ¿Se añadió persistencia? 4697 / 7045 (servicio), 4698 (tarea programada), Sysmon 13 en claves Run.
• ¿Adónde se conectó? Sysmon 3 y 22.
• ¿Alguien intentó ocultarlo? 1102, 104, Sysmon 4/16, Defender 5001/5007.

Lista de comprobación

• Directiva de auditoría avanzada forzada para invalidar la básica; subcategorías configuradas como arriba
• Captura de la línea de comandos en el 4688 habilitada
• Registro de seguridad dimensionado para días, no horas; alertas sobre los eventos de borrado
• Sysmon desplegado con una configuración mantenida y ajustada
• Eventos reenviados (WEF o agente) y retenidos de forma centralizada
• Preguntas de incidente respondidas de principio a fin en un ejercicio de simulación

El registro no impide nada, pero todos los demás controles de este mapa son más fáciles de confiar cuando puedes verlos funcionar, y ver el momento en que dejan de hacerlo.