Ciberseguridad y seguridad de la información

Sysmon Event ID 3 y 22: Conexiones de red y consultas DNS

7 min de lecturaPublicado: 5 de agosto de 2026
Ilustración visual profesional sobre Sysmon Event ID 3 y 22 en el ámbito de Windows e Identidad
Respuesta rápida

Sysmon Event ID 3 y 22 requiere la lectura completa del evento y no solo del Event ID: hora, equipo, usuario, Logon ID, Proceso, fuente de red y contexto organizacional. La conclusión se genera por la correlación entre varias fuentes.

La investigación de Windows e Identidad se basa en la combinación de eventos de autenticación, creación de procesos, cambios de permisos, telemetría de Sysmon y contexto organizacional. Un solo evento casi nunca proporciona una conclusión completa. Este artículo se centra en Sysmon Event ID 3 y 22 y está destinado a analistas de SOC e investigadores de Endpoint. El objetivo es proporcionar una metodología de trabajo que se pueda aplicar en la práctica, en una entrevista profesional y en un entorno de trabajo, sin limitarse a una definición de diccionario.

El desafío principal es que los datos son casi siempre parciales. ProcessGuid, DestinationIp, DestinationPort pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la investigación en torno a una pregunta de investigación, la evidencia requerida y un criterio claro para su finalización.

El escenario práctico en el artículo es: Conectar una Consulta a un proceso y una IP en la Línea de Tiempo. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, solo se debe trabajar con autorización explícita, un Alcance definido y la capacidad de detener la prueba.

Campos del Evento 3

Los campos importantes no son necesariamente los que se muestran en la parte superior de la pantalla. En Sysmon Event ID 3 y 22, se deben identificar identificadores estables, tiempo, origen, destino, resultado y contexto. Ejemplos útiles son ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. El objetivo es permitir la Correlación entre registros y no solo la lectura de un evento individual.

Se recomienda crear un pequeño diccionario de datos: nombre del campo, significado, formato, origen, valores Null esperados y si es confiable para el enlace. Esto permite distinguir entre un campo de visualización y un identificador forense, y detectar cuándo un Conector o una versión han cambiado el Esquema.

Campos del Evento 22

Los campos importantes no son necesariamente los que se muestran en la parte superior de la pantalla. En Sysmon Event ID 3 y 22, se deben identificar identificadores estables, tiempo, origen, destino, resultado y contexto. Ejemplos útiles son ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. El objetivo es permitir la Correlación entre registros y no solo la lectura de un evento individual.

Se recomienda crear un pequeño diccionario de datos: nombre del campo, significado, formato, origen, valores Null esperados y si es confiable para el enlace. Esto permite distinguir entre un campo de visualización y un identificador forense, y detectar cuándo un Conector o una versión han cambiado el Esquema.

Conexión por ProcessGuid

Una implementación correcta comienza con los requisitos y no con los valores predeterminados. Se definen qué Casos de Uso son compatibles, cuál es el volumen de datos, quién gestiona la configuración y cuál es el mecanismo de Rollback. En Sysmon Event ID 3 y 22, se debe distinguir entre configuraciones que generan Telemetría y configuraciones que la filtran o enriquecen.

Después de la configuración, se ejecuta una prueba controlada con un dato esperado, se verifica que el evento se haya registrado, que los campos centrales existan y que el cambio no haya generado carga o un punto ciego. Cada cambio se guarda en una versión, con fecha, propietario, motivo y resultado de la prueba.

Identificación de dominios y destinos anómalos

La investigación de Sysmon Event ID 3 y 22 comienza formulando una Hipótesis: qué comportamiento explica el hallazgo y qué evidencia lo confirmará o refutará. Luego se amplía la ventana de tiempo, se verifican las entidades y se busca una secuencia antes y después del evento.

Una buena correlación combina al menos dos tipos de información de ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. Para cada hallazgo, se indica qué prueba, qué no prueba y cuál es el siguiente paso. Si los datos no son suficientes, se marca como Desconocido y no se convierte la ausencia de evidencia en evidencia de ausencia.

Limitaciones y validación en fuentes adicionales

En esta etapa, se define qué evidencia es necesaria para responder a la pregunta de investigación. Para Sysmon Event ID 3 y 22, los puntos básicos son Event ID y el Proveedor, Equipo, Usuario y Logon ID, Proceso, Padre y Línea de Comandos, IP de Origen, Estación de Trabajo y Tipo de Inicio de Sesión. Para cada fuente se documentan el propietario, el período de retención, la zona horaria, el retraso de ingesta y los campos que pueden faltar.

La calidad de la recopilación no se mide por el hecho de que el log 'llega'. Se debe verificar la Integridad, Latencia, Análisis, Eventos duplicados y Sincronización de tiempo. Una prueba Canary o un evento de laboratorio conocido permite verificar que la acción apareció en la fuente, pasó por la Tubería y se puede buscar en los campos correctos.

Puntos de control únicos

En este tema, se recomienda construir previamente un mapa de evidencia enfocado. Los principales puntos de control son: ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime, query name, response code, TTL, subdomain entropy. La lista no es un Checklist automático; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo o explicar un comportamiento legítimo.

  • ProcessGuid: Defina cuál es el valor esperado, qué se consideraría anómalo y qué otra fuente confirmaría el hallazgo.
  • DestinationIp: Defina cuál es el valor esperado, qué se consideraría anómalo y qué otra fuente confirmaría el hallazgo.
  • DestinationPort: Defina cuál es el valor esperado, qué se consideraría anómalo y qué otra fuente confirmaría el hallazgo.
  • QueryName: Defina cuál es el valor esperado, qué se consideraría anómalo y qué otra fuente confirmaría el hallazgo.
  • QueryResults: Defina cuál es el valor esperado, qué se consideraría anómalo y qué otra fuente confirmaría el hallazgo.
  • UtcTime: Defina cuál es el valor esperado, qué se consideraría anómalo y qué otra fuente confirmaría el hallazgo.

Cuando uno de los puntos focales no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el identificador de proceso no es estable, se puede usar el tiempo, el Host, el Usuario y el Padre; si la Carga útil está cifrada, se utilizan los Metadatos, el volumen, la frecuencia y el contexto TLS/DNS.

Proceso de trabajo recomendado

  1. Defina el Alcance y una pregunta de trabajo sobre Sysmon Event ID 3 y 22.
  2. Registre las fuentes de datos y la evidencia necesaria: ProcessGuid, DestinationIp, DestinationPort, QueryName.
  3. Cree una Línea de Base corta de comportamiento normal o resultado esperado.
  4. Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
  5. Cree una Línea de Tiempo o una tabla de comparación y separe los hechos de la interpretación.
  6. Realice un Pivot a otra fuente para confirmar o refutar la explicación inicial.
  7. Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es conectar una Consulta a un proceso y una IP en la Línea de Tiempo. El propósito del ejercicio no es probar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe entregar un producto que otro analista o evaluador pueda revisar: una captura de pantalla o Exportación de la evidencia, una Línea de Tiempo corta, una suposición inicial, evidencia confirmatoria, limitación y recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

EtapaQué se realizaProducto
PreparaciónDefina el Alcance, el tiempo y el destino. Registre qué campos o evidencias de ProcessGuid, DestinationIp, DestinationPort se espera que aparezcan.Plan de prueba corto
Creación de datosRealice una acción segura y simulada relacionada con Sysmon Event ID 3 y 22, sin información real o impacto en el sistema de producción.Evento/Solicitud/Flujo controlado
RecopilaciónRecopile la evidencia bruta y el contexto de una fuente adicional. Asegúrese de la zona horaria, los identificadores y la integridad.Dos evidencias vinculadas
AnálisisEscriba qué prueba cada evidencia, qué no prueba y cuál es la posible explicación legítima.Conclusión provisional
FinalizaciónElija un cierre, escalada, hallazgo o ajuste; añada una recomendación y un Retest.Producto documentado

Lista de verificación práctica

  • Verificar y documentar: Event ID y el Proveedor.
  • Verificar y documentar: Computer, User y Logon ID.
  • Verificar y documentar: Process, Parent y Command Line.
  • Verificar y documentar: Source IP, Workstation y Logon Type.
  • Verificar y documentar: Group/Privilege changes.
  • Verificar y documentar: Sysmon ProcessGuid o SessionGuid.
  • Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
  • Guarde el dato bruto antes de filtrar o modificar.
  • Escriba qué demuestra el hallazgo y qué aún se desconoce.
  • Defina el propietario y la acción de seguimiento con una fecha.

Errores comunes

  • Basarse en el Event ID sin los campos.
  • Confundir el inicio de sesión con la fuente del ataque.
  • Ignorar el tipo de inicio de sesión.
  • Vincular Procesos solo por PID.
  • Asumir que todo PowerShell es malicioso.
  • Cerrar un evento sin verificar el Domain Controller.

Resumen y CTA

Sysmon Event ID 3 y 22: Conexiones de red y consultas DNS es un tema que conecta el conocimiento técnico con la disciplina laboral. Comience con una pregunta, recopile solo evidencia relevante, mantenga el contexto y el tiempo, y elija una acción que se pueda justificar y volver a probar.

En la ruta Cybersecurity & AI de HPI se practican estos principios utilizando sistemas, logs y laboratorios. Un paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de una cartera de trabajo profesional.

Preguntas frecuentes

¿Sysmon Event ID 3 y 22 por sí solos prueban un ataque o una vulnerabilidad?

No. Proporciona una señal o un hallazgo que requiere contexto, validación y una fuente adicional. Una conclusión profesional se basa en una secuencia de evidencia y en la conformidad con el comportamiento esperado.

¿Qué hacer cuando faltan algunos datos?

Documente lo que falta, busque una fuente alternativa y reduzca el nivel de certeza. No complete campos por conjetura ni presente "Desconocido" como válido.

¿Cuánto tiempo se debe conservar la evidencia?

El tiempo depende de la política, la regulación, el costo y el tipo de evento. Es importante definir de antemano la Retención, la Retención Legal y la capacidad de exportar evidencia en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Utilice máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En pruebas autorizadas, defina el Alcance, las condiciones de detención y una copia de seguridad antes de comenzar el trabajo.

¿Quieres comprobar si este itinerario es para ti?

Deja tus datos y un asesor de HPI te llamará para una breve charla de orientación, sin compromiso.

Tus datos se guardan de forma segura.

Para estudios de SOC y ciberseguridad en el programa Cybersecurity & AI

¿Quieres los detalles del programa? Déjanos tus datos y te contactaremos.

Artículos relacionados