Parte: 8 — Blue Team, detección y SOC · Fuente: The Practice of Network Security Monitoring — Bejtlich · Applied NSM — Sanders y Smith ⏱️ Duración estimada: 120 min · Nivel: Avanzado
Integrar todo lo aprendido en la parte resolviendo casos realistas de detección de principio a fin: desde el compromiso inicial hasta la exfiltración, reconstruyendo la cadena de ataque con telemetría de endpoint y red, mapeándola a ATT&CK y proponiendo las detecciones que la habrían atrapado antes. Es la clase de síntesis práctica del blue team.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Método de análisis de caso | Estructura para no perderse |
| 2 | Caso 1: phishing → ejecución → persistencia | Cadena de intrusión típica |
| 3 | Caso 2: movimiento lateral → dominio | Escalada y propagación |
| 4 | Caso 3: C2 → exfiltración | Salida de datos |
| 5 | Reconstrucción de línea de tiempo | Ordenar los hechos |
| 6 | Mapeo a ATT&CK | Vocabulario y cobertura |
| 7 | Puntos de detección perdidos | Dónde mejorar |
| 8 | Lecciones aprendidas y reporte | Cerrar el ciclo |
Un caso defensivo reconstruye decisiones desde evidencia, no una narración retrospectiva perfecta. Cada elemento se marca como hecho observado, inferencia sustentada o hipótesis pendiente. Fuente, consulta, zona horaria y adquisición permiten reproducir el razonamiento.
Se distinguen hora del evento, registro e ingesta para ordenar eventos tardíos. Una detección ausente se clasifica: fuente no recolectada, parser defectuoso, analítica inexistente, alerta no creada o triaje incorrecto. Esa clasificación asigna una corrección concreta. ATT&CK se aplica después de comprender evidencia. Para comparar cambios se conserva dataset, versión, consulta y resultado esperado.
Un caso empieza con preguntas: qué entidad actuó, qué activo fue afectado, qué cambió y qué evidencia falta. La línea de tiempo reúne eventos con procedencia; el grafo conecta usuarios, procesos, archivos, hosts y destinos. Primero se anotan hechos —un evento con campos concretos—; después inferencias —dos eventos probablemente pertenecen a la misma sesión—; por último hipótesis que aún requieren contraste.
Esta separación evita retrospectiva perfecta. Sabiendo el resultado, es fácil interpretar toda anomalía como señal evidente. El analista debe registrar qué podía conocerse en ese momento y qué consulta reveló el siguiente dato. Una explicación alternativa se prueba: una conexión rara puede ser actualización; un proceso firmado puede haber sido abusado. La fuerza del caso surge de corroboración, no de narrativa dramática.
Splunk Boss of the SOC ofrece datasets y preguntas de investigación para practicar; EVTX-ATTACK-SAMPLES reúne eventos útiles para probar artefactos. Son materiales de laboratorio, no prueba de rendimiento universal. Se fija versión o commit, se preserva archivo y hash, se documentan zona horaria, parser y consulta. Si se modifica una regla, se repite exactamente la misma muestra y se comparan positivos, negativos y coste.
ATT&CK se aplica después de entender el comportamiento. Mapear una ejecución a una técnica no añade evidencia; ofrece vocabulario para comunicar. El caso debe explicar qué procedimiento y campos justifican el mapeo y qué partes no se observaron.
Una alerta perdida se localiza en la cadena. Si el origen nunca generó dato, se corrige instrumentación; si llegó sin campos, parser; si la consulta no coincidió, lógica; si coincidió pero no creó notable, programación; si el notable fue cerrado mal, runbook o formación. Decir simplemente «el SIEM falló» no asigna una intervención verificable.
El producto final incluye timeline, entidades, hallazgos, incertidumbres, causa del gap, cambio propuesto y prueba de regresión. Un buen caso enseña tanto por qué se detectó como por qué pudo no detectarse.
El correo aporta entrega y URL/adjunto; proxy o navegador apoya descarga; endpoint demuestra proceso; tareas/registro muestran persistencia. El orden no se presume: se normalizan tiempos y se enlazan entidades. Una detección puede existir en ejecución y faltar en persistencia. El informe distingue qué etapa se observó y qué fuente no estaba disponible.
Una cuenta privilegiada aparece desde una estación hacia un servidor, luego el servidor inicia conexiones a otros activos. El grafo revela que el destino se convirtió en origen. Se comparan rutas administrativas y eventos de servicio remoto. Si el SOC solo agrupó por host inicial, el gap está en correlación/alcance, no necesariamente en ausencia de alertas individuales.
Una relación periódica evoluciona hacia transferencia saliente. Flow demuestra volumen y destino; endpoint vincula proceso; clasificación del dato requiere fuente adicional. No se llama exfiltración solo por bytes. La hipótesis se fortalece si aparecen preparación de archivos, proceso inesperado y destino sin justificación, pero el informe conserva el término «posible» cuando el contenido no puede confirmarse.
Estos tres casos no son historias para memorizar. Enseñan a mover la unidad de análisis: evento, secuencia, entidad, grafo y decisión. Los datasets permiten reproducir el razonamiento, y el reporte explica también alternativas descartadas.
Un dataset controlado contiene documento, intérprete y conexión. La timeline confirma los tres hechos. En el SIEM existen proceso y red, pero la regla no alertó. Se ejecuta la consulta contra el evento y se descubre que esperaba process.parent.name, mientras el pipeline pobló otro campo.
La clasificación es «mapeo/parser», no «regla inexistente». Se corrige el pipeline o contrato, se reindexa la muestra cuando procede y se ejecutan fixtures. Después se verifica notable y triaje. El mapa ATT&CK se actualiza solo cuando la cadena completa queda probada.
El informe conserva dataset/commit, hash, versión de parser, consulta antes/después, positivo, negativo y resultado. También registra que la prueba cubre una variante concreta y no todas las ejecuciones de intérpretes.
El alumno separa hechos, inferencias e hipótesis; reproduce el gap; lo localiza en una etapa y demuestra regresión. Una narración sin consultas ni procedencia no es caso de estudio verificable.
Trabaja sobre datasets públicos o de tu laboratorio; no analices datos de terceros sin autorización.
Resuelve un caso completo entregando: línea de tiempo con técnicas ATT&CK por fase, identificación de los puntos de detección perdidos y al menos tres detecciones nuevas que habrían interrumpido la cadena antes. Criterio de aceptación: la timeline cubre desde el acceso inicial hasta la exfiltración de forma coherente y con tiempos ordenados, cada fase está mapeada a su técnica correcta, y las detecciones propuestas son verificables (probadas o expresadas como reglas Sigma/SIEM concretas).
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Timeline desordenada | Tiempos no sincronizados; normaliza a UTC (clase 182) |
| Fases sin evidencia | Punto ciego de telemetría; anótalo como hueco a cerrar |
| Mapeo ATT&CK forzado | Técnica mal asignada; verifica el procedimiento real |
| "El ataque era indetectable" | Afirmación no demostrada; separa ausencia de telemetría, fallo de ingesta, falta de analítica y comportamiento realmente no observable con las fuentes disponibles |
| Reporte sin acciones | Análisis sin lecciones; cada caso debe producir mejoras concretas |
❓ ¿Por qué estudiar casos si ya sé las técnicas? Porque la realidad mezcla fases, ruido y datos incompletos. Los casos entrenan el pivoteo, la reconstrucción y el criterio, que ninguna clase teórica da por sí sola.
❓ ¿Dónde consigo datos realistas para practicar? Splunk BOTS, Security Onion, EVTX-ATTACK-SAMPLES y los datasets de Atomic Red Team ofrecen telemetría de ataques reproducible y legal para entrenar.
❓ ¿El objetivo es encontrar al atacante o mejorar la detección? Ambos, pero el valor duradero está en las detecciones y lecciones que dejas: cada caso resuelto debe hacer al SOC más difícil de sorprender la próxima vez.
Clase 197 — Métricas y madurez del SOC