Plantilla de Reporte de Threat Hunting: Documentacion Completa del Hunt
Plantilla completa para documentar hunts de amenazas. Estructura del reporte, hipotesis, metodologia, hallazgos, evidencia, recomendaciones y metricas. Incluye ejemplos reales y buenas practicas de documentacion para equipos de threat hunting.
Por Que Documentar los Hunts
La documentacion 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 documentacion, 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 periodo temporal permiten repetir el analisis en el futuro o en otro entorno.
Retroalimentacion. Los hallazgos documentados se convierten en reglas de deteccion. 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 direccion. "Completamos 12 hunts este trimestre, descubrimos 3 amenazas reales y creamos 8 nuevas reglas de deteccion" es mucho mas convincente que "hicimos threat hunting".
Plantilla del Reporte de Hunt
Seccion 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
Ademas 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 |
| Tecnicas ATT&CK testeadas | Tecnicas 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 | Distribucion por severidad | Trimestral |
| Reglas creadas | Reglas de deteccion generadas por hunts | Mensual |
| Tiempo medio de respuesta | Desde hallazgo hasta escalacion a IR | Por incidente |
Metricas de madurez
| Metrica | Descripcion | Frecuencia |
|---|---|---|
| Cobertura ATT&CK | % de tecnicas cubiertas por hunting o deteccion | Semestral |
| Tipo de hipotesis | Distribucion: attack/intel/anomaly driven | Trimestral |
| Gaps de visibilidad | Numero de gaps identificados y corregidos | Trimestral |
| Automatizacion | % de hallazgos convertidos en deteccion automatica | Trimestral |
Errores Comunes en la Documentacion
No registrar las consultas exactas. "Busque PowerShell sospechoso" no es util. 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 periodo y por que no se encontro. Esto evita que otro hunter repita el mismo analisis.
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 documentacion muerta. El paso de "hallazgo" a "regla de deteccion" debe tener un responsable y una fecha.
Conclusion
Un reporte de hunt bien estructurado transforma una actividad de investigacion en un activo del equipo. Cada reporte contribuye al conocimiento acumulativo, habilita la retroalimentacion hacia la deteccion automatizada y proporciona evidencia del valor del programa.
La plantilla presentada en este articulo cubre las siete secciones esenciales: metadatos, hipotesis, metodologia, hallazgos, analisis, recomendaciones y metricas. Adaptala a las necesidades de tu equipo, pero no elimines ninguna seccion. La completitud es lo que diferencia un registro util de una nota olvidada.
Preguntas frecuentes
Libros recomendados
Artículos relacionados
Que es Threat Hunting: Metodologia Completa para Equipos de Seguridad
Hipotesis de Hunting Basadas en ATT&CK: Guia Practica para Construirlas
Como Construir un Programa de Threat Hunting: Equipo, Herramientas y Metricas
Hunting Maturity Model (HMM): Los 5 Niveles de Madurez en Threat Hunting
Metricas de Detection Engineering: Medir lo que Importa
¿Qué es Detection Engineering? Del Alert Fatigue a Detecciones que Funcionan
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.