Hipotesis de Hunting Basadas en ATT&CK: Guia Practica para Construirlas

La Hipotesis como Motor del Hunting

Una hipotesis de hunting es una afirmacion testeable sobre una amenaza potencial en tu entorno. Es el punto de partida que dirige la investigacion, determina que datos necesitas y define el criterio de exito o fracaso del hunt.

La calidad de la hipotesis determina la calidad del hunt. Una hipotesis vaga ("buscar actividad sospechosa en la red") no produce resultados accionables. Una hipotesis especifica ("adversarios estan usando rundll32.exe para ejecutar DLLs maliciosas desde directorios temporales en los endpoints Windows del segmento de finanzas") dirige la investigacion de forma precisa.

Anatomia de una Buena Hipotesis

Una hipotesis de hunting efectiva tiene cuatro componentes:

Amenaza (quien o que). El adversario, la campana o la tecnica que se busca. Puede ser un actor especifico (APT28), un tipo de malware (ransomware) o una tecnica generica (movimiento lateral).

Tecnica (como). El metodo que el adversario usaria. Debe ser especifica y describir un comportamiento observable en los datos. "Usando WMI para ejecutar comandos remotamente" es mejor que "haciendo cosas malas".

Entorno (donde). La parte de la infraestructura donde se buscara. "En los servidores Windows del segmento de bases de datos" es mas util que "en alguna parte de la red".

Evidencia (que buscar). Los artefactos, logs o patrones que confirmarian o refutarian la hipotesis. "Eventos Sysmon ID 1 con ParentImage wmiprvse.exe y CommandLine conteniendo cmd.exe o powershell.exe" define exactamente que buscar.

Plantilla de hipotesis

HIPOTESIS: [Actor/Amenaza] esta usando [Tecnica ATT&CK]
para [objetivo tactica] en [segmento/sistemas del entorno].

EVIDENCIA ESPERADA:
- Fuente de datos: [Sysmon, Zeek, AD logs, etc.]
- Indicadores: [eventos, patrones, valores especificos]
- Baseline normal: [que deberia verse normalmente]
- Anomalia buscada: [desviacion del baseline]

PRIORIDAD: [Alta/Media/Baja] basada en [justificacion]

Tres Fuentes de Hipotesis

Fuente 1: MITRE ATT&CK (attack-driven)

ATT&CK es la fuente mas sistematica para generar hipotesis. El framework documenta cientos de tecnicas agrupadas en tacticas. El proceso es:

1. Mapear la cobertura de deteccion actual contra ATT&CK (que tecnicas tienen reglas de deteccion)
2. Identificar gaps: tecnicas sin cobertura de deteccion
3. Priorizar gaps por relevancia (que adversarios usan esas tecnicas y son relevantes para tu sector)
4. Formular hipotesis para los gaps de mayor prioridad

Ejemplo con T1053.005 (Scheduled Task/Job: Scheduled Task):

Un analisis de cobertura revela que no hay reglas de deteccion para la creacion de tareas programadas en Windows. La tecnica es usada por numerosos grupos (APT29, FIN7, Lazarus) y es comun en la fase de persistencia.

HIPOTESIS: Un adversario ha establecido persistencia mediante la
creacion de tareas programadas (schtasks.exe) que ejecutan scripts
de PowerShell o binarios desde ubicaciones no estandar en los
servidores Windows del dominio corporativo.

EVIDENCIA ESPERADA:
- Fuente: Sysmon Event ID 1 (Process Create)
- Indicadores: ParentImage que incluya schtasks.exe,
  CommandLine con /create y apuntando a rutas %TEMP%, %APPDATA%,
  o carpetas ocultas
- Fuente complementaria: Windows Event ID 4698 (A scheduled task was created)
- Baseline: tareas programadas legitimas (backups, updates,
  scripts de IT) documentadas en CMDB
- Anomalia: tareas no documentadas, especialmente las que
  ejecutan PowerShell, cmd.exe o binarios en rutas temporales

Ejemplo con T1021.002 (Remote Services: SMB/Windows Admin Shares):

HIPOTESIS: Existe movimiento lateral mediante el uso de shares
administrativos (C$, ADMIN$, IPC$) entre servidores del segmento
de produccion, fuera del horario habitual de mantenimiento.

EVIDENCIA ESPERADA:
- Fuente: Windows Event ID 5140 (Network Share Accessed)
  y 5145 (Detailed File Share)
- Indicadores: accesos a C$, ADMIN$ o IPC$ entre servidores
  (no desde estaciones de trabajo de administradores)
- Fuente complementaria: Zeek smb_mapping.log
- Baseline: accesos legitimos durante ventanas de mantenimiento
  desde IPs de administradores
- Anomalia: accesos fuera de horario, desde IPs no conocidas,
  o entre servidores que no deberian comunicarse

Fuente 2: Inteligencia de amenazas (intelligence-driven)

La CTI proporciona contexto sobre amenazas activas que afectan a organizaciones similares. La diferencia con el hunting basado en IOCs es que aqui se buscan TTPs, no indicadores atomicos.

Proceso:

1. Recibir un informe de CTI relevante (CISA advisory, reporte de vendor, publicacion CERT)
2. Extraer las TTPs descritas en el informe
3. Mapear las TTPs a ATT&CK
4. Formular hipotesis basadas en como esas TTPs se manifestarian en tu entorno

Ejemplo basado en un advisory de CISA sobre Volt Typhoon:

El advisory describe que Volt Typhoon (actor chino state-sponsored) usa LOLBins para persistir y moverse lateralmente en infraestructuras criticas. Las tecnicas principales incluyen ntdsutil.exe para extraer credenciales de AD y netsh para crear port forwarding.

HIPOTESIS: Un adversario esta usando ntdsutil.exe para crear
snapshots de NTDS.dit (base de datos de Active Directory) en
los domain controllers, como paso previo a la extraccion de
credenciales de todos los usuarios del dominio.

EVIDENCIA ESPERADA:
- Fuente: Sysmon Event ID 1 en Domain Controllers
- Indicadores: proceso ntdsutil.exe con argumentos "snapshot"
  o "activate instance ntds"
- Fuente complementaria: creacion de archivos .dit en directorios
  no estandar (Sysmon Event ID 11)
- Baseline: uso legitimo de ntdsutil por el equipo de AD
  (documentado y en horario laboral)
- Anomalia: ejecucion fuera de ventanas de mantenimiento,
  por cuentas no autorizadas, o seguida de compresion/copia
  de archivos

Ejemplo basado en un reporte sobre campana de Qakbot:

Un reporte de seguridad describe una nueva variante de Qakbot distribuida via emails de respuesta encadenada (reply-chain phishing) que usa archivos .one (OneNote) como vector de entrega.

HIPOTESIS: Usuarios del departamento comercial han recibido
emails de phishing con adjuntos .one de OneNote que contienen
scripts embebidos (HTA, VBS, BAT) como vector de entrega
de Qakbot u otro loader.

EVIDENCIA ESPERADA:
- Fuente: logs del gateway de correo (adjuntos .one)
- Fuente: Sysmon Event ID 1 con ParentImage onenote.exe
  lanzando procesos hijos (wscript, cmd, powershell, mshta)
- Indicadores: cadena de ejecucion onenote.exe -> wscript.exe
  o mshta.exe -> cmd.exe
- Baseline: onenote.exe no deberia lanzar procesos de scripting
  en uso normal
- Anomalia: cualquier proceso hijo de scripting lanzado por
  onenote.exe

Fuente 3: Anomalias de baseline (anomaly-driven)

Las anomalias son desviaciones del comportamiento normal del entorno. Requieren un baseline documentado contra el cual comparar.

Tipos de anomalias que generan hipotesis:

Anomalias de volumen. Un servidor que normalmente genera 100 MB de trafico DNS al dia y repentinamente sube a 2 GB. Un usuario que consulta 500 archivos en un dia cuando su media es 20.

Anomalias temporales. Actividad en horarios inusuales: conexiones RDP a las 3 AM desde una estacion de trabajo que nunca se usa fuera de horario laboral.

Anomalias de destino. Un servidor interno que empieza a comunicarse con IPs en paises donde la organizacion no tiene presencia. Un endpoint que resuelve dominios de hosting gratuito que no son parte del negocio.

Anomalias de proceso. Un servicio de base de datos que lanza PowerShell. Un servidor web que ejecuta certutil. Un proceso de sistema que abre conexiones salientes no documentadas.

HIPOTESIS: Un endpoint comprometido en el segmento de usuarios
esta realizando DNS tunneling para exfiltrar datos, evidenciado
por un volumen anomalo de consultas DNS a un dominio especifico
con registros TXT de longitud inusual.

EVIDENCIA ESPERADA:
- Fuente: logs DNS (Zeek dns.log o logs del resolver interno)
- Indicadores: alto volumen de consultas a un mismo dominio
  de segundo nivel, subdominios largos (mas de 50 caracteres),
  consultas de tipo TXT con respuestas de tamano grande
- Baseline: volumen normal de consultas DNS por endpoint
  (tipicamente 500 a 2000 queries/dia)
- Anomalia: endpoint con mas de 10.000 queries/dia a un mismo
  dominio, subdominios con patrones de codificacion (Base32/64)

Priorizacion de Hipotesis

No todas las hipotesis tienen la misma prioridad. Tres factores determinan el orden de investigacion:

Relevancia de la amenaza. Las hipotesis basadas en amenazas que afectan activamente a tu sector tienen prioridad sobre amenazas genericas. Si eres una institucion financiera, las TTPs de FIN7 son mas prioritarias que las de APT28.

Gap de deteccion. Las tecnicas sin ninguna cobertura de deteccion son mas prioritarias que las que tienen cobertura parcial. Un gap total significa que un adversario puede usar esa tecnica sin riesgo de deteccion.

Impacto potencial. Las hipotesis sobre tecnicas de alto impacto (exfiltracion, ransomware, destruccion) tienen prioridad sobre tecnicas de reconocimiento o descubrimiento.

Matriz de priorizacion

Criterio	Peso	Alto (3)	Medio (2)	Bajo (1)
Relevancia amenaza	40%	Actor activo en mi sector	Actor activo en otros sectores	Tecnica teorica
Gap deteccion	35%	Sin cobertura	Cobertura parcial	Cobertura completa
Impacto potencial	25%	Exfiltracion, ransomware	Persistencia, C2	Reconocimiento

Puntuacion: (Relevancia x 0.4) + (Gap x 0.35) + (Impacto x 0.25). Las hipotesis con puntuacion mas alta se investigan primero.

De la Hipotesis a la Investigacion

Una vez formulada y priorizada la hipotesis, el siguiente paso es disenar la investigacion.

Paso 1: Identificar fuentes de datos

Para cada hipotesis, lista las fuentes de datos necesarias y verifica que estan disponibles:

• Los datos existen y se estan recopilando?
• La retencion cubre el periodo temporal de interes?
• La granularidad es suficiente (por ejemplo, Sysmon Event ID 1 incluye CommandLine completa)?
• Hay gaps conocidos (endpoints sin Sysmon, segmentos sin monitorizacion de red)?

Paso 2: Construir consultas

Traduce la evidencia esperada a consultas ejecutables en tu SIEM o herramienta de analisis.

Ejemplo en KQL (Elastic) para la hipotesis de tareas programadas:

event.code: "1" AND
process.parent.name: "schtasks.exe" AND
process.command_line: (*powershell* OR *cmd.exe* OR *wscript*) AND
process.working_directory: (*Temp* OR *AppData* OR *ProgramData*)

Ejemplo en SPL (Splunk):

index=sysmon EventCode=1 ParentImage="*schtasks.exe"
| where match(CommandLine, "(?i)(powershell|cmd\.exe|wscript)")
| where match(CurrentDirectory, "(?i)(temp|appdata|programdata)")
| stats count by Computer, User, CommandLine, ParentCommandLine
| sort -count

Paso 3: Analizar resultados

Los resultados de las consultas raramente dan una respuesta binaria. El hunter debe:

• Filtrar falsos positivos conocidos (tareas programadas legitimas del equipo de IT)
• Identificar patrones (multiples endpoints con la misma tarea sospechosa)
• Pivotar sobre hallazgos (si una tarea sospechosa ejecuta PowerShell, que hace ese script?)
• Correlacionar con otras fuentes (la IP de destino del script aparece en feeds de CTI?)

Paso 4: Documentar y cerrar

Independientemente del resultado, el hunt se documenta con:

• Hipotesis original y justificacion
• Fuentes de datos consultadas y consultas usadas
• Hallazgos (positivos, negativos, inconcluyentes)
• Limitaciones (gaps de visibilidad, periodo temporal)
• Recomendaciones (nuevas reglas de deteccion, mejoras de logging)

Errores Comunes al Formular Hipotesis

Hipotesis demasiado amplias. "Buscar malware en la red" no es una hipotesis. No dirige la investigacion, no define que buscar ni donde. Acotar por tecnica, segmento y periodo temporal.

Hipotesis sin datos disponibles. Formular una hipotesis sobre DNS tunneling cuando los logs de DNS no se recopilan es inutil. Antes de formular la hipotesis, verifica que los datos estan disponibles.

Confundir IOCs con hipotesis. "Buscar la IP 203.0.113.45 en los logs" es una busqueda de IOC, no una hipotesis. Una hipotesis describe un comportamiento, no un indicador atomico.

No considerar el baseline. Sin saber que es normal, todo parece sospechoso. Si la hipotesis busca "ejecuciones inusuales de PowerShell", el hunter necesita saber cuales son las ejecuciones habituales.

Hipotesis que no se pueden refutar. "Un adversario sofisticado puede haber comprometido cualquier sistema usando tecnicas desconocidas" no es testeable. Si no se puede refutar, no es una hipotesis.

ATT&CK Navigator para Planificar Hunts

MITRE ATT&CK Navigator es una herramienta web que permite crear capas (layers) del framework ATT&CK con colores y anotaciones. Es extremadamente util para planificar hunts:

Capa 1: Cobertura de deteccion. Colorea en verde las tecnicas cubiertas por reglas de deteccion. Las tecnicas sin color son gaps.

Capa 2: Amenazas relevantes. Colorea en rojo las tecnicas usadas por los adversarios relevantes para tu sector. Puedes superponer multiples actores.

Capa 3: Prioridades de hunting. Superpone las capas 1 y 2. Las intersecciones (tecnicas usadas por adversarios relevantes que no tienen cobertura) son los candidatos prioritarios para hunting.

Esta visualizacion permite al equipo ver de un vistazo donde concentrar los esfuerzos de hunting y como va evolucionando la cobertura a medida que se completan hunts y se crean nuevas reglas.

Conclusion

La hipotesis es el corazon del threat hunting. Sin ella, el hunting se convierte en una busqueda sin direccion. Con una hipotesis bien formulada, el hunter sabe exactamente que buscar, donde buscar y como interpretar lo que encuentra.

Las tres fuentes de hipotesis (ATT&CK, inteligencia de amenazas y anomalias de baseline) se complementan entre si. Un programa de hunting maduro usa las tres de forma rotativa, asegurando cobertura amplia y profunda.

En los siguientes articulos de esta serie, aplicaremos estos conceptos a escenarios especificos de hunting: movimiento lateral, persistencia, command and control y exfiltracion.