Aviso ético y legal: las técnicas, comandos y configuraciones de esta lección se aplican exclusivamente en sistemas, redes y entornos de laboratorio sobre los que tengas autorización explícita y por escrito (tu propia infraestructura, un laboratorio personal o un entorno corporativo con mandato formal de tu equipo de seguridad). Desplegar auditoría avanzada, Sysmon o reenvío de eventos en sistemas de terceros sin autorización puede vulnerar la Ley Orgánica 10/1995 (Código Penal, art. 197 bis y siguientes) y normativa equivalente en otras jurisdicciones. Todo lo que sigue está pensado para un laboratorio de prácticas o un entorno de producción propio bajo tu responsabilidad.
Qué aprenderás
- Por qué la Preparación es, en coste/beneficio, la fase más rentable del ciclo de vida de un incidente (NIST SP 800-61) y qué falla cuando se omite.
- Qué telemetría necesitas tener funcionando antes del incidente, no durante ni después.
- Cómo configurar la política de auditoría avanzada de Windows (
auditpol) y qué subcategorías activar. - Los Event ID de seguridad indispensables en IR: 4624/4625/4634/4648/4672 (logon), 4688 (procesos con línea de comandos), 4698 (tareas), 7045 (servicios), 4720/4726 (cuentas), 5140/5145 (shares) y 4103/4104 (PowerShell).
- Qué es Sysmon, cómo desplegarlo con una configuración de referencia (SwiftOnSecurity u Olaf Hartong) y sus eventos clave (1, 3, 7, 8, 11, 12/13, 22).
- Cómo centralizar todo con Windows Event Forwarding (WEF) y un SIEM, qué aporta un EDR y cuánto tiempo retener los logs.
- Los fundamentos de playbooks/runbooks y de documentación con cadena de custodia.
1. Por qué la Preparación es la fase más rentable
El modelo de NIST SP 800-61 (Computer Security Incident Handling Guide) describe el ciclo de vida de la respuesta a incidentes en cuatro fases: Preparación, Detección y Análisis, Contención/Erradicación/Recuperación, y Actividad Post-Incidente. La tentación natural es saltar directamente a Detección y Análisis: parece la parte «interesante». Pero en la práctica de campo, el factor que más determina si una investigación dura cuatro horas o cuatro semanas no es la habilidad del analista, sino qué telemetría existía ya cuando el atacante entró.
Esto no es una opinión metodológica: es aritmética. Un analista con Event ID 4688 con línea de comandos, Sysmon con event ID 1 y logons 4624/4625 correlacionables puede reconstruir una intrusión completa —vector inicial, movimiento lateral, persistencia, exfiltración— en horas. Sin esa telemetría depende de lo que quede en el disco: prefetch, MFT, registro, memoria si tuvo suerte de capturarla a tiempo. Es posible, pero órdenes de magnitud más lento y con huecos que nunca se rellenan porque el dato simplemente no se generó.
La consecuencia práctica: la inversión con mayor retorno en todo el programa de IR no es comprar más herramientas de análisis, es habilitar la auditoría correcta antes del incidente. Es barata (Windows y Sysmon no requieren licencia adicional), es predecible (defines de antemano qué vas a necesitar en vez de improvisar bajo presión) y convierte una investigación de «arqueología forense» en una de «consulta de logs».
2. Qué telemetría necesitas antes del incidente
Antes de entrar en comandos, conviene fijar el marco de qué preguntas debe poder responder tu telemetría cuando llegue el incidente. Como mínimo:
| Pregunta de investigación | Fuente de telemetría necesaria |
|---|---|
| ¿Quién inició sesión, dónde y cuándo (éxito y fallo)? | 4624, 4625, 4634, 4648, 4672 (Seguridad de Windows) |
| ¿Qué procesos se ejecutaron y con qué línea de comandos? | 4688 (Seguridad) + Sysmon event ID 1 |
| ¿Se estableció persistencia (tareas, servicios, cuentas)? | 4698, 7045, 4720/4726 (Seguridad) |
| ¿Hubo movimiento lateral vía recursos compartidos o SMB? | 5140, 5145 (Seguridad) |
| ¿Se ejecutó PowerShell ofuscado o malicioso? | 4103, 4104 (Microsoft-Windows-PowerShell/Operational) |
| ¿Hubo conexiones de red salientes sospechosas o C2? | Sysmon event ID 3 y 22 (DNS) |
| ¿Hubo inyección de código en otro proceso? | Sysmon event ID 8 (CreateRemoteThread) y 10 (ProcessAccess) |
| ¿Se modificaron claves de registro de autoarranque? | Sysmon event ID 12/13 |
| ¿Qué archivos se dejaron caer en el sistema? | Sysmon event ID 11 (FileCreate) |
Esta tabla es el índice del resto del módulo: cada fila corresponde a una fuente concreta que vamos a habilitar y verificar en el laboratorio.
3. Política de auditoría avanzada de Windows (auditpol)
Desde Windows Vista / Server 2008, Microsoft recomienda usar la Advanced Audit Policy Configuration en lugar de las nueve categorías «básicas» heredadas, porque permite granularidad por subcategoría. El requisito previo indispensable es forzar que la política avanzada tenga precedencia sobre la básica; si no lo haces, Windows puede ignorar tu configuración de subcategorías.
# Forzar que la política de subcategoría avanzada tenga precedencia
# sobre la política de categoría básica (requisito previo obligatorio)
auditpol /set /subcategory:"Registry" /success:enable
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v SCENoApplyLegacyAuditPolicy /t REG_DWORD /d 1 /f
Con eso resuelto, estas son las subcategorías mínimas para IR (todas se gestionan con auditpol /set /subcategory:"<nombre>" /success:enable /failure:enable, ajustando éxito/fallo según el caso):
# Logon / Logoff
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Special Logon" /success:enable
# Seguimiento detallado (necesario para 4688 con línea de comandos)
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Process Termination" /success:enable
# Cambios de política y gestión de cuentas
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
# Acceso a objetos: recursos compartidos de archivos
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable
# Sistema: creación de tareas programadas y cambios de servicio
auditpol /set /subcategory:"Other Object Access Events" /success:enable /failure:enable
# Verificar el estado actual de una categoría completa
auditpol /get /category:"Detailed Tracking"
auditpol /get /category:"Logon/Logoff"
# Exportar la configuración completa a CSV para documentarla en el runbook
auditpol /backup /file:C:IRauditpol-baseline.csv
Matiz crítico: habilitar "Process Creation" en auditpol te da el Event ID 4688, pero sin la línea de comandos salvo que actives además la directiva de grupo «Include command line in process creation events»:
# Habilitar el registro de línea de comandos en el 4688 (vía registro,
# equivalente a la GPO "Include command line in process creation events")
reg add "HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemAudit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
Tabla de referencia: Event ID de seguridad de Windows para IR
| Event ID | Qué registra | Por qué importa en IR |
|---|---|---|
| 4624 | Inicio de sesión correcto (incluye tipo de logon: 2 interactivo, 3 red/SMB, 10 RDP, etc.) | Establece presencia legítima o sospechosa de una cuenta en un host; el tipo de logon distingue acceso local de movimiento lateral vía red |
| 4625 | Inicio de sesión fallido | Indicador de fuerza bruta, password spraying o credenciales inválidas usadas por el atacante durante el reconocimiento |
| 4634 | Cierre de sesión (logoff) | Delimita la ventana temporal de una sesión, clave para acotar el alcance de la actividad de un usuario o atacante |
| 4648 | Intento de logon con credenciales explícitas (runas, «Ejecutar como») | Detecta uso de credenciales alternativas: típico en movimiento lateral y en el uso de cuentas de servicio robadas |
| 4672 | Se asignan privilegios especiales a un nuevo logon (cuenta con privilegios administrativos) | Marca sesiones con privilegios elevados; correlacionado con 4624 identifica escalada o abuso de cuentas admin |
| 4688 | Creación de un nuevo proceso (con línea de comandos si se activó la directiva) | El evento más denso en valor forense de todo Windows: reconstruye la cadena de ejecución completa de un ataque |
| 4698 | Se crea una tarea programada | Mecanismo de persistencia clásico; el atacante programa reejecución de su payload tras reinicio |
| 7045 | Se instala un nuevo servicio en el sistema (log System, no Security) | Otro vector de persistencia y de ejecución con privilegios SYSTEM; muy usado por ransomware y herramientas post-explotación |
| 4720 | Se crea una cuenta de usuario | Persistencia por creación de cuentas propias del atacante para mantener acceso aunque se roten credenciales |
| 4726 | Se elimina una cuenta de usuario | Puede indicar limpieza de huellas o sabotaje; también relevante en la fase de erradicación para verificar que no queden cuentas del atacante |
| 5140 | Se accede a un objeto de red compartido (file share) | Detecta acceso remoto a recursos compartidos administrativos (C$, ADMIN$) usados en movimiento lateral |
| 5145 | Se comprueba el acceso detallado a un objeto de recurso compartido | Nivel de detalle superior a 5140: qué archivo concreto dentro del share se intentó abrir y con qué permisos |
| 4103 | PowerShell Module Logging: registra la invocación de un pipeline con sus parámetros | Primera capa de visibilidad sobre uso de PowerShell, incluyendo cmdlets y parámetros usados |
| 4104 | PowerShell ScriptBlock Logging: registra el contenido completo del bloque de script ejecutado (incluye deofuscación automática) | Captura el código real ejecutado aunque esté ofuscado en superficie; esencial porque PowerShell es el vector post-explotación más común en Windows |
4. PowerShell logging: 4103 y 4104
PowerShell es, en la práctica de campo, el lenguaje de post-explotación más usado en entornos Windows: frameworks como Empire o Cobalt Strike, y un porcentaje enorme de scripts «living off the land», pasan por powershell.exe o pwsh.exe. Sin ScriptBlock Logging activo, esa actividad es prácticamente invisible salvo por el propio 4688 del proceso (sin contenido del script).
# Habilitar Module Logging (Event ID 4103) para todos los módulos
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /f
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLoggingModuleNames" /v "*" /t REG_SZ /d "*" /f
# Habilitar Script Block Logging (Event ID 4104) — el más importante de los dos
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f
# Habilitar también el registro de inicio/parada de invocación (4105/4106) como complemento
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging" /v EnableScriptBlockInvocationLogging /t REG_DWORD /d 1 /f
# Verificar que el log operativo de PowerShell está habilitado y recibiendo eventos
wevtutil gl "Microsoft-Windows-PowerShell/Operational"
wevtutil qe "Microsoft-Windows-PowerShell/Operational" /c:5 /rd:true /f:text
Estos eventos no viven en Security, sino en Applications and Services Logs > Microsoft > Windows > PowerShell > Operational. Es un error común olvidar este canal en la configuración de WEF/SIEM.
5. Sysmon: la telemetría que Windows no te da de fábrica
Sysmon (System Monitor), de Mark Russinovich y Thomas Garnier, forma parte de Sysinternals y es gratuito. Según la documentación oficial: «System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time.» A diferencia de la auditoría nativa, Sysmon añade contexto que Windows no registra: hashes de los binarios ejecutados, GUID de proceso persistente entre reinicios de PID, conexiones de red por proceso, carga de imágenes/DLL e inyección de hilos remotos.
Sysmon no viene preinstalado: hay que descargarlo de Sysinternals e instalarlo con una configuración XML. No se despliega «a pelo» (la configuración por defecto genera ruido y omite categorías clave como red); se despliega con un fichero curado. Las dos referencias más usadas en la comunidad son SwiftOnSecurity (bajo ruido, alta señal, buena para empezar) y Olaf Hartong (más agresiva, alineada con MITRE ATT&CK, para SOC maduros).
# Instalación con configuración de referencia (ejemplo: sysmonconfig.xml
# descargado del repositorio de SwiftOnSecurity u Olaf Hartong)
sysmon64 -accepteula -i sysmonconfig.xml
# Comprobar que el servicio y el driver están activos
sc query Sysmon64
Get-Service Sysmon64
# Volcar la configuración activa para documentarla en el runbook
sysmon64 -c
# Actualizar la configuración en caliente sin reinstalar (sin reinicio)
sysmon64 -c sysmonconfig-nuevo.xml
# Consultar los últimos eventos de Sysmon directamente
wevtutil qe "Microsoft-Windows-Sysmon/Operational" /c:10 /rd:true /f:text
# Desinstalar (solo en laboratorio, para limpieza)
sysmon64 -u
Los eventos de Sysmon se almacenan en Applications and Services Logs/Microsoft/Windows/Sysmon/Operational, no en el log System ni en Security. Este es otro punto de fallo común al configurar el reenvío de eventos.
Tabla de referencia: Event ID clave de Sysmon
| Event ID | Nombre | Qué aporta en IR |
|---|---|---|
| 1 | Process creation | Igual que 4688 pero con hash del binario (SHA1/MD5/SHA256/IMPHASH), ProcessGuid persistente y jerarquía padre-hijo más fiable |
| 3 | Network connection | Conexión TCP/UDP por proceso: IP/puerto origen y destino — clave para identificar C2 o exfiltración; desactivado por defecto, hay que habilitarlo en la config |
| 7 | Image loaded | Carga de DLL en un proceso, con firma y hash; detecta DLL sideloading e inyección de librerías maliciosas |
| 8 | CreateRemoteThread | Un proceso crea un hilo en otro proceso — técnica clásica de inyección de código usada por malware para camuflarse |
| 11 | FileCreate | Creación o sobrescritura de archivos; útil para vigilar carpetas de arranque, temporales y de descargas donde cae el malware inicial |
| 12/13 | RegistryEvent (creación/eliminación de objeto / valor establecido) | Cambios en claves de autoarranque del registro — persistencia muy usada por malware de puesta en marcha |
| 22 | DNSEvent (DNS query) | Consulta DNS por proceso, éxito o fallo; permite detectar dominios de C2 y algoritmos de generación de dominios (DGA) — no disponible en Windows 7 o anterior |
Sysmon también genera el event ID 10 (ProcessAccess, relevante para detectar volcado de credenciales de LSASS) y el 15 (FileCreateStreamHash, útil para identificar descargas marcadas con «Zone.Identifier»), que conviene tener presentes aunque no formen parte del núcleo mínimo de este módulo.
6. Centralización: Windows Event Forwarding (WEF) y SIEM
Toda la telemetría anterior es inútil si vive solo en el disco local del endpoint: un atacante con privilegios de administrador puede limpiar el Visor de Eventos en segundos (wevtutil cl Security) o el ransomware puede cifrar el disco antes de que nadie mire el log. La telemetría de valor para IR tiene que salir del host en tiempo casi real hacia un repositorio centralizado que el atacante no controle.
Windows Event Forwarding (WEF) es el mecanismo nativo de Windows para esto: un modelo subscription-based donde un servidor colector (Windows Event Collector, WEC) se suscribe a los logs de los endpoints origen usando WinRM. No requiere agente de terceros ni licencias adicionales, aunque tiene limitaciones de escalabilidad frente a otras soluciones (agentes de SIEM comerciales, Winlogbeat, NXLog).
# En el servidor colector (WEC): habilitar el servicio de Windows Event Collector
wecutil qc /q
# En cada endpoint origen: habilitar el listener de WinRM para que el WEC pueda suscribirse
winrm quickconfig -q
# En el WEC: crear una suscripción de tipo "source-initiated" a partir de un
# fichero XML de suscripción (define qué canales recoger: Security, Sysmon, PowerShell...)
wecutil cs suscripcion-dfir.xml
# Verificar el estado de la suscripción y cuántos endpoints están reportando
wecutil gr "SuscripcionDFIR"
wecutil rs "SuscripcionDFIR"
# Consultar el log agregado ForwardedEvents en el propio colector
wevtutil qe ForwardedEvents /c:10 /rd:true /f:text
A partir de WEF (o directamente desde los endpoints), el siguiente salto es la ingesta en un SIEM (Splunk, Microsoft Sentinel, Elastic Security, QRadar, Wazuh…) que aporta lo que ni Windows ni Sysmon dan por sí solos: correlación entre fuentes y hosts, reglas de detección, alertado, dashboards y retención centralizada más allá de la capacidad de disco de un endpoint. El log local de Windows tiene un tamaño máximo que hace rotar eventos antiguos; sin exportación a un SIEM, esa telemetría se pierde en cuestión de días u horas en sistemas con mucha actividad.
7. El papel del EDR
Conviene ser precisos sobre qué aporta un EDR (Endpoint Detection and Response — CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Elastic Defend, etc.) que Sysmon y la auditoría nativa no dan, porque a veces se presentan como sustitutos y no lo son del todo:
- Telemetría en kernel más profunda: visibilidad de llamadas a API, comportamiento en memoria y técnicas de evasión que Sysmon no captura con el mismo detalle.
- Capacidad de respuesta activa: aislamiento de host, terminación de proceso remoto, cuarentena de archivos — Sysmon es puramente pasivo, solo registra.
- Motor de detección propio con inteligencia de amenazas actualizada: reglas y modelos de comportamiento del vendor, actualizados con IOC e IOA de campañas reales.
- Retención y búsqueda gestionadas: consola propia de búsqueda retrospectiva (threat hunting) sin depender de que hayas configurado bien el pipeline de reenvío.
Lo que Sysmon y la auditoría avanzada de Windows aportan que un EDR por sí solo no siempre garantiza: transparencia total del dato (sin caja negra del vendor), coste (Sysmon es gratuito) y portabilidad (útiles aunque cambies de proveedor de EDR). La postura de este módulo es que ambas capas son complementarias, no sustitutivas: un EDR sin auditoría de Windows habilitada pierde contexto de logon/cuentas; una auditoría exhaustiva sin EDR carece de capacidad de respuesta activa.
8. Retención de logs
La pregunta «¿cuánto tiempo guardo los logs?» no tiene una respuesta única: depende del marco regulatorio aplicable, del apetito de riesgo de la organización y de la capacidad del SIEM. Como referencia de partida orientativa —no como norma fija—:
- Logs de seguridad de Windows y Sysmon en el endpoint local: al menos 30 días, limitado por el tamaño máximo configurado del log (revisar y aumentar con
wevtutil sl Security /ms:<bytes>). - Logs centralizados en el SIEM (índice «caliente»): entre 90 días y 1 año es habitual en organizaciones maduras, para cubrir el tiempo medio de permanencia de un atacante (dwell time) antes de ser detectado.
- Archivo en frío: 1 a 7 años según sector regulado (PCI-DSS exige un mínimo de 1 año con 3 meses inmediatamente disponibles).
# Aumentar el tamaño máximo del log de Seguridad local (ejemplo: 1 GB)
wevtutil sl Security /ms:1073741824
# Comprobar el tamaño máximo y la política de retención configurada
wevtutil gl Security
La retención local (endpoint) y la centralizada (SIEM/archivo) son decisiones independientes: el endpoint solo necesita sobrevivir hasta el siguiente ciclo de recolección del pipeline de reenvío; la retención «real» a efectos de investigación y cumplimiento vive en el sistema centralizado.
9. Playbooks y runbooks
Un playbook (o runbook) es un documento operativo, versionado, que describe paso a paso cómo actuar ante un tipo concreto de incidente: qué consultas lanzar, qué IOC/IOA buscar, qué decisiones de contención tomar y en qué orden, y quién debe ser notificado. Sin playbook, cada analista improvisa bajo estrés; con playbook, la respuesta es reproducible, delegable a analistas junior y auditable después.
Un playbook mínimo para «sospecha de ransomware» incluye al menos: (1) las consultas exactas de Sysmon/Security/PowerShell para confirmar o descartar; (2) el criterio para aislar el host (¿automático vía EDR o requiere aprobación humana?); (3) el orden de contención en la red; (4) a quién escalar y con qué SLA; (5) qué evidencia preservar. Todo esto se prepara antes del incidente, porque escribirlo durante el incidente ya es tarde.
10. Documentación y cadena de custodia
Toda evidencia recolectada —exportaciones de logs, capturas de memoria, imágenes de disco, capturas de pantalla— debe quedar documentada con una cadena de custodia clara: quién la recolectó, cuándo (idealmente en UTC), de qué sistema, con qué herramienta y versión, y el hash criptográfico del artefacto en el momento de la recolección. Esto determina si esa evidencia puede sostenerse después en un proceso disciplinario, un peritaje o un procedimiento judicial.
# Exportar un log completo preservando el formato nativo .evtx
wevtutil epl Security C:IRCASO-2026-014Security_HOST01_20260701.evtx
# Calcular el hash del artefacto exportado inmediatamente después de la exportación
Get-FileHash -Algorithm SHA256 C:IRCASO-2026-014Security_HOST01_20260701.evtx
# Registrar el evento de exportación en el propio log de auditoría (trazabilidad)
Get-Date -Format "yyyy-MM-dd HH:mm:ss UTC" -AsUTC
Norma práctica: cada artefacto exportado debe ir acompañado, desde el minuto uno, de una entrada en el registro de cadena de custodia con el hash calculado en el momento de la recolección; sin ese hash inicial, no hay forma posterior de demostrar que no fue alterado antes de analizarlo.
11. Laboratorio: habilitar auditoría y Sysmon en la VM Windows y verificar
Asume la VM Windows de prácticas del curso, con acceso administrativo local y sin conexión a producción.
- Habilitar la política de auditoría avanzada mínima. Ejecuta en una consola elevada (cmd o PowerShell «Run as Administrator»):
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v SCENoApplyLegacyAuditPolicy /t REG_DWORD /d 1 /f auditpol /set /subcategory:"Logon" /success:enable /failure:enable auditpol /set /subcategory:"Process Creation" /success:enable reg add "HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemAudit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable auditpol /set /subcategory:"File Share" /success:enable /failure:enable - Habilitar PowerShell ScriptBlock Logging.
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f - Descargar e instalar Sysmon con una configuración de referencia (descarga
Sysmon.zipde Sysinternals y unsysmonconfig.xmldel repositorio público de SwiftOnSecurity):sysmon64 -accepteula -i sysmonconfig.xml Get-Service Sysmon64 - Generar actividad de prueba. Abre una consola y ejecuta un par de comandos sencillos y un logon de prueba (por ejemplo, con
runashacia una cuenta local distinta), para tener eventos frescos que buscar:whoami /all runas /user:LabUser cmd.exe Invoke-Expression "Get-Process | Select-Object -First 3" - Verificar que el 4688 llega con línea de comandos:
wevtutil qe Security /q:"*[System[(EventID=4688)]]" /c:5 /rd:true /f:textConfirma en la salida que el campo
Process Command Lineno aparece vacío. - Verificar que Sysmon está generando el event ID 1 (process creation):
wevtutil qe "Microsoft-Windows-Sysmon/Operational" /q:"*[System[(EventID=1)]]" /c:5 /rd:true /f:text - Verificar el 4104 de PowerShell (debería mostrar el contenido del
Invoke-Expressiondel paso 4):wevtutil qe "Microsoft-Windows-PowerShell/Operational" /q:"*[System[(EventID=4104)]]" /c:3 /rd:true /f:text - Verificar el 4624 del logon de prueba con
runas:wevtutil qe Security /q:"*[System[(EventID=4624)]]" /c:5 /rd:true /f:text
Si todos los pasos devuelven eventos con los campos esperados (línea de comandos en 4688, hash en el event ID 1 de Sysmon, contenido del script en 4104), la telemetría base de Preparación funciona. Documenta el resultado de cada consulta como evidencia del laboratorio.
12. Errores comunes
- Habilitar «Process Creation» y asumir que el 4688 ya trae la línea de comandos. Sin la directiva
ProcessCreationIncludeCmdLine_Enabledel 4688 se genera con el campo de línea de comandos vacío, lo que anula gran parte de su valor forense. - No habilitar el PowerShell logging hasta después del incidente. El 4103/4104 no son retroactivos: si no estaban activos cuando el atacante ejecutó su script, ese contenido no existe en ningún sitio.
- Instalar Sysmon con la configuración por defecto (sin XML curado). Sin fichero de configuración, Sysmon no audita conexiones de red (event ID 3, deshabilitado por defecto) ni carga de imágenes (event ID 7), dos de los eventos más valiosos para detección.
- Confundir el log
Systemcon el canal operativo de Sysmon o de PowerShell. Cada uno vive en su propia ruta; si el pipeline de WEF/SIEM solo recogeSecurityySystem, esos canales quedan huérfanos. - No aumentar el tamaño máximo del log de Seguridad. Con el tamaño por defecto, en un host con actividad alta el log puede rotar y sobrescribir eventos críticos en horas.
- Dar por sentado que un EDR ya cubre todo esto. Un EDR aporta detección y respuesta, pero no siempre retiene con el mismo detalle el histórico de auditoría nativa que necesitarás para una reconstrucción exhaustiva.
- No documentar la línea base de auditoría. Sin un
auditpol /backupguardado como referencia, no hay forma rápida de verificar si alguien alteró la configuración de auditoría antes o durante el incidente.
13. Ejercicio
Sobre tu VM Windows de laboratorio: (1) habilita las subcategorías de auditoría avanzada de la sección 3 y el ProcessCreationIncludeCmdLine_Enabled; (2) instala Sysmon con la configuración de SwiftOnSecurity; (3) habilita el 4103/4104 de PowerShell; (4) simula una cadena de actividad sospechosa: crea una tarea programada con schtasks /create, instala un servicio de prueba con sc create, y ejecuta un Invoke-WebRequest hacia una URL de prueba; (5) localiza con wevtutil los Event ID 4698 (tarea), 7045 (servicio), Sysmon 1 (proceso) y Sysmon 3 (red, si aplica); (6) exporta esos cuatro eventos a un .evtx y calcula su hash SHA-256, simulando el primer paso de una cadena de custodia. Entrega la lista de comandos usados y las exportaciones de los cuatro eventos localizados.
Preguntas frecuentes
¿Necesito Sysmon si ya tengo un EDR desplegado?
En la mayoría de organizaciones maduras, sí conviene mantener ambos. El EDR aporta detección activa y respuesta; Sysmon aporta un registro transparente, gratuito y portable que no depende de la caja negra del vendor y sigue siendo tuyo si cambias de proveedor.
¿Por qué el Event ID 4688 no muestra la línea de comandos aunque tengo «Process Creation» auditado?
Porque auditar la subcategoría «Process Creation» solo activa la generación del evento; el contenido de la línea de comandos requiere además la directiva ProcessCreationIncludeCmdLine_Enabled. Son dos interruptores distintos y hay que activar los dos.
¿Qué configuración de Sysmon debería usar para empezar: SwiftOnSecurity u Olaf Hartong?
Para un equipo que empieza, la de SwiftOnSecurity suele recomendarse por su relación señal/ruido más manejable. La de Olaf Hartong está más orientada a SOC con mayor volumen y mapeo explícito a MITRE ATT&CK. Ninguna configuración de terceros debe desplegarse sin revisarla antes.
¿Cuánto tiempo tarda en notarse el «coste» de no haber hecho esta preparación?
Se nota en el primer incidente serio: la fase de Detección y Análisis se alarga porque el analista reconstruye con artefactos de disco lo que un log habría dado en segundos, y ciertas preguntas (¿qué línea de comandos se ejecutó?, ¿qué contenía ese script?) quedan sin respuesta porque el dato nunca se generó.
¿Es obligatorio Windows Event Forwarding o puedo usar directamente un agente de SIEM?
No es obligatorio. WEF es la opción nativa sin coste de licencia adicional, pero muchas organizaciones optan por un agente de terceros (Winlogbeat, NXLog, el agente propio del SIEM) por mayor resiliencia o facilidad de gestión a escala. Depende del tamaño del entorno y del presupuesto, no de un requisito técnico estricto.
«System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time.» — Microsoft Learn / Sysinternals — Sysmon