Sysmon: qué es, cómo instalarlo y qué eventos analizar en Blue Team

Un usuario abre Word.

Word inicia PowerShell.

PowerShell realiza una consulta DNS.

Segundos después establece una conexión hacia una dirección externa y crea un archivo en una carpeta temporal.

Windows puede registrar partes de esa actividad.

Sysmon puede ayudarnos a conectarlas con mucho más contexto.

Por ejemplo:

Eso es lo interesante de Sysmon.

No convierte automáticamente una actividad en maliciosa.

No reemplaza al analista.

Y tampoco es un antivirus.

Su valor está en otra parte: proporcionar telemetría suficientemente detallada para reconstruir qué ocurrió dentro de un endpoint Windows.

Para Blue Team y SOC, esa diferencia es enorme.

1. Qué es Sysmon y para qué sirve #

Sysmon, abreviatura de System Monitor, es una herramienta desarrollada por Microsoft (creada originalmente por Mark Russinovich y Thomas Garnier dentro de la suite Sysinternals) que registra determinados tipos de actividad técnica del sistema y escribe esa información estructurada dentro del visor de eventos de Windows.

A diferencia de la auditoría tradicional, Sysmon fue concebido específicamente para dar respuesta a necesidades de ciberseguridad defensiva, monitorizando:

• Creación de procesos: con línea de comandos completa, directorio de trabajo y hashes criptográficos (SHA256, MD5, IMPHASH).
• Relaciones de linaje: proceso padre, línea de comandos del padre e identificadores únicos temporales.
• Comunicaciones de red: sockets TCP y UDP asociados al binario responsable, indicando IP origen, IP destino, puertos y nombres de equipo.
• Consultas DNS: dominios solicitados por procesos concretos, códigos de retorno y direcciones IP resultantes.
• Ciclo de vida de archivos: creación, sobrescritura y eliminación segura de ficheros en el disco duro.
• Modificaciones del Registro: creación y borrado de claves, modificación de valores y renombrado de entradas.
• Técnicas en memoria y evasión: inyección de hilos (CreateRemoteThread), acceso a memoria de otros procesos (ProcessAccess), carga de controladores y manipulación de ejecutables (Process Tampering / Process Hollowing).

Sin embargo, hay algo que debemos dejar claro desde el principio:

Principio fundamental: Sysmon no decide por nosotros si algo es un ataque. Es una fuente de telemetría pura: no bloquea procesos, no analiza malicia en tiempo real y no crea alertas por sí solo.

La cadena operativa de defensa divide claramente sus responsabilidades:

Confundir esas tres capas es una de las razones por las que alguien puede instalar Sysmon, saturar sus servidores con millones de eventos diarios y seguir sin disponer de una capacidad real de detección de amenazas.

2. Sysmon vs. Windows Event Logs: capas complementarias #

Al estudiar las fuentes defensivas de un entorno corporativo vimos eventos nativos fundamentales de auditoría:

• 4624 → Inicio de sesión correcto.
• 4625 → Inicio de sesión fallido.
• 4688 → Creación de proceso nativa de Windows.
• 4720 → Creación de cuenta de usuario.
• 1102 → Registro de seguridad limpiado intencionadamente.

Esos eventos pertenecen a la auditoría nativa de Windows (canal Security). Sysmon añade otra capa de observabilidad en el endpoint.

Por ejemplo, Windows Event Logs nos ayuda a determinar:

Una cuenta inició sesión mediante Escritorio Remoto (Event ID 4624, Logon Type 10)

Y Sysmon nos permite observar con precisión quirúrgica qué ocurrió inmediatamente después:

Qué procesos se ejecutaron (Event 1)
Qué dominios externos consultaron (Event 22)
Qué conexiones TCP establecieron (Event 3)
Qué binarios temporales crearon (Event 11)
Qué claves de autoarranque modificaron en el Registro (Event 13)

No son herramientas rivales. Se complementan de manera natural en cualquier investigación forense o de triaje defensivo:

Ahora dejamos de analizar eventos aislados. Tenemos una cadena de comportamiento continua.

3. Process Create: la información que enriquece un proceso #

Uno de los ejemplos más claros del valor añadido de Sysmon se manifiesta al comparar la creación nativa de procesos con el Event ID 1 (Process Create) de Sysmon.

Un evento de proceso generado por Sysmon incluye de manera estructurada campos como:

• UtcTime: Marca de tiempo exacta normalizada en UTC.
• ProcessGuid: Identificador universal único del proceso.
• ProcessId: PID numérico asignado por el sistema operativo en ese momento.
• Image: Ruta completa del ejecutable en el sistema de ficheros.
• CommandLine: Parámetros y argumentos exactos pasados al proceso al iniciar.
• CurrentDirectory: Directorio de trabajo en el que se lanzó el ejecutable.
• User: Cuenta de usuario y dominio bajo cuyo token corre el proceso.
• Hashes: Resúmenes criptográficos calculados en el instante de carga (MD5, SHA256, IMPHASH).
• ParentProcessGuid: Identificador universal único del proceso padre.
• ParentProcessId: PID del proceso que ordenó la creación.
• ParentImage: Ruta completa del proceso padre.
• ParentCommandLine: Línea de comandos exacta ejecutada por el proceso padre.

Esta densidad de información permite responder de inmediato preguntas analíticas complejas:

• ¿Se ejecutó PowerShell? Sí.
• ¿Quién lo ejecutó? EMPRESA\mlopez.
• ¿Qué proceso lo invocó directamente? WINWORD.EXE (un documento de Word).
• ¿Con qué parámetros? -NoProfile -ExecutionPolicy Bypass -EncodedCommand ...
• ¿Qué hash exacto tenía el binario ejecutado para verificar si fue reemplazado? SHA256=a8f5c...
• ¿Qué ocurrió después con ese mismo proceso a lo largo del tiempo? Lo sabemos siguiendo su ProcessGuid.

4. ProcessId vs. ProcessGuid: el valor de la unicidad #

Windows asigna tradicionalmente a cada proceso un número identificador denominado Process ID (PID):

ProcessId: 5184

El problema metodológico para una investigación de seguridad radica en que los PIDs se reutilizan de manera constante. Un ejecutable malicioso puede iniciarse, ejecutar un comando durante tres segundos, terminar su ejecución y liberar el PID 5184. Minutos después, un proceso legítimo del sistema (como svchost.exe o una actualización de Microsoft Edge) puede recibir ese mismo PID 5184.

Si intentamos correlacionar eventos transcurridos a lo largo de varias horas únicamente mediante el PID, corremos el riesgo de mezclar la actividad de dos programas completamente distintos.

Para solucionar esta limitación estructural, Sysmon genera un ProcessGuid:

ProcessGuid: {A23F184B-91C0-6523-0000-001034567800}

Este identificador alfanumérico combina la máquina, el momento exacto de creación del proceso y metadatos únicos para garantizar que sea imposible la colisión entre dos ejecuciones. Microsoft señala formalmente en su documentación que ProcessGuid está concebido de manera prioritaria para facilitar la correlación analítica entre eventos dispares:

Event ID 1  (Process Create)    → ProcessGuid: {A23F...} (powershell.exe nace)
Event ID 22 (DNS Query)         → ProcessGuid: {A23F...} (powershell.exe consulta dominio)
Event ID 3  (Network Connect)   → ProcessGuid: {A23F...} (powershell.exe abre socket TCP)
Event ID 11 (File Create)       → ProcessGuid: {A23F...} (powershell.exe escribe en disco)

Gracias al ProcessGuid podemos enlazar la cadena forense sin temer a la rotación de PIDs del sistema operativo.

5. Dónde se guardan los eventos: canal Operational #

A diferencia de los eventos de auditoría que se ubican en el canal tradicional Security, en las versiones actuales de Windows Sysmon almacena todos sus registros en un canal dedicado bajo la jerarquía de aplicaciones y servicios:

Applications and Services Logs
└── Microsoft
    └── Windows
        └── Sysmon
            └── Operational

Podemos consultar este canal abriendo gráficamente el Visor de eventos:

eventvwr.msc

Y navegando hasta la ruta mencionada. Para entornos de triaje rápido, extracción remota o automatización defensiva, es sumamente práctico consultarlo mediante PowerShell:

# Obtener los últimos 20 eventos generados por Sysmon
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 20

# Filtrar únicamente los eventos de creación de proceso (Event ID 1)
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1
} -MaxEvents 10

6. Sysinternals standalone vs. Sysmon integrado en Windows #

Este es un punto fundamental que suele omitirse en manuales antiguos. En la actualidad coexisten dos modalidades de Sysmon documentadas formalmente por Microsoft:

1. Sysmon independiente de Sysinternals (Standalone): Es el binario clásico descargable (sysmon.exe / sysmon64.exe) compatible con la práctica totalidad de ediciones de Windows cliente y servidor.
2. Sysmon integrado en Windows (Built-in Sysmon): Una característica nativa del sistema operativo introducida en versiones modernas de Windows (Windows 11 / Windows Server) que permite habilitar el servicio de monitorización directamente como componente del sistema.

Advertencia crítica de Microsoft: El Sysmon integrado en Windows no está diseñado para coexistir ni ejecutarse de manera simultánea con una instalación independiente de Sysmon de Sysinternals en el mismo equipo. Ejecutar ambos controladores puede provocar colisiones y degradación de rendimiento.

Por este motivo, antes de desplegar cualquier software en una máquina corporativa o de laboratorio, comprueba qué servicios existen en el sistema:

Get-Service -Name "sysmon*"

Verifica siempre la versión y el canal antes de proceder con la instalación.

7. Instalación y configuración en un entorno de pruebas #

Para construir un entorno de prácticas defensivo recomendamos utilizar la versión independiente de Microsoft Sysinternals. Tras descargar el paquete oficial y abrir una ventana de terminal o PowerShell con privilegios elevados de Administrador, la sintaxis estándar de instalación es:

# Instalación básica aceptando el acuerdo de licencia (EULA)
sysmon64.exe -accepteula -i

En sistemas de 32 bits o distribuciones unificadas el ejecutable puede denominarse simplemente sysmon.exe.

La instalación predeterminada sin archivo XML activa únicamente un conjunto básico de eventos. En un entorno profesional o de laboratorio avanzado, el verdadero potencial de Sysmon se desbloquea al suministrar un archivo de configuración XML:

# Instalar Sysmon cargando un archivo de configuración
sysmon64.exe -accepteula -i C:\Sysmon\sysmonconfig.xml

# Actualizar la configuración activa de un Sysmon ya instalado (sin reiniciar el equipo)
sysmon64.exe -c C:\Sysmon\sysmonconfig.xml

# Volcar por pantalla la configuración actualmente aplicada en el sistema
sysmon64.exe -c

# Desinstalar el servicio y el controlador del sistema
sysmon64.exe -u

Microsoft documenta explícitamente que los cambios de configuración se aplican de manera dinámica en memoria sin requerir reinicio del sistema operativo.

8. Estructura XML: reglas include y exclude sin puntos ciegos #

El comportamiento de Sysmon está gobernado por directivas XML estructuradas. Un archivo de configuración esquemático presenta la siguiente arquitectura conceptual:

<Sysmon schemaversion="4.90">
  <!-- Algoritmos de hash a calcular para los ejecutables -->
  <HashAlgorithms>SHA256,MD5,IMPHASH</HashAlgorithms>
  <CheckRevocation/>

  <!-- Filtrado granular de eventos por tipo -->
  <EventFiltering>

    <!-- Registrar creación de procesos excluyendo ruido del sistema -->
    <ProcessCreate onmatch="exclude">
      <Image condition="is">C:\Windows\System32\conhost.exe</Image>
    </ProcessCreate>

    <!-- Registrar conexiones de red incluyendo puertos y ejecutables clave -->
    <NetworkConnect onmatch="include">
      <Image condition="image">powershell.exe</Image>
      <DestinationPort condition="is">443</DestinationPort>
    </NetworkConnect>

    <!-- Registrar consultas DNS -->
    <DnsQuery onmatch="exclude">
      <QueryName condition="end with">.local</QueryName>
    </DnsQuery>

  </EventFiltering>
</Sysmon>

El motor de filtrado opera según dos estrategias antagónicas:

• onmatch="include": Modo lista blanca estricta. Sysmon ignora todo excepto la actividad que coincida de forma exacta con las reglas declaradas. Ahorra espacio, pero puede provocar puntos ciegos si los atacantes usan técnicas no contempladas.
• onmatch="exclude": Modo lista negra de ruido. Sysmon registra absolutamente todo excepto la actividad benigna y altamente predecible explícitamente descartada. Es el enfoque defensivo recomendado, aunque requiere calibración continua para evitar saturar el sistema.

El peligro de las exclusiones ciegas: Si para reducir volumen decides excluir toda la ruta C:\Windows\System32\*, crearás un agujero crítico en tu visibilidad: los atacantes que abusen de binarios legítimos de Windows (LOLBins como certutil.exe, bitsadmin.exe, mshta.exe o wmic.exe) operarán sin dejar rastro en Sysmon.

9. Más telemetría no significa mejor detección: gestión del ruido #

Un error clásico al descubrir Sysmon es asumir que el éxito defensivo consiste en capturar cada byte generado por la máquina. Supongamos que una estación de trabajo genera 200.000 eventos diarios y decides enviarlos íntegramente al SIEM central.

Esa decisión no mejora por sí sola la capacidad de detección. Lo que suele producir en la práctica es:

• Incremento desproporcionado de costes de ingestión y licencias en el SIEM.
• Consultas analíticas notablemente más lentas.
• Saturación de almacenamiento en los discos del servidor central.
• Fatiga de alertas y dificultad para aislar la señal real en medio del ruido.

El objetivo de un analista de seguridad no es registrar absolutamente todo lo que ocurre, sino disponer de suficiente evidencia contextual para responder preguntas forenses relevantes.

10. Matriz de Event IDs esenciales para el analista SOC #

La especificación técnica actual de Sysmon incluye identificadores hasta el Event ID 29, además del 255 para incidencias internas del controlador. Para iniciar una carrera en SOC o Blue Team, esta matriz condensa los eventos indispensables:

11. Análisis detallado de eventos clave (1, 3, 22, 11, 10, 12–14) #

Event ID 1: Creación de procesos y linaje jerárquico

Si sólo pudieras monitorear un único evento en todo Sysmon, la elección obligada es el Event ID 1. Registra la creación de procesos aportando hashes criptográficos de la imagen, la línea de comandos completa y el identificador ProcessGuid.

Consideremos este fragmento de log:

Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -ExecutionPolicy Bypass -NoProfile -enc SQBFAFgA...
User: EMPRESA\mlopez
ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
ParentProcessGuid: {D250109C-6B1A-6523-0000-001002341200}
ProcessGuid: {D250109C-6B40-6523-0000-001003451200}

El valor no radica en que PowerShell sea intrínsecamente malicioso (los administradores de sistemas lo utilizan a diario). El valor radica en el árbol de linaje: un procesador de textos como Microsoft Word jamás debería invocar de forma natural un intérprete de PowerShell ejecutando comandos codificados en Base64.

Analizar procesos en un árbol jerárquico (Process Tree) es infinitamente superior a inspeccionar listas planas de binarios:

explorer.exe
 └── WINWORD.EXE
      └── powershell.exe
           └── cmd.exe
                └── whoami.exe

Para formalizar este patrón en firmas portables e independientes de la plataforma SIEM, puedes aprender a crear reglas Sigma a partir de esta telemetría estructurando selecciones sobre ParentImage e Image.

Event ID 3: Conexiones de red con atribución a binarios

Los cortafuegos de red tradicionales observan el tráfico a nivel perimetral:

10.10.20.15:52140 → 203.0.113.70:443 (TCP permitido)

Sin embargo, el firewall no sabe qué proceso interno de la máquina generó esa conexión. Sysmon Event ID 3 aporta exactamente esa pieza:

ProcessGuid: {D250109C-6B40-6523-0000-001003451200}
Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Protocol: tcp
Initiated: true
SourceIp: 10.10.20.15
DestinationIp: 203.0.113.70
DestinationPort: 443

Nota operativa crítica: Microsoft documenta formalmente que el Event ID 3 no viene habilitado por defecto en la configuración básica de Sysmon. Si no se incluye una directiva NetworkConnect en el XML, el evento no se emitirá. Ver cero eventos de red no implica ausencia de conexiones, sino ausencia de captura.

Event ID 22: Consultas DNS

Introducido en versiones recientes de Sysmon, el Event ID 22 captura la resolución de nombres DNS efectuada por los procesos del host. Aporta el nombre solicitado (QueryName), el resultado devuelto (QueryResults) y el código de estado, independientemente de si la consulta tuvo éxito o fue denegada:

ProcessGuid: {D250109C-6B40-6523-0000-001003451200}
Image: powershell.exe
QueryName: cdn-update-example.test
QueryResults: ::ffff:203.0.113.70;

Al unir Event 1 + Event 22 + Event 3 conseguimos la correlación completa: el proceso nació, resolvió el dominio y abrió la sesión hacia la IP resuelta.

Event ID 11: Creación de archivos en disco

Registra cuando un archivo es creado o sobreescrito en el sistema. En investigaciones defensivas es indispensable para monitorizar directorios típicamente abusados para ejecución no autorizada y persistencia:

• C:\Users\<Usuario>\AppData\Local\Temp\
• C:\Users\<Usuario>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
• C:\Windows\System32\Tasks\

Event ID 10: Process Access y acceso a memoria

Este evento audita cuando un proceso abre los descriptores de otro para inspeccionar su espacio de memoria mediante llamadas al sistema como OpenProcess. Es habitual investigarlo ante sospechas de volcado de credenciales (credential dumping) sobre el proceso del subsistema de autenticación de Windows:

SourceImage: C:\Users\mlopez\AppData\Local\Temp\procdump.exe
TargetImage: C:\Windows\System32\lsass.exe
GrantedAccess: 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_INFORMATION)

Criterio analítico: Software completamente benigno (antivirus corporativos, motores de diagnóstico y depuradores) también solicita accesos legítimos a otros procesos. El Event ID 10 no es sinónimo automático de ataque; requiere comprobar la reputación del binario origen y los privilegios solicitados (GrantedAccess).

Event ID 12, 13 y 14: Modificaciones del Registro

Sysmon segmenta las acciones sobre la base de datos de configuración de Windows:

• Event ID 12: Creación o eliminación de claves y objetos.
• Event ID 13: Asignación y cambio de valores (Registry value set).
• Event ID 14: Renombrado de claves y valores.

Windows y las aplicaciones normales modifican miles de entradas de registro por minuto. Alertar ante cualquier Event ID 13 inundará el SOC. El analista debe centrar sus reglas en ubicaciones estratégicas de persistencia técnica: claves CurrentVersion\Run, servicios en System\CurrentControlSet\Services o secuencias de inicio de sesión de Winlogon.

12. Eventos avanzados: 7, 8, 16, 19–21, 23/26 y 25 #

Una vez dominados los eventos troncales, estas categorías resuelven técnicas forenses más específicas:

• Event ID 7 (Image Load): Monitoriza la carga de librerías dinámicas DLL. Es vital para detectar ataques de DLL Sideloading o inyección de módulos, pero genera un volumen masivo de datos si no se filtra rigurosamente.
• Event ID 8 (CreateRemoteThread): Se dispara cuando un proceso genera un hilo de ejecución en el espacio virtual de otro proceso distinto. Es una técnica habitual de inyección de código utilizada para ocultar actividad bajo procesos legítimos como svchost.exe o explorer.exe.
• Event ID 16 (Sysmon Config Change): Registra alteraciones en las directivas activas de Sysmon. Un atacante con privilegios que modifique el archivo de configuración para excluir sus propios ejecutables dejará constancia en este evento.
• Event ID 19, 20 y 21 (WMI Persistence): Auditan la creación de filtros WMI (19), consumidores de eventos (20) y enlaces de vinculación (21). Es la telemetría idónea para detectar persistencia basada en scripts sin archivos en disco (fileless malware).
• Event ID 23 vs. 26 (File Delete): El Event ID 23 guarda una copia forense del archivo borrado dentro de la carpeta configurada en ArchiveDirectory (útil para recuperar artefactos eliminados por atacantes, pero de alto consumo en disco), mientras que el Event ID 26 audita la eliminación sin archivar el archivo.
• Event ID 25 (Process Tampering): Diseñado por Microsoft para detectar manipulación del contenido ejecutable de un proceso en memoria (como process hollowing o process herpaderping).

13. Caso práctico: documento → PowerShell → DNS → red → archivo #

Analicemos un incidente forense real registrado en un equipo de trabajo corporativo a las 09:31 de la mañana. En lugar de evaluar eventos sueltos, reconstruyamos la secuencia cronológica exacta mediante los campos de Sysmon:

1. 09:31:14 — Event ID 1 (Apertura del documento)

Image: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
CommandLine: "WINWORD.EXE" "C:\Users\mlopez\Downloads\Factura_Pendiente.docx"
ProcessGuid: {AAA-11111111-2222-3333-4444-555555555555}
User: EMPRESA\mlopez

El usuario abrió un archivo ofimático descargado de Internet.

2. 09:31:48 — Event ID 1 (Invocación anómala de PowerShell)

Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Command ...
ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
ParentProcessGuid: {AAA-11111111-2222-3333-4444-555555555555}
ProcessGuid: {BBB-22222222-3333-4444-5555-666666666666}

El proceso hijo powershell.exe nace directamente de Microsoft Word con identificador {BBB-222...}.

3. 09:31:51 — Event ID 22 (Consulta de infraestructura externa)

ProcessGuid: {BBB-22222222-3333-4444-5555-666666666666}
Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
QueryName: cdn-update-example.test
QueryResults: 203.0.113.70;

Ese mismo proceso consulta un dominio externo mediante DNS.

4. 09:31:52 — Event ID 3 (Establecimiento de canal TCP)

ProcessGuid: {BBB-22222222-3333-4444-5555-666666666666}
DestinationIp: 203.0.113.70
DestinationPort: 443
Protocol: tcp

Un segundo después, el socket se conecta a la dirección IP obtenida en la consulta DNS anterior.

5. 09:31:55 — Event ID 11 (Descarga y escritura de binario ejecutable)

ProcessGuid: {BBB-22222222-3333-4444-5555-666666666666}
TargetFilename: C:\Users\mlopez\AppData\Local\Temp\update.exe

El proceso deposita un nuevo archivo update.exe en el directorio temporal del usuario.

Cómo redactar el hallazgo analítico: No escribas en tu reporte de triaje: «Word infectó el equipo con un troyano». Escribe la evidencia técnica demostrada: «A las 09:31:48, WINWORD.EXE generó una instancia de powershell.exe ({BBB-222...}), la cual resolvió el dominio cdn-update-example.test, estableció una conexión TCP/443 hacia 203.0.113.70 y creó el archivo update.exe en AppData\Local\Temp. Se procede a extraer el hash del binario para comprobar reputación y verificar persistencia en el Registro».

14. Consultas forenses con PowerShell y Get-WinEvent #

El cmdlet Get-WinEvent con tablas hash (-FilterHashtable) es el mecanismo más rápido y eficiente para consultar grandes volúmenes de telemetría de Sysmon directamente desde PowerShell:

# 1. Buscar todas las conexiones de red (Event 3) originadas por powershell.exe
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 3
} | Where-Object { $_.Properties[4].Value -like "*powershell.exe*" } |
Select-Object TimeCreated,
    @{N="Proceso";E={$_.Properties[4].Value}},
    @{N="IP_Destino";E={$_.Properties[14].Value}},
    @{N="Puerto";E={$_.Properties[16].Value}}

# 2. Correlacionar toda la actividad asociada a un ProcessGuid específico
$guid = "{BBB-22222222-3333-4444-5555-666666666666}"
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1, 3, 11, 22
} | Where-Object { $_.ToXml() -like "*$guid*" } |
Select-Object TimeCreated, Id, Message | Sort-Object TimeCreated

# 3. Detectar procesos ejecutados desde rutas temporales del sistema
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1
} | Where-Object { $_.Properties[4].Value -like "*\AppData\Local\Temp\*" } |
Select-Object TimeCreated,
    @{N="Ejecutable";E={$_.Properties[4].Value}},
    @{N="CommandLine";E={$_.Properties[10].Value}}

15. Sysmon en la arquitectura corporativa: SIEM y EDR #

En una organización con cientos o miles de endpoints, los analistas del SOC no abren el Visor de eventos máquina por máquina. La telemetría de Sysmon se recolecta mediante agentes (como Windows Event Forwarding - WEF, Winlogbeat o agentes de Splunk) y se canaliza a un repositorio centralizado:

Para comprender a fondo la arquitectura de ingestión, normalización y detección en el centro de operaciones, consulta nuestra guía sobre qué es un SIEM y cómo funciona. Si deseas analizar cómo interactúan estas plataformas con la automatización defensiva, revisa SIEM vs SOAR.

Sysmon y EDR: clarificación funcional

Un agente EDR (Endpoint Detection and Response) corporativo moderno (como Defender for Endpoint, CrowdStrike o SentinelOne) suele integrar su propia telemetría de kernel y ofrece funciones avanzadas de detección en tiempo real, aislamiento automático de la máquina en red y reversión de cambios.

Sysmon no compite directamente con un EDR ni pretende sustituirlo. En muchas arquitecturas, Sysmon complementa la visibilidad en servidores donde no hay licencias completas de EDR, sirve como fuente neutral para reglas comunitarias Sigma o aporta telemetría estandarizada para laboratorios defensivos y centros de triaje.

16. Buenas prácticas: timestamps UTC y límites de visibilidad #

• Estandarización temporal en UTC: Sysmon escribe todas sus marcas de tiempo internas en UTC (Tiempo Universal Coordinado) dentro del campo UtcTime. Si tu equipo local está en España peninsular (UTC+2 en verano) y el evento ocurrió a las 11:30 en tu reloj, Sysmon registrará 09:30 UTC. En cualquier investigación forense debes documentar expresamente las zonas horarias para no desajustar tus cronogramas.
• La falacia de la ausencia: La frase más peligrosa en el análisis defensivo es: «No veo el evento en Sysmon, por lo tanto la acción no ocurrió». Una directiva de exclusión XML mal calibrada, un problema de buffering en el controlador o un fallo del servicio (Event ID 255) pueden ocultar la evidencia. Un analista riguroso afirma: «No disponemos de telemetría registrada en esta fuente».

17. De la telemetría a Detection Engineering #

El camino natural para quien domina los eventos de Sysmon es avanzar hacia la Ingeniería de Detección (Detection Engineering). Este proceso transforma hipótesis defensivas en reglas operativas de monitorización:

Una regla ingenua como:

Image contains "powershell.exe"

Generará miles de falsos positivos al día. La ingeniería de detección añade contexto comportamental:

Image = "powershell.exe" AND ParentImage IN ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE")

Al restringir la relación padre-hijo, la regla pasa de ser puro ruido a convertirse en una detección de alta fidelidad para vectores de ataque basados en documentos maliciosos.

Para clasificar estas hipótesis comportamentales bajo una taxonomía formal de adversarios y vincularlas a Data Components analíticos, consulta nuestra guía completa sobre MITRE ATT&CK para analistas SOC.

18. Laboratorio práctico: 5 ejercicios sin malware #

Para entrenar tus destrezas analíticas no requieres ejecutar artefactos maliciosos reales. Puedes generar comportamientos sospechosos utilizando únicamente binarios del sistema operativo:

Resolve-DnsName -Name "example.com"

Invoke-WebRequest -Uri "https://example.com" -UseBasicParsing

"evidencia de laboratorio" | Out-File "$env:TEMP\sysmon-test.txt"
Remove-Item "$env:TEMP\sysmon-test.txt"

19. Preguntas frecuentes sobre Sysmon #

¿Qué es Sysmon? #

Sysmon (System Monitor) es una utilidad y controlador de sistema de Microsoft que monitoriza y registra actividades clave del sistema operativo Windows —como creación de procesos con hashes, conexiones de red, consultas DNS y cambios en el Registro— volcándolas en el visor de eventos para su análisis defensivo.

¿Sysmon es un antivirus? #

No. Sysmon no analiza malware en tiempo real ni bloquea ficheros o conexiones sospechosas. Es exclusivamente un generador de telemetría forense de alta calidad.

¿Sysmon detecta malware por sí solo? #

No de manera autónoma. Proporciona los datos y evidencias necesarias para que los analistas del SOC o las reglas analíticas de un SIEM/EDR puedan identificar patrones de ataque.

¿Qué Event ID de Sysmon debería aprender primero? #

El Event ID 1 (Process Create). Es el pilar sobre el que pivota toda investigación de host. Posteriormente incorpora el Event ID 3 (Network Connection), el Event ID 22 (DNS Query) y el Event ID 11 (File Create).

¿Dónde se guardan los logs de Sysmon? #

En el canal dedicado Applications and Services Logs > Microsoft > Windows > Sysmon > Operational dentro del Visor de eventos de Windows (eventvwr.msc).

¿Sysmon y los Windows Event Logs son lo mismo? #

No. Los Windows Event Logs son la infraestructura base del sistema operativo. Sysmon es un componente adicional que inyecta telemetría especializada y profunda dentro de esa misma infraestructura de registro.

¿Sysmon reemplaza a un SIEM? #

No. Sysmon genera telemetría a nivel de endpoint individual. El SIEM se encarga de recolectar, correlacionar y buscar eventos procedentes de miles de equipos y dispositivos de red de toda la empresa.

¿Sysmon reemplaza a un EDR corporativo? #

No necesariamente. Las plataformas EDR añaden capacidades de contención activa, aislamiento de máquinas y respuesta automatizada. Sysmon se centra en la observabilidad y captura de eventos.

¿Debo activar todos los eventos de Sysmon en producción? #

No por defecto. Habilitar sin filtros eventos masivos como Image Load (ID 7) o Process Access (ID 10) puede generar cientos de miles de eventos innecesarios al día, degradando el rendimiento y encareciendo los costes de almacenamiento.

¿Puedo utilizar una configuración de Sysmon descargada de Internet? #

Plantillas reconocidas como las de SwiftOnSecurity o Florian Roth son excelentes para aprender o usar como punto de partida en laboratorios. En producción corporativa deben probarse y ajustarse al perfil específico de software de la organización.

20. Conclusión: reconstruir comportamiento, no acumular números #

Sysmon empieza a ser verdaderamente útil cuando dejamos de concebirlo como una lista memorizada de Event IDs. Un proceso inicia otro proceso. Ese segundo proceso consulta un dominio externo mediante DNS. Luego establece una conexión TCP. Deposita un archivo ejecutable en disco. Modifica una clave en el Registro.

Cada evento por separado es únicamente una pieza de datos. La labor profesional del analista defensivo consiste en conectarlas para desvelar el cuadro completo.

Cuando abras por primera vez el canal Microsoft-Windows-Sysmon/Operational, no te abrumes intentando recordar los 29 identificadores. Elige un evento de creación de proceso (Event ID 1). Observa su línea de comandos. Sigue su ProcessGuid hacia los eventos posteriores. Y pregúntate con criterio forense: «¿Qué hizo este proceso inmediatamente después?». Ahí es donde comienza la auténtica investigación de Blue Team.

Para consolidar tus competencias en operaciones defensivas, revisa nuestra guía sobre habilidades de un analista SOC o traza tu progresión formativa completa con el Blue Team roadmap.

Fuentes oficiales y documentación técnica revisada #

• Microsoft Learn: System Monitor (Sysmon) Documentation (Especificación técnica de comandos, eventos y directivas).
• Microsoft Learn: Event 4624: An account was successfully logged on (Auditoría de inicio de sesión nativa de Windows).
• Microsoft Learn: Event 4688: A new process has been created (Auditoría de procesos de Windows).
• Microsoft Learn: Get-WinEvent PowerShell Cmdlet (Consulta y filtrado de registros de eventos).
• Sysinternals Repository: Microsoft Threat Intelligence Center (MSTIC) Sysmon Guidelines.

Última revisión técnica: 07 de octubre de 2026.