🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Respuesta a Incidentes y Análisis Forense (DFIR)
Módulo 4 de 12

Módulo 4: Detección, triaje e identificación del incidente

Módulo 4: Detección, triaje e identificación del incidente

Aviso ético y legal: las consultas, indicadores y técnicas de este módulo se explican con fines exclusivamente educativos y de defensa. Aplícalas únicamente en sistemas, redes y telemetría sobre los que tengas autorización explícita (tu propio laboratorio, un entorno corporativo con mandato formal, o una plataforma de práctica legal como un CTF o un rango de ciberdefensa). Analizar registros, endpoints o cuentas de terceros sin autorización es ilegal en España conforme a los artículos 197 y 264 del Código Penal, además de constituir una violación grave de la ética profesional DFIR. Todos los IOC, hashes, IP y dominios de ejemplo en este módulo son ficticios o pertenecen a rangos reservados para documentación (RFC 5737) salvo que se indique lo contrario.

Qué aprenderás

  • Las fuentes de detección habituales en un SOC maduro (SIEM, EDR, NDR/IDS, reportes de usuario, threat intelligence) y qué aporta cada una a la fase de Detection & Analysis de NIST SP 800-61r2.
  • La diferencia técnica entre Indicador de Compromiso (IOC) e Indicador de Ataque (IOA), con ejemplos concretos, y por qué el IOA es más resiliente frente a la evasión del adversario.
  • Un proceso de triaje reproducible: priorizar alertas combinando severidad, fiabilidad de la fuente y criticidad del activo.
  • Cómo reducir falsos positivos y fatiga de alertas sin perder cobertura de detección.
  • Enriquecimiento de indicadores con VirusTotal, AbuseIPDB, WHOIS y threat intelligence, con sus limitaciones.
  • Cómo construir una timeline inicial y acotar (scoping) el alcance real de un compromiso.
  • Criterios para declarar formalmente un incidente y escalarlo, y formatos de intercambio (STIX/TAXII, OpenIOC, MISP).
  • Consultas reales de detección en Splunk SPL y Microsoft Sentinel KQL.

1. La fase de Detección y Análisis en el ciclo de respuesta a incidentes

NIST SP 800-61r2 estructura la respuesta a incidentes en cuatro fases: Preparación; Detección y Análisis; Contención, Erradicación y Recuperación; y Actividad Post-Incidente. Este módulo cubre la segunda fase, que la propia guía describe como la más difícil de estandarizar porque el volumen y la fiabilidad de precursores e indicadores varía enormemente entre organizaciones e incidentes.

Un error frecuente en equipos junior es tratar la «detección» como un evento puntual —una alerta salta, se investiga, se cierra— en lugar de un proceso continuo de acumulación de evidencia. Un incidente real casi nunca se anuncia con una alerta inequívoca; se construye a partir de múltiples señales débiles que, correlacionadas, superan el umbral de sospecha razonable. El objetivo de este módulo es dotarte del marco mental y las herramientas técnicas para pasar de «señal aislada» a «caso justificado» de forma rápida y defendible.

2. Fuentes de detección

Ninguna fuente de detección es suficiente por sí sola; lo que resulta caro de evadir para el atacante es la combinación correlada de varias fuentes independientes.

2.1 SIEM

Centraliza logs de múltiples fuentes (firewalls, servidores, controladores de dominio, proxies, VPN, aplicaciones) y correla mediante reglas de detección (use cases) o analytics. Su valor está en la visión agregada: un logon fallido aislado no dice nada, pero 400 logons fallidos contra 60 cuentas desde una misma IP en 3 minutos sí. Plataformas típicas: Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security. Limitación clave: el SIEM es tan bueno como los logs que recibe — si Sysmon no está desplegado, si la auditoría avanzada de Windows (Process Creation, Logon, PowerShell Script Block Logging) no está habilitada, o si la retención es de 7 días cuando el atacante llevaba 40 dentro, no puede detectar lo que nunca recibió.

2.2 EDR

El EDR (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Carbon Black) instrumenta el endpoint: creación de procesos, inyección de memoria, modificaciones de registro, llamadas a API, conexiones de red por proceso. Su ventaja sobre el SIEM tradicional es la granularidad y la capacidad de aislamiento en tiempo real. Muchos EDR incorporan motores de IOA nativos (comportamiento, no firma) — el tema de la sección 3.

2.3 NDR/IDS/IPS

Snort, Suricata, Zeek, o soluciones NDR comerciales (Darktrace, ExtraHop, Corelight) analizan tráfico de red por firmas o por comportamiento/ML. Son valiosos para detectar movimiento lateral, exfiltración y C2 que no dejan rastro claro en el endpoint: un atacante que usa binarios legítimos del sistema (LOLBins) puede pasar desapercibido para el EDR si el proceso no es anómalo, pero el patrón de tráfico (beaconing periódico, volumen asimétrico, DNS tunneling) sí lo delata.

2.4 Alertas de usuarios

El Verizon DBIR y otros informes sitúan el phishing reportado por empleados como una de las fuentes de detección más rentables: no requiere licencia, se activa antes que muchos controles automatizados y aporta contexto humano. Un botón de «Reportar phishing» bien integrado, con SLA de triaje rápido, es uno de los mejores ROI en detección temprana.

2.5 Threat Intelligence (CTI)

Los feeds de inteligencia —comerciales (Recorded Future, Mandiant Advantage), de comunidad (OTX de AlienVault) o gubernamentales (CCN-CERT, INCIBE-CERT)— aportan indicadores concretos para matching retrospectivo y contexto de TTP de actores concretos que permite anticipar qué buscar aunque no exista todavía un IOC específico. Esta función conecta directamente con el IOA.

3. IOC vs IOA: la distinción que define la madurez de tu detección

3.1 Indicador de Compromiso (IOC)

Un IOC es evidencia forense estática de que un compromiso ya ha ocurrido: un hash de fichero, una IP, un dominio, una clave de registro, una regla YARA que matchea un binario específico. Es útil para búsquedas retrospectivas, compartir inteligencia de forma inequívoca (STIX, feeds MISP) y bloqueo automatizado en firewall/proxy/EDR.

Ejemplos de IOC:

  • Hash SHA-256 a1b2c3d4e5f6... de una muestra conocida de Cobalt Strike Beacon.
  • IP 203.0.113.45 (RFC 5737) identificada como C2 de una campaña de ransomware.
  • Dominio update-service-cdn[.]net usado como staging de phishing.
  • Clave de registro HKCUSoftwareMicrosoftWindowsCurrentVersionRunSysHelper creada por un loader para persistencia.
  • Mutex único Global\a3f8e91c-persist creado por una familia de malware concreta para evitar reinfección.

El problema de los IOC es su fragilidad. David Bianco lo formalizó en su «Pyramid of Pain» (2013): un hash cambia con recompilar un byte; una IP cambia alquilando otra VPS; un dominio cambia registrando otro. El coste para el atacante de invalidar un IOC es casi cero. Detectar solo por IOC te condena a ir siempre un paso por detrás.

3.2 Indicador de Ataque (IOA)

Un IOA es un patrón de comportamiento o intención, independiente de la herramienta usada. No pregunta «¿es este hash malicioso?» sino «¿este proceso se comporta como lo haría un atacante en esta fase de la kill chain, sea cual sea el binario?». CrowdStrike, que popularizó el término, lo resume así: los IOA detectan la intención del atacante y el resultado que persigue, sea cual sea el malware o exploit utilizado.

Ejemplos de IOA:

  • Dumping de credenciales: un proceso abre un handle con lectura de memoria (PROCESS_VM_READ) sobre lsass.exe sin ser un producto de seguridad conocido. Detecta Mimikatz, procdump abusado o herramientas custom nunca vistas: el comportamiento es el mismo.
  • Living-off-the-land sospechoso: certutil.exe con -urlcache o -decode desde un proceso padre inusual (por ejemplo, Microsoft Word).
  • Escalada de privilegios vía token: proceso de baja integridad que crea un proceso con token SYSTEM sin pasar por UAC.
  • Movimiento lateral clásico: ejecución remota vía WMI (Win32_Process.Create) o PsExec seguida en segundos de un servicio nuevo con nombre aleatorio en el host destino.
  • Reconocimiento de dominio: secuencia rápida de nltest /domain_trusts, net group "domain admins" /domain y LDAP masivo desde una estación que nunca administró el dominio.

Evadir un IOA bien diseñado exige «cambiar de táctica por completo», no un byte — mucho más caro para el adversario. Por eso los marcos modernos (Sigma rules, detection engineering guiado por MITRE ATT&CK) se orientan a comportamiento, no a artefactos.

3.3 Por qué necesitas ambos, en capas

Los IOC son rápidos de desplegar, con falsos positivos casi nulos, ideales para respuesta táctica y threat hunting retrospectivo. Los IOA requieren más ingeniería (umbrales, tuning), más riesgo de falso positivo si están mal calibrados, pero detectan amenazas nunca vistas y son mucho más duraderos. La tabla siguiente compara ambos por fiabilidad (confianza ante una coincidencia positiva) y longevidad (tiempo útil antes de quedar obsoletos):

Tipo de indicador Ejemplo Fiabilidad Longevidad
Hash de fichero (SHA-256/MD5) 44d88612fea8a8f36de82e1278abb02f Muy alta (match exacto) Muy baja (invalidado al recompilar)
Dirección IP 198.51.100.23 (RFC 5737) Media (IP compartidas, NAT) Baja (horas-días; hosting barato)
Dominio secure-login-portal[.]info Media-alta Baja-media (días-semanas)
Herramienta de ataque / infraestructura C2 Framework Cobalt Strike/Sliver con perfil malleable identificado Alta Media (semanas-meses)
TTP / técnica (IOA de comportamiento) Acceso de lectura de memoria a LSASS desde proceso no confiable Alta si está calibrado Muy alta (meses-años)
Objetivos / TTP de alto nivel del actor Preferencia por RDP expuesto + VPN sin MFA como acceso inicial Alta a nivel estratégico Muy alta (años; «modus operandi»)

Esta tabla resume, en esencia, la Pyramid of Pain de David Bianco: cuanto más subes hacia TTP, más caro le resulta al atacante evadirte.

4. Proceso de triaje y priorización de alertas

Un SOC de tamaño medio recibe entre cientos y decenas de miles de alertas diarias. Es imposible investigar todas con el mismo nivel de profundidad. El triaje es el proceso disciplinado de decidir, en segundos o pocos minutos, cuáles merecen escalado inmediato, cuáles van a cola normal y cuáles se cierran justificadamente.

4.1 Los tres ejes de priorización

  1. Severidad técnica: impacto si la alerta es verdadero positivo. «Ejecución de ransomware conocido» pesa más que «escaneo de puertos detectado».
  2. Fiabilidad de la fuente/regla: histórico de esa regla concreta. Una regla con 2% de FP históricos merece más crédito que una con 80%. Requiere trackear la tasa de verdadero/falso positivo por regla, no solo por herramienta.
  3. Contexto y criticidad del activo: la misma alerta tiene prioridad radicalmente distinta en un controlador de dominio que en un portátil de pruebas aislado. Exige un inventario de activos con clasificación de criticidad (CMDB) integrado con el SIEM/SOAR.

Ejemplo de matriz: severidad alta + fiabilidad alta + activo crítico = escalado inmediato a IR; severidad media + fiabilidad baja + activo no crítico = cola estándar (SLA 4-8h); severidad baja + fiabilidad muy baja = revisión en lote, candidato a supresión si se confirma benigno de forma consistente.

4.2 El flujo de triaje paso a paso

  1. Ingesta y deduplicación: agrupar alertas relacionadas (mismo host, mismo actor, ventana temporal corta) en un único caso.
  2. Contextualización rápida: ¿qué activo es? ¿quién es el usuario? ¿está de viaje según RRHH (relevante para «impossible travel»)? ¿hay ventana de mantenimiento que explique el ruido?
  3. Verificación técnica mínima: confirmar que el evento ocurrió tal y como describe la alerta, revisando el log crudo.
  4. Enriquecimiento de indicadores (sección 5): reputación de IP/dominio/hash antes de decidir.
  5. Decisión de triaje: escalar, investigar en profundidad, o cerrar como falso positivo documentado con justificación explícita.

4.3 Reducción de falsos positivos y fatiga de alertas

La fatiga de alertas erosiona la atención del analista, aumentando el riesgo de que una alerta crítica se cierre por inercia. Es uno de los mayores riesgos operativos de un SOC: más incidentes graves se han escalado tarde por «ya habíamos visto esa alerta cien veces y siempre era ruido» que por falta de tecnología.

Estrategias efectivas:

  • Tuning continuo: reglas con FP sostenido por encima de un umbral (por ejemplo, >90% durante 30 días) deben recalibrarse o suprimirse.
  • Excepciones documentadas y con caducidad: si un proceso legítimo dispara ruido recurrente, se documenta con fecha de revisión, no «para siempre» sin trazabilidad.
  • Correlación y agregación (SOAR): fusionar alertas relacionadas en un único caso reduce volumen sin perder señal.
  • Enriquecimiento automático pre-triaje: si el SOAR ya adjunta reputación y contexto antes de que el humano vea la alerta, el tiempo de decisión baja de minutos a segundos.
  • Priorización por riesgo, no por FIFO: trabajar por score de prioridad evita que una alerta crítica quede detrás de cien triviales más antiguas.

5. Consultas reales de detección: Splunk SPL y Microsoft Sentinel KQL

Las siguientes consultas implementan los IOA de la sección 3 sobre esquemas estándar (Windows Security/Sysmon vía Splunk, tablas nativas de Sentinel/Defender). Ajusta índices, macros y nombres de tabla a tu entorno antes de desplegarlas.

5.1 Splunk SPL — Event ID 4688 con líneas de comando sospechosas (LOLBin)

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4688
| rex field=New_Process_Name "(?<proc_name>[^\\]+)$"
| where match(proc_name, "(?i)(certutil|bitsadmin|mshta|regsvr32|rundll32|wscript|cscript).exe")
    AND match(Process_Command_Line, "(?i)(-urlcache|-decode|http|/transfer|javascript:|scrobj.dll)")
| eval risk_note="LOLBin con parametros de descarga/decodificacion remota"
| table _time, Computer, Account_Name, proc_name, Creator_Process_Name, Process_Command_Line, risk_note
| sort -_time

Busca binarios firmados y legítimos de Windows invocados con parámetros propios de descarga o decodificación remota. Es IOA porque no depende de un hash concreto, sino de la combinación anómala herramienta+parámetro+intención.

5.2 Splunk SPL — Acceso sospechoso a memoria de LSASS (credential dumping)

index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10
    TargetImage="*\lsass.exe"
| where NOT match(SourceImage, "(?i)(MsMpEng.exe|CrowdStrike|SentinelAgent|TaniumClient|procexp)")
| where match(GrantedAccess, "0x1010|0x1410|0x1438|0x143a|0x1fffff")
| eval risk_note="Handle de lectura de memoria sobre LSASS desde proceso no confiable"
| table _time, Computer, SourceImage, SourceProcessId, TargetImage, GrantedAccess, risk_note
| sort -_time

El Event ID 10 de Sysmon (ProcessAccess) registra cada handle que un proceso abre sobre otro. Filtrar accesos de lectura de memoria (PROCESS_VM_READ) hacia lsass.exe, excluyendo procesos legítimos conocidos, es una de las detecciones de IOA con mejor relación señal/ruido de todo el arsenal de un SOC.

5.3 Splunk SPL — Logons anómalos («impossible travel»)

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=10
| iplocation src_ip
| stats dc(src_ip) AS ips_distintas, dc(Country) AS paises_distintos,
        values(Country) AS paises, earliest(_time) AS primera, latest(_time) AS ultima
        by Account_Name
| where ips_distintas > 3 AND paises_distintos > 1
| eval ventana_min=round((ultima-primera)/60,1)
| where ventana_min < 120
| eval risk_note="Logons RDP desde multiples paises en ventana corta"
| table Account_Name, ips_distintas, paises_distintos, paises, ventana_min, risk_note
| sort -ips_distintas

Agrega logons RDP (Logon_Type=10) por cuenta y detecta cuándo una identidad autentica desde varios países en una ventana incompatible con desplazamiento físico real — patrón clásico de credenciales comprometidas usadas simultáneamente por atacante y usuario legítimo.

5.4 Microsoft Sentinel KQL — Creación de proceso sospechosa (equivalente LOLBin)

DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("certutil.exe","bitsadmin.exe","mshta.exe","regsvr32.exe","rundll32.exe","wscript.exe","cscript.exe")
| where ProcessCommandLine has_any ("-urlcache","-decode","http://","https://","/transfer","javascript:","scrobj.dll")
| where InitiatingProcessFileName !in~ ("MsMpEng.exe","SenseIR.exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

5.5 Microsoft Sentinel KQL — Acceso a LSASS (Microsoft Defender for Endpoint)

DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == "OpenProcessApiCall"
| where TargetProcessFileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ ("MsMpEng.exe","SenseIR.exe","procexp64.exe","procexp.exe")
| extend GrantedAccessHex = tostring(AdditionalFields.GrantedAccess)
| where GrantedAccessHex in ("0x1010","0x1410","0x1438","0x143a","0x1fffff")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName,
          InitiatingProcessFolderPath, GrantedAccessHex
| order by Timestamp desc

5.6 Microsoft Sentinel KQL — Logons anómalos multi-país («impossible travel»)

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize IPsDistintas = dcount(IPAddress),
            PaisesDistintos = dcount(tostring(LocationDetails.countryOrRegion)),
            Paises = make_set(tostring(LocationDetails.countryOrRegion)),
            Primera = min(TimeGenerated), Ultima = max(TimeGenerated)
          by UserPrincipalName
| extend VentanaMin = datetime_diff('minute', Ultima, Primera)
| where IPsDistintas > 2 and PaisesDistintos > 1 and VentanaMin < 120
| project UserPrincipalName, IPsDistintas, PaisesDistintos, Paises, VentanaMin
| order by IPsDistintas desc

Las tres parejas SPL/KQL implementan la misma lógica de IOA sobre esquemas distintos: ilustra por qué el IOA es más portable y duradero que el IOC — la lógica de detección sobrevive al cambio de plataforma porque describe comportamiento, no un valor a buscar en una lista de bloqueo.

6. Enriquecimiento de indicadores

Identificado un indicador candidato, el siguiente paso es contrastarlo contra fuentes externas de reputación e inteligencia para aumentar o reducir la confianza en que sea malicioso.

VirusTotal: consulta hashes, URL, dominios e IP contra decenas de motores y sandboxes. Presta atención no solo al ratio de detecciones, sino a si varios motores coinciden en la misma familia, a la fecha de primera aparición (first seen) y a las relaciones (qué otros dominios/IP contactó la muestra en sandbox).

AbuseIPDB: base colaborativa de reportes de abuso de IP. El «Abuse Confidence Score» debe interpretarse con cautela: IP de cloud compartida (AWS, Azure) pueden arrastrar reportes históricos de un inquilino anterior. Contrasta siempre con la fecha de los reportes recientes, no solo el score agregado.

WHOIS: la fecha de registro de un dominio es una señal barata y fiable — un dominio registrado hace 4 días y ya usado para facturas falsas es sistemáticamente sospechoso. Presta atención también al registrador y al patrón de typosquatting contra tu propio dominio.

Threat Intelligence Platforms: MISP, OpenCTI o feeds comerciales permiten ver si un indicador forma parte de un cluster ya atribuido a un actor o campaña conocida, con su contexto de TTP asociado.

Limitaciones: nunca subas ficheros o datos sensibles a servicios públicos como VirusTotal sin evaluar la confidencialidad — un fichero subido en el tier estándar queda accesible a terceros, incluido potencialmente el atacante monitorizando si su muestra fue detectada. Un resultado «limpio» no es prueba de inocencia, solo ausencia de detección previa: es lo esperable en la primera hora de una campaña nueva. El enriquecimiento respalda la decisión, no la sustituye.

7. Construcción de la timeline inicial y scoping

Superado el umbral de sospecha razonable, el objetivo deja de ser «confirmar sí/no» y pasa a acotar el alcance real del compromiso — el scoping. Un scoping deficiente es, junto con el tunnel vision (sección 11), la causa más frecuente de incidentes mal gestionados: se contiene y se cierra un host mientras el atacante mantiene persistencia en otros que nadie llegó a mirar.

7.1 Qué preguntas debe responder el scoping

  • ¿Qué equipos están afectados? No solo el host de la alerta original, sino cualquier sistema con acceso demostrable o de alta probabilidad (movimiento lateral, credenciales reutilizadas).
  • ¿Qué cuentas están comprometidas? Distingue la cuenta de acceso inicial de cualquier cuenta adicional obtenida por escalada o dumping — incluidas cuentas de servicio, que rara vez rotan contraseña.
  • ¿Qué datos han podido ser accedidos, modificados o exfiltrados? Cruza el acceso con la clasificación de datos de los sistemas tocados.
  • ¿Cuál es la ventana temporal real? No asumas que el primer evento visto en el SIEM es el primer evento ocurrido — retención de logs, despliegue tardío de EDR o desactivación de logging por el atacante pueden ocultar actividad anterior.

7.2 Construcción práctica de la timeline

La timeline es un documento vivo y cronológico con cada evento confirmado (no supuesto) y su fuente: marca de tiempo con zona horaria explícita, host/activo, cuenta, acción observada, fuente (log/herramienta/ID de evento) y nivel de confianza (confirmado vs. hipótesis).

La técnica más eficaz es trabajar en dos direcciones: hacia atrás (root cause: vector de acceso inicial, primer host tocado, persistencia instalada) y hacia delante/lateral (blast radius: qué más pudo alcanzar el atacante). Herramientas típicas: pivoting en SIEM/EDR por cuenta y host, logs de autenticación (Kerberos/NTLM, Azure AD Sign-in), timelining forense de disco (Plaso/log2timeline, KAPE) y grafos de relaciones en la plataforma XDR.

7.3 Cuándo el scoping es «suficiente» (que no es «completo»)

El scoping nunca es absolutamente completo, pero se considera suficiente para pasar a contención cuando: se identificó el vector de acceso inicial con evidencia razonable, se enumeraron hosts y cuentas con evidencia directa de compromiso, se revisó el histórico de actividad de esas cuentas/hosts en la ventana estimada, y se evaluó explícitamente si hay indicios de movimiento lateral hacia sistemas críticos o exfiltración.

8. Criterios para declarar formalmente un incidente y escalarlo

No toda alerta confirmada como verdadero positivo constituye automáticamente un «incidente» formal. NIST SP 800-61r2 define un incidente como una violación o amenaza inminente de violación de las políticas de seguridad o prácticas estándar. Declararlo formalmente activa un proceso —notificación a partes interesadas, posibles obligaciones bajo RGPD/LOPDGDD con la AEPD como autoridad competente, asignación de IR Lead, paso a Contención— por lo que el criterio debe estar predefinido en el plan de IR, no improvisado caso a caso.

Criterios típicos:

  • Confirmación de acceso no autorizado con evidencia directa (no solo indicios).
  • Evidencia de ejecución de malware con capacidad de propagación, cifrado o exfiltración.
  • Indicios razonables de exfiltración de datos sensibles, regulados o de propiedad intelectual.
  • Compromiso de cuentas privilegiadas (administradores de dominio, cuentas de servicio amplias).
  • Cualquier actividad que, en su peor escenario razonable, tendría impacto material en negocio o cumplimiento — «principio de precaución escalado»: ante duda razonable con impacto potencial alto, se escala y se desescala después si el scoping lo descarta, nunca al revés.

El escalado sigue la matriz RACI del plan de IR: quién es notificado, en qué plazo, con qué información mínima (resumen del hallazgo, alcance conocido, contención ya tomada) y por qué canal — idealmente uno que no dependa de la infraestructura potencialmente comprometida.

9. Formatos de intercambio de inteligencia: STIX/TAXII, OpenIOC, MISP

STIX/TAXII: STIX es un lenguaje estructurado (JSON en 2.x) para representar información de amenazas rica: no solo indicadores aislados, sino actores, campañas, TTP (mapeadas a MITRE ATT&CK) y sus relaciones. TAXII es el protocolo de transporte para intercambiar contenido STIX entre plataformas de forma automatizada. Es el estándar de facto de la industria, usado por la mayoría de ISAC/ISAO sectoriales.

OpenIOC: formato XML de Mandiant orientado a indicadores forenses de host (registro, ficheros, procesos, memoria) consumibles por herramientas de barrido. Ha perdido tracción frente a STIX/YARA/Sigma, pero sigue presente en herramientas legacy e informes antiguos.

MISP: plataforma open source y, de facto, formato/modelo de datos para compartir indicadores entre organizaciones y comunidades (en España, coordinadas con INCIBE-CERT y CCN-CERT). Exporta/importa STIX, OpenIOC, CSV o JSON nativo, con correlación automática y control de nivel de confianza vía TLP (Traffic Light Protocol: RED, AMBER, GREEN, CLEAR).

Para un analista de triaje, lo relevante no es memorizar la sintaxis exacta de cada formato, sino saber qué formato esperar de cada fuente e integrarlo en el flujo de enriquecimiento del SOC.

10. Laboratorio: triar un conjunto de alertas de ejemplo y construir una mini-timeline

Laboratorio autocontenido, realizable sobre papel/editor de texto. Dispones de cinco alertas ficticias generadas en 90 minutos en una organización simulada.

# Hora (UTC) Fuente Descripción Activo
A1 09:02 Email Gateway Usuario jgarcia reporta correo con enlace a «factura-pendiente-urgente[.]top» vía botón de phishing Portátil jgarcia (Finanzas)
A2 09:14 EDR Proceso rundll32.exe con línea de comando javascript: lanzado desde WINWORD.EXE, proceso padre inusual Portátil jgarcia (Finanzas)
A3 09:16 EDR Lectura de memoria sobre lsass.exe desde rundll32.exe no firmado por Microsoft en esa ruta Portátil jgarcia (Finanzas)
A4 10:05 SIEM (4624 tipo 3) Autenticación de red con cuenta de servicio svc-backup-fin hacia el file server desde el portátil de jgarcia — esa cuenta nunca había autenticado desde un endpoint de usuario FIN-FS01
A5 10:31 NDR Transferencia saliente de 380 MB desde FIN-FS01 a IP externa 198.51.100.77 nunca antes contactada, fuera de ventana de backups FIN-FS01

10.1 Instrucciones

  1. Clasifica cada alerta como IOC, IOA o precursor/reporte humano, y asigna prioridad (alta/media/baja) razonando por los tres ejes del apartado 4.1.
  2. Identifica qué alertas, aisladas, podrían descartarse erróneamente como falso positivo, y por qué el contexto conjunto cambia esa conclusión.
  3. Construye una mini-timeline ordenada cronológicamente indicando, para cada entrada: hipótesis dentro de la kill chain (acceso inicial, ejecución, credential access, movimiento lateral, exfiltración) y nivel de confianza (confirmado / alta probabilidad / hipótesis).
  4. Redacta en 4-6 líneas el scoping mínimo que abrirías: qué otros hosts/cuentas revisarías y por qué.
  5. Decide, con justificación, si esto cumple los criterios de declaración formal del apartado 8, y a quién escalarías y con qué urgencia.

10.2 Guía de solución razonada

(No la leas hasta completar tu propio razonamiento.)

A1 es un precursor humano de fiabilidad media-alta; aislada, prioridad media. A2 es IOA claro (LOLBin con scripting desde Office); aislada podría descartarse como falso positivo de una macro legítima sin correlacionar con A1. A3 es el IOA de mayor peso individual (acceso a LSASS): por sí sola justifica escalado alto. La secuencia A1→A2→A3 en 14 minutos sobre el mismo activo elimina la duda de coincidencia: kill chain de acceso inicial (phishing) → ejecución → credential access, confianza alta.

A4 es donde un scoping deficiente falla: aislada, «una cuenta de servicio autentica contra el file server» parece ruido normal si no se cruza que nunca lo había hecho desde un endpoint de usuario, y ocurre 49 minutos después del dumping confirmado en A3. Es movimiento lateral con credenciales robadas, alta probabilidad. A5 confirma exfiltración de alta probabilidad: volumen inusual, destino nunca contactado, fuera de ventana de backup, sobre el activo que acaba de recibir el logon anómalo.

Scoping mínimo inmediato: (a) histórico de svc-backup-fin en 90 días; (b) todo host/recurso con permisos para esa cuenta, no solo FIN-FS01; (c) si jgarcia tiene acceso a otros sistemas críticos que expliquen el robo de esas credenciales; (d) bloqueo/monitorización de 198.51.100.77 en el perímetro. Con dumping confirmado, movimiento lateral y exfiltración de alta probabilidad sobre Finanzas, esto cumple los criterios del apartado 8: escalado inmediato al IR Lead, con contención del host origen y del file server en paralelo al scoping.

11. Errores comunes

  • Cerrar como falso positivo sin completar el scoping: el error más costoso. Confirmar que «esta alerta» es benigna no equivale a confirmar que «no ha pasado nada» en el activo o la cuenta implicados.
  • Tunnel vision (visión de túnel): centrarse en la primera hipótesis plausible e ignorar evidencia que sugiere mayor alcance. Especialmente peligroso cuando la alerta «encaja» con un patrón conocido y el analista deja de buscar movimiento lateral o exfiltración fuera de ese guion.
  • Confiar ciegamente en la severidad por defecto de la herramienta sin contextualizar con la criticidad real del activo — una alerta «media» en un controlador de dominio puede ser más urgente que una «alta» en un equipo de pruebas aislado.
  • Ignorar la zona horaria al correlacionar fuentes distintas (SIEM en UTC, logs de aplicación en hora local, reporte del usuario en su propia hora) — puede invertir el orden causal aparente de la timeline.
  • Sobre-indexar en IOC y descuidar el IOA — un programa que solo bloquea hashes e IP conocidas siempre va un paso por detrás de un adversario que rota infraestructura y recompila trivialmente.
  • No documentar el razonamiento del triaje — cerrar con un simple «FP» sin registrar por qué imposibilita el tuning posterior y elimina trazabilidad si la alerta reaparece con contexto distinto.
  • Escalar tarde por miedo a «dar una falsa alarma» — el coste de escalar un incidente que se desescala tras el scoping es órdenes de magnitud menor que no escalar uno real a tiempo.

12. Ejercicio

Diseña, en una o dos páginas, una matriz de triaje para una organización ficticia de tu elección (por ejemplo, una PYME de comercio electrónico con 80 empleados, o una clínica con datos de pacientes). Debe incluir:

  1. Al menos tres niveles de prioridad (P1/P2/P3) con criterios explícitos de severidad, fiabilidad de fuente y criticidad de activo para cada nivel.
  2. Al menos cinco tipos de activo clasificados por criticidad (por ejemplo: servidor de base de datos de clientes = crítico; portátil de becario = bajo).
  3. Al menos tres reglas de detección concretas (puedes basarte en las consultas SPL/KQL de la sección 5) con su SLA de investigación según prioridad.
  4. Un criterio explícito y por escrito de cuándo una alerta cumple los requisitos de declaración formal de incidente, a quién se escala y en qué plazo máximo.

Extensión opcional: convierte una de tus reglas en una regla Sigma (YAML agnóstico de plataforma) para practicar la portabilidad de la lógica de detección — el mismo principio ilustrado en la sección 5 al comparar SPL y KQL.

Preguntas frecuentes

¿Cuál es la diferencia práctica más importante entre un IOC y un IOA a la hora de escribir una regla de detección?

Un IOC produce una regla de coincidencia exacta contra una lista (este hash, esta IP, este dominio) que hay que actualizar constantemente porque el atacante la invalida con un cambio trivial. Un IOA produce una regla de patrón de comportamiento que sigue siendo válida aunque el atacante cambie de herramienta, porque describe la táctica, no el artefacto. Un programa maduro combina ambos: IOC para bloqueo táctico inmediato, IOA como columna vertebral de la detección proactiva.

¿Cómo se mide objetivamente si una regla de detección genera demasiados falsos positivos?

Trackeando, por regla individual, la proporción de alertas cerradas como verdadero positivo frente a falso positivo/benigno documentado, en una ventana representativa (30-90 días). Reglas con FP sostenido por encima de un umbral definido deben entrar en un ciclo de recalibración: ajustar el umbral, añadir exclusiones documentadas, o combinarlas con una segunda condición que reduzca ruido sin perder la señal original.

¿Es aceptable cerrar una alerta como falso positivo sin scoping si la explicación parece obvia («es una herramienta de IT conocida»)?

Solo si esa explicación está verificada, no asumida: ruta de fichero correcta, firma digital válida, horario coherente con el uso habitual, cuenta ejecutora autorizada. Un atacante que nombra su malware svchost.exe cuenta precisamente con que el analista reconozca el nombre y cierre sin verificar. La «obviedad» de una explicación no exime de la verificación mínima, solo determina cuánto tiempo dedicarle.

¿Qué relación hay entre el triaje de alertas y el framework MITRE ATT&CK?

ATT&CK proporciona el vocabulario común de tácticas y técnicas que permite situar cada alerta dentro de una kill chain más amplia en lugar de evaluarla aislada. Mapear una alerta a una técnica concreta (por ejemplo, T1003.001 para dumping de LSASS) facilita tanto la priorización como la comunicación entre analistas y con threat intelligence, usando una taxonomía estandarizada.

¿Por qué es tan importante especificar la zona horaria al construir una timeline de incidente?

Porque distintas fuentes registran habitualmente en zonas horarias distintas por defecto (UTC en SIEM y cloud, hora local en logs on-premise, hora del dispositivo en reportes manuales), y un desfase de pocas horas sin normalizar puede invertir el orden causal aparente entre dos eventos. La buena práctica es normalizar toda la timeline a UTC desde el primer borrador y anotar la zona horaria original de cada fuente.

Fuente citada

«Precursors and indicators are identified using many different sources: computer security software alerts, logs (e.g., audit, firewall, IDS/IPS, application, service, network device, netflow), publicly available information on new vulnerabilities and exploits, and people both inside and outside the organization. […] Determining whether a particular event is actually an incident is sometimes a matter of judgment. It may be necessary to collaborate with other technical and information security personnel to make a decision.»

— NIST Special Publication 800-61 Revision 2, «Computer Security Incident Handling Guide», sección 3.2 «Detection and Analysis».