Plantilla de Reporte de Threat Hunting: Documentacion

Por Que Documentar los Hunts

TL;DR: El reporte de threat hunting es un documento estructurado que registra hipótesis, metodología y hallazgos para transformar la búsqueda proactiva de amenazas en conocimiento corporativo accionable. Mediante el uso de métricas, un equipo puede transformar 12 hunts trimestrales en múltiples reglas de detección y evidencias de compromiso reales. Es fundamental adoptar una plantilla estandarizada con metadatos técnicos para asegurar la reproducibilidad y demostrar el valor estratégico del programa de hunting.

La documentación de los hunts cumple cuatro funciones criticas:

Conocimiento acumulativo. Cada hunt documentado contribuye a la base de conocimiento del equipo. Los hunts pasados informan las hipotesis futuras. Sin documentación, el equipo reinventa la rueda constantemente.

Reproducibilidad. Un hunt bien documentado puede ser reproducido por otro analista. Las consultas exactas, las fuentes de datos y el período temporal permiten repetir el análisis en el futuro o en otro entorno.

Retroalimentacion. Los hallazgos documentados se convierten en reglas de detección. Sin un registro formal, los hallazgos se pierden entre los cuadernos de notas y los chats internos.

Justificacion. Los reportes permiten medir la efectividad del programa y justificar la inversion ante la dirección. "Completamos 12 hunts este trimestre, descubrimos 3 amenazas reales y creamos 8 nuevas reglas de detección" es mucho más convincente que "hicimos threat hunting".

Plantilla del Reporte de Hunt

Sección 1: Metadatos

HUNT REPORT
===========

ID:              HUNT-2026-042
Titulo:          Hunting de Persistencia via WMI Event Subscriptions
Fecha inicio:    2026-06-02
Fecha fin:       2026-06-03
Hunter(s):       Ana Garcia, Carlos Lopez
Estado:          Completado
Resultado:       Hallazgo positivo (1 host comprometido)

Clasificacion:   TLP:AMBER
Prioridad:       Alta
Tiempo invertido: 6 horas

Seccion 2: Hipotesis

HIPOTESIS
=========

Enunciado:
Un adversario ha establecido persistencia en servidores Windows
del segmento de produccion mediante WMI Event Subscriptions que
ejecutan comandos de PowerShell en respuesta a eventos del sistema.

Tipo de hipotesis: Attack-driven (basada en ATT&CK T1546.003)

Justificacion:
- No existe cobertura de deteccion para WMI Event Subscriptions
  en el SIEM actual
- La tecnica es usada por multiples grupos (APT29, APT41, FIN7)
- El sector financiero (nuestro sector) es objetivo habitual
  de estos grupos
- Sysmon Event IDs 19/20/21 estan habilitados pero no hay reglas

ATT&CK Mapping:
- Tactica: Persistence (TA0003), Privilege Escalation (TA0004)
- Tecnica: T1546.003 (Event Triggered Execution: WMI Event Subscription)

Seccion 3: Metodologia

METODOLOGIA
===========

Fuentes de datos consultadas:
  1. Sysmon Event IDs 19, 20, 21 (via Elastic, index winlogbeat-*)
     Periodo: 2026-03-01 a 2026-06-02 (90 dias)
     Cobertura: 342 servidores Windows

  2. Consulta WMI directa via Velociraptor
     Artifact: Windows.Persistence.PermanentWMIEvents
     Scope: Todos los servidores Windows (342 hosts)

  3. Logs de PowerShell (Event ID 4103/4104)
     Periodo: 2026-05-01 a 2026-06-02 (30 dias)
     Cobertura: 342 servidores

Consultas ejecutadas:

  Consulta 1 (Elastic KQL):
  event.code: ("19" OR "20" OR "21")
  | Periodo: ultimos 90 dias
  | Resultados: 47 eventos

  Consulta 2 (Velociraptor VQL):
  SELECT * FROM wmi(
    query="SELECT * FROM __EventFilter",
    namespace="root/subscription"
  )
  | Resultados: 18 subscriptions en 342 hosts

  Consulta 3 (Elastic KQL):
  event.code: "4104" AND
  powershell.file.script_block_text: *WMI* AND
  powershell.file.script_block_text: *EventFilter*
  | Resultados: 3 eventos en 1 host

Limitaciones:
  - Sysmon Event IDs 19-21 solo estaban habilitados desde
    2026-01-15 (no hay datos anteriores)
  - 12 servidores no tenian agente Velociraptor instalado
  - Logs de PowerShell solo tienen 30 dias de retencion

Seccion 4: Hallazgos

HALLAZGOS
=========

Hallazgo 1: WMI Event Subscription maliciosa en SRV-DB-PROD-03
  Severidad: CRITICA
  Confianza: Alta (95%)

  Descripcion:
  Se identifico una WMI Event Subscription en el servidor
  SRV-DB-PROD-03 que no corresponde a ninguna herramienta
  corporativa conocida. La subscription ejecuta un script
  PowerShell codificado en Base64 cada vez que un usuario
  inicia sesion en el servidor.

  Evidencia:
  - Event Filter:
    Nombre: "SystemHealthCheck"
    Query: SELECT * FROM __InstanceCreationEvent WITHIN 60
           WHERE TargetInstance ISA 'Win32_LogonSession'

  - Event Consumer:
    Tipo: CommandLineEventConsumer
    CommandLineTemplate: powershell.exe -nop -w hidden
      -enc [base64 de 847 caracteres]

  - Binding creado: 2026-04-18 03:42:17 UTC

  - Script decodificado (resumen, no completo por TLP):
    Descarga un segundo stage desde un dominio sospechoso
    y lo ejecuta en memoria via reflection

  - Host comprometido: SRV-DB-PROD-03
    IP: 10.20.30.43
    Rol: Servidor de base de datos SQL Server
    Ultima actividad WMI: 2026-06-01 08:15:22 UTC

  IOCs extraidos:
  - Dominio: cdn-updates[.]systemcheck[.]xyz (C2)
  - IP del dominio: 185.234.xxx.xxx
  - Hash del script: SHA256 e3b0c44298fc1c149...

Hallazgo 2: WMI Subscriptions legitimas no documentadas
  Severidad: BAJA (informativo)
  Confianza: Alta

  Descripcion:
  Se encontraron 17 WMI Event Subscriptions en 8 servidores
  que corresponden a herramientas de monitorizacion corporativas
  (SCCM, Nagios) pero no estaban documentadas en la CMDB.
  No son maliciosas pero su existencia no documentada dificulta
  la deteccion de anomalias.

  Recomendacion: documentar en la CMDB para actualizar el
  baseline de WMI subscriptions legitimas.

Seccion 5: Analisis y Correlacion

ANALISIS
========

Timeline del compromiso (basado en evidencia disponible):
  2026-04-18 03:42 - Creacion de la WMI Event Subscription
  2026-04-18 03:43 - Primera ejecucion del script (Event ID 4104)
  2026-04-18 a 2026-06-01 - Ejecucion periodica en cada logon
  2026-06-01 08:15 - Ultima ejecucion observada

Correlacion con otras fuentes:
  - El dominio cdn-updates.systemcheck.xyz NO aparece en feeds
    de CTI conocidos (no reportado previamente)
  - La IP 185.234.xxx.xxx esta alojada en hosting en Moldavia
  - No se encontro movimiento lateral desde SRV-DB-PROD-03
    (limitacion: solo 30 dias de logs de autenticacion)
  - No se encontro exfiltracion obvia desde este servidor
    (limitacion: logs de red Zeek solo cubren el perimetro,
    no el segmento de bases de datos)

Atribucion:
  No es posible con la evidencia actual. La tecnica T1546.003
  es usada por multiples grupos. Se necesita analisis del
  segundo stage para mas indicadores.

Impacto potencial:
  - SRV-DB-PROD-03 aloja bases de datos de clientes
  - Un adversario con ejecucion en este servidor podria
    acceder a datos sensibles de clientes
  - El compromiso lleva activo al menos 45 dias

Seccion 6: Recomendaciones

RECOMENDACIONES
===============

Inmediatas (escalar a IR):
  1. Aislar SRV-DB-PROD-03 de la red
  2. Capturar memoria volatil antes de apagar
  3. Analizar el segundo stage del malware
  4. Investigar actividad historica en logs de BD
  5. Verificar integridad de datos de clientes

Deteccion (crear reglas):
  1. Crear regla Sigma/KQL para Sysmon Event IDs 19/20/21
     con exclusiones para subscriptions legitimas documentadas
  2. Crear regla para PowerShell con -enc lanzado por
     WmiPrvSE.exe
  3. Crear alerta para nuevas WMI subscriptions en servidores
     de produccion

Mejora de visibilidad:
  1. Instalar agente Velociraptor en los 12 servidores
     que no lo tienen
  2. Extender retencion de logs de PowerShell a 90 dias
  3. Desplegar sensor Zeek en el segmento de bases de datos
  4. Documentar todas las WMI subscriptions legitimas en CMDB

Programa de hunting:
  1. Programar hunt periodico de WMI subscriptions (mensual)
  2. Anadir T1546.003 al coverage map como "cubierta por hunting"
  3. Evaluar cobertura de otras tecnicas de Event Triggered
     Execution (T1546.*)

Seccion 7: Metricas del Hunt

METRICAS
========

Tiempo total invertido:      6 horas (2 analistas x 3 horas)
Endpoints analizados:        342
Fuentes de datos consultadas: 3
Consultas ejecutadas:         7
Hallazgos confirmados:        1 critico, 1 informativo
IOCs nuevos generados:        3
Reglas de deteccion creadas:  2 (pendiente implementacion)
Gaps de visibilidad identificados: 3
ATT&CK techniques tested:    1 (T1546.003)

Estructura del Repositorio de Hunts

Organizar los reportes de hunt en un repositorio estructurado facilita la busqueda y reutilizacion:

hunts/
  2026/
    Q2/
      HUNT-2026-040-dns-tunneling-corporate.md
      HUNT-2026-041-powershell-encoding-endpoints.md
      HUNT-2026-042-wmi-persistence-servers.md
      HUNT-2026-043-lateral-movement-finance-segment.md
  templates/
    hunt-report-template.md
    hunt-hypothesis-template.md
  playbooks/
    playbook-persistence-check.md
    playbook-lateral-movement.md
    playbook-c2-beaconing.md
  metrics/
    quarterly-summary-Q2-2026.md

Metricas del Programa de Hunting

Además de las metricas individuales de cada hunt, el programa necesita metricas agregadas:

Metricas de actividad

Metrica	Descripcion	Frecuencia
Hunts completados	Total de hunts finalizados	Mensual
Horas invertidas	Tiempo total del equipo en hunting	Mensual
Técnicas ATT&CK testeadas	Técnicas cubiertas por al menos un hunt	Trimestral
Endpoints cubiertos	Porcentaje de endpoints incluidos en hunts	Trimestral

Metricas de resultado

Metrica	Descripcion	Frecuencia
Tasa de descubrimiento	% de hunts con hallazgo positivo	Trimestral
Severidad de hallazgos	Distribución por severidad	Trimestral
Reglas creadas	Reglas de detección generadas por hunts	Mensual
Tiempo medio de respuesta	Desde hallazgo hasta escalación a IR	Por incidente

Metricas de madurez

Metrica	Descripcion	Frecuencia
Cobertura ATT&CK	% de técnicas cubiertas por hunting o detección	Semestral
Tipo de hipotesis	Distribución: attack/intel/anomaly driven	Trimestral
Gaps de visibilidad	Número de gaps identificados y corregidos	Trimestral
Automatización	% de hallazgos convertidos en detección automática	Trimestral

Errores Comunes en la Documentación

No registrar las consultas exactas. "Busque PowerShell sospechoso" no es útil. La consulta exacta (copiar y pegar) permite reproducir el hunt.

No documentar los negativos. Un hunt que no encuentra nada sigue siendo un resultado valido. Documenta que se busco, donde, durante que período y por que no se encontro. Esto evita que otro hunter repita el mismo análisis.

No documentar las limitaciones. Cada hunt tiene limitaciones de visibilidad: logs que no existen, endpoints sin agente, periodos de retencion insuficientes. Documentarlas es tan importante como documentar los hallazgos.

No cerrar el ciclo. Un reporte sin recomendaciones implementadas es documentación muerta. El paso de "hallazgo" a "regla de detección" debe tener un responsable y una fecha.

Conclusion

Un reporte de hunt bien estructurado transforma una actividad de investigación en un activo del equipo. Cada reporte contribuye al conocimiento acumulativo, habilita la retroalimentacion hacia la detección automatizada y proporciona evidencia del valor del programa.

La plantilla presentada en este artículo cubre las siete secciones esenciales: metadatos, hipotesis, metodologia, hallazgos, análisis, recomendaciones y metricas. Adaptala a las necesidades de tu equipo, pero no elimines ninguna sección. La completitud es lo que diferencia un registro útil de una nota olvidada.