Contención, recuperación e informe de incidente

Aviso ético y legal: las técnicas y procedimientos de este módulo se explican con fines exclusivamente educativos y de defensa. Aplícalos únicamente en sistemas sobre los que tengas autorización explícita y documentada (tu propio laboratorio, un entorno corporativo con mandato formal de respuesta a incidentes, o una plataforma legal de práctica como un CTF). Intervenir sistemas de terceros sin autorización constituye delito en España conforme a los arts. 197 y 264 del Código Penal, aunque la intención sea defensiva. Nombres de empresa, IOC, hashes, IP, dominios y cifras de este módulo son ficticios o pertenecen a rangos reservados (RFC 5737). El caso práctico es una simulación pedagógica.

Qué aprenderás

Cómo cerrar el ciclo PICERL de NIST SP 800-61r2 con sus tres fases decisivas: Contención, Erradicación y Recuperación.
La diferencia entre contención a corto y largo plazo, y el dilema de contener sin alertar al atacante mientras se preserva evidencia volátil.
Por qué aislar un host preservando su RAM no es lo mismo que apagarlo.
Cómo eliminar la causa raíz y todos los mecanismos de persistencia, no solo el síntoma, y cuándo reconstruir desde cero en vez de limpiar.
Por qué un Golden Ticket exige resetear krbtgt dos veces.
Los criterios para validar una recuperación y decidir la vuelta a producción.
La estructura profesional de un informe de incidente, con plantilla, y las métricas MTTD/MTTR/dwell time.
Cómo dirigir una reunión de lecciones aprendidas («post-mortem sin culpas»).
Las obligaciones legales en España/UE: RGPD arts. 33 y 34 (72 horas a la AEPD), NIS2, conservación de evidencia.

1. Cerrando el ciclo: dónde estamos y qué falta

Los módulos previos de este curso cubrieron la fase de Detection & Analysis de NIST SP 800-61r2: detectar señales débiles, triarlas, correlacionarlas con IOC/IOA, y adquirir evidencia forense de memoria y disco preservando la cadena de custodia. Llegados aquí ya sabemos qué ha pasado y hasta dónde ha llegado el atacante. Falta actuar sobre ese conocimiento sin destruir la evidencia, sin dejar puertas abiertas y sin generar una falsa sensación de «incidente cerrado» cuando el atacante conserva acceso.

Este módulo final cubre las tres fases restantes del ciclo PICERL (Preparación, Identificación, Contención, Erradicación, Recuperación, Lecciones aprendidas): Contención, Erradicación y Recuperación, más el entregable que las convierte en conocimiento organizativo: el informe de incidente. Lo hilvanamos con un caso único de ransomware, porque estas fases solo se entienden bien en secuencia bajo presión de tiempo real, no como listas de comandos aisladas.

2. El caso práctico: ransomware en «Distribuciones Ferralla S.A.»

Caso simulado, usado como hilo conductor. Datos ficticios; patrón representativo de intrusiones de ransomware de doble extorsión (acceso inicial vía RDP/credenciales comprometidas, movimiento lateral con herramientas legítimas, escalada a Domain Admin, exfiltración previa al cifrado, despliegue masivo).

Contexto: Distribuciones Ferralla S.A., distribuidora industrial de 180 empleados, sedes en Zaragoza y Valencia, ERP crítico en Windows Server local. Día D, 03:14: el SIEM genera alerta crítica por creación masiva de ficheros .lockbit3 en el servidor FS-ZAR-01, replicada en 4 minutos en FS-VAL-01. A las 03:22 el EDR aísla automáticamente ambos hosts. A las 06:40 se escala a IR Lead tras confirmar que no es falso positivo.

El análisis forense previo (RAM de FS-ZAR-01 capturada antes del aislamiento, logs de EDR y del controlador de dominio) reconstruyó la cadena completa: acceso inicial D-11 vía credenciales VPN de un técnico externo comprometidas por infostealer; reconocimiento y movimiento lateral con PsExec/WMI entre D-11 y D-9; dumping de LSASS en un servidor intermedio D-8; generación de un Golden Ticket Kerberos D-6 con el hash de krbtgt obtenido de un administrador de dominio (persistencia crítica: permite forjar TGT válidos para cualquier cuenta incluso tras resetear contraseñas individuales); exfiltración de ~340 GB vía rclone entre D-3 y D-1; y despliegue de LockBit 3.0 mediante GPO malicioso el día D. Con esta cronología, entramos en contención.

3. Contención: parar la hemorragia sin destruir la escena

NIST SP 800-61r2 define la contención como el paso que evita que el incidente sobrepase los recursos disponibles, dando tiempo a diseñar una erradicación a medida. La guía subraya que la estrategia de contención debe decidirse antes del incidente, con criterios predefinidos: decidirla en caliente conduce a errores.

3.1 El dilema: contener sin alertar al atacante

Contener de forma visible y precipitada alerta al adversario de que ha sido detectado, y eso típicamente provoca: acelerar el cifrado/destrucción antes de perder el acceso; activar sabotaje de salida (borrado de logs, destrucción de backups accesibles, wipers); o desaparecer para volver semanas después por una puerta trasera no localizada.

En nuestro caso, la contención automática del EDR a las 03:22 ya alertó al atacante de facto. Pero el equipo identificó un tercer servidor (APP-ZAR-03) con indicios de persistencia (tarea programada sospechosa) sin actividad de cifrado: ¿aislarlo ya, alertando de que se ha localizado ese punto de apoyo, o monitorizarlo en silencio para identificar más infraestructura del atacante? Criterio general: si el activo no causa daño activo (sin cifrado ni exfiltración en curso) y monitorizarlo aporta inteligencia real, la contención silenciosa —aislamiento a nivel de firewall/switch sin tocar el EDR del host, sin alertas visibles— es preferible. Si hay riesgo inminente de daño mayor, la contención agresiva gana siempre, aunque alerte al atacante.

3.2 Contención a corto plazo: aislar sin apagar

El error de manual es, ante un host comprometido, desconectarlo y apagarlo: destruye toda la RAM (claves de cifrado recuperables, credenciales en claro, procesos del atacante activos) y en discos con BitLocker complica el acceso posterior. La contención correcta combina aislamiento de red con preservación del estado en ejecución:

Aislamiento vía EDR (network containment): CrowdStrike Falcon, Defender for Endpoint o SentinelOne permiten aislar un host manteniendo solo un canal cifrado hacia la consola. El proceso sigue vivo, la RAM intacta, sin comunicación con el resto de la red ni C2.
Aislamiento a nivel de switch si no hay EDR: mover el puerto a VLAN de cuarentena o ACL de denegación, sin desconectar el cable ni apagar.
Captura de memoria ANTES de cualquier apagado, siempre. Si el apagado es inevitable, primero se captura la RAM con herramienta validada y se documenta el hash de la imagen.
Deshabilitar cuentas comprometidas, no borrarlas (Disable-ADAccount): preserva el SID y la trazabilidad forense futura.
Bloqueo de IOC confirmados (IP de C2, dominios, hashes) en firewall/proxy/EDR, correlado entre todas las fuentes.

En Ferralla: aislamiento de red (ya automatizado) en FS-ZAR-01 y FS-VAL-01; captura de memoria de ambos antes de cualquier otra acción; deshabilitación inmediata de las tres cuentas comprometidas confirmadas (técnico externo, administrador de dominio, cuenta de servicio usada en el movimiento lateral); bloqueo perimetral de las dos IP de C2; y aislamiento silencioso a nivel de VLAN de APP-ZAR-03, con monitorización reforzada 18 horas antes de erradicarlo.

3.3 Contención a largo plazo

Si la contención a corto plazo es «parar la hemorragia ya», la de largo plazo es estabilizar mientras se prepara la erradicación definitiva: segmentación de red más agresiva durante días; reglas de detección temporales de alta sensibilidad para los TTP identificados; sustitución de sistemas comprometidos por réplicas limpias mientras se analiza el original en aislamiento forense; y forzado de reautenticación de sesiones activas (invalidar tokens/cookies, no solo cambiar contraseñas) para cerrar accesos ya establecidos.

En Ferralla: corte de SMB/RDP entre segmentos de servidor no esenciales durante las 72 horas de investigación, y reglas Sigma temporales para las TTP identificadas (PsExec, tickets Kerberos anómalos, tráfico rclone) en toda la red.

4. Erradicación: eliminar la causa raíz, no el síntoma

NIST SP 800-61r2 define la erradicación como eliminar los componentes del incidente: borrar malware, deshabilitar cuentas violadas, e identificar y mitigar todas las vulnerabilidades explotadas. Esa palabra —todas— es la que separa un incidente resuelto de uno pospuesto.

4.1 El error de erradicar sin scoping completo

Erradicar solo el síntoma visible (los binarios de LockBit y el servicio desplegado vía GPO) sin haber completado antes el scoping —determinar exhaustivamente qué hosts, cuentas y mecanismos de persistencia están comprometidos— es la causa número uno de reinfección. Un atacante con varios días de acceso, como en Ferralla, rara vez depende de un único punto: despliega mecanismos redundantes (tarea programada, clave Run, servicio camuflado, cuenta adicional, y aquí un Golden Ticket que sobrevive a cualquier cambio de contraseña) precisamente para sobrevivir a una limpieza parcial.

El orden correcto: (1) completar el scoping con todas las fuentes (EDR, logs de AD, memoria forense, IOC/IOA) hasta tener una lista cerrada y verificada; (2) solo entonces, erradicar de forma coordinada y simultánea en todos los puntos, para que el atacante no pueda «saltar» de un mecanismo a otro mientras limpias uno a uno.

4.2 Reconstruir desde cero vs. limpiar in situ

Decisión caso por caso con criterio explícito. A favor de reconstruir: nivel de privilegio alcanzado (SYSTEM/Domain Admin baja la confianza en detectar el 100% de la persistencia); rootkits o persistencia a nivel de firmware/bootloader; dwell time largo; criticidad del activo. A favor de limpiar in situ: privilegio bajo, dwell time corto y acotado, activo no crítico, o coste de reconstrucción desproporcionado frente al riesgo residual tras limpieza verificada.

En Ferralla: reconstrucción completa para los dos controladores de dominio, FS-ZAR-01, FS-VAL-01 y el servidor del dumping de LSASS (cinco sistemas), dado el privilegio alcanzado (Domain Admin) y el Golden Ticket. Para APP-ZAR-03, tras 18 horas de monitorización sin evidencia de escalada adicional, limpieza in situ verificada, con el criterio documentado en el informe.

4.3 Rotación de credenciales y el caso especial de krbtgt

Toda credencial a la que el atacante haya tenido acceso demostrado o razonablemente probable debe rotarse: cuentas de usuario y servicio, contraseñas de administrador local (idealmente gestionadas vía LAPS), certificados si hubo indicios de acceso a la PKI, y tokens/claves API expuestas.

El Golden Ticket merece explicación aparte por ser uno de los errores de erradicación más graves y frecuentes. Se forja con el hash NTLM de la cuenta krbtgt, que Kerberos usa para firmar todos los TGT. Con ese hash, el atacante forja TGT válidos para cualquier usuario, con cualquier grupo, validez de hasta 10 años por defecto, sin que el acceso quede reflejado como login real en ningún log de autenticación normal. Cambiar la contraseña de las cuentas de usuario no invalida un Golden Ticket ya forjado: el ticket depende del hash de krbtgt, no de la contraseña de la cuenta suplantada.

La única forma de invalidarlos es resetear la contraseña de krbtgt. Pero Active Directory mantiene el hash anterior también como válido durante el periodo de replicación, así que un solo reseteo no basta: un ticket forjado con el hash N-1 seguiría siendo válido en ese margen. La práctica estándar (Microsoft, Mandiant) es resetear krbtgt dos veces, con horas de separación entre ambos (tiempo suficiente para que la replicación entre todos los DC se complete tras el primero), invalidando así el hash original y el intermedio.

En Ferralla: primer reseteo de krbtgt tras confirmar replicación estable entre los dos DC; verificación con repadmin /replsummary; segundo reseteo 10 horas después; solo entonces se dio por invalidada la persistencia Kerberos. En paralelo se rotaron las 3 cuentas comprometidas y, por precaución, las 7 de Domain Admins, revisando además la pertenencia a grupos privilegiados en busca de cuentas añadidas por el atacante (no se encontraron, pero la comprobación es obligatoria).

5. Recuperación: restaurar con criterios, no con prisa

La recuperación devuelve los sistemas a operación normal con confianza razonable de que el problema está resuelto, no oculto. NIST SP 800-61r2 exige restauración desde backups limpios y verificados, reconstrucción, parcheado, cambio de contraseñas y refuerzo perimetral, con monitorización reforzada posterior porque los sistemas recién recuperados son un objetivo habitual de reintento.

5.1 Restaurar desde backups verificados

«Verificado» exige comprobar dos cosas: que el backup es anterior al compromiso confirmado (con acceso inicial en D-11, cualquier backup posterior es sospechoso salvo verificación explícita), y que el backup no está cifrado, corrupto o manipulado —el ransomware moderno busca y cifra o borra copias accesibles desde la red antes del cifrado masivo, para forzar el pago—. En Ferralla se usaron los backups de D-12, verificados como anteriores al acceso inicial, aceptando la pérdida de un día de datos frente al riesgo de reintroducir persistencia.

5.2 Validación antes de volver a producción

Antes de reconectar cualquier sistema, debe verificarse de forma explícita y documentada: ausencia de los IOC/IOA del incidente (escaneo con las reglas YARA/Sigma generadas); parcheado del vector de acceso inicial (en Ferralla: MFA obligatorio en VPN, RDP cerrado a internet); rotación de credenciales confirmada y comprobada (no solo ejecutada); EDR desplegado y reportando telemetría en estado healthy; y reglas de detección específicas activas y probadas con un evento de test controlado.

5.3 Monitorización reforzada y criterios de cierre

El estándar del sector es mantener monitorización reforzada (mayor sensibilidad, revisión manual diaria por el equipo de IR, no solo el SOC habitual) durante al menos 2-4 semanas antes de dar el caso por operativamente cerrado. En Ferralla se estableció un periodo de 30 días con revisión diaria, dada la gravedad (Golden Ticket, exfiltración, Domain Admin comprometido), con criterio de cierre explícito: cero detecciones relacionadas con los TTP del incidente durante ese periodo completo.

6. Tabla resumen: fases, acciones clave y errores a evitar

Fase	Acciones clave	Errores frecuentes a evitar
Contención corto plazo	Aislar de red vía EDR/VLAN preservando la RAM; capturar memoria antes de apagar; deshabilitar (no borrar) cuentas comprometidas; bloquear IOC en perímetro.	Apagar el equipo primero; borrar cuentas en vez de deshabilitarlas; contener de forma visible sin evaluar si acelera el daño.
Contención largo plazo	Segmentación sostenida; detección temporal de alta sensibilidad; forzar reautenticación de sesiones activas; réplicas limpias si es viable.	Confiar en que cambiar contraseñas invalida sesiones/tokens ya activos; levantar la contención antes de completar el scoping.
Erradicación	Scoping exhaustivo antes de actuar; eliminar TODA la persistencia de forma coordinada; decidir reconstrucción vs. limpieza con criterio documentado; rotar credenciales; resetear `krbtgt` dos veces si hubo Golden Ticket.	Erradicar solo el síntoma visible → reinfección; limpiar host a host sin coordinación; resetear `krbtgt` una sola vez; no revisar grupos privilegiados.
Recuperación	Backups verificados como anteriores al compromiso y no manipulados; validar ausencia de IOC/IOA antes de reconectar; confirmar parcheado del vector inicial; monitorización reforzada 2-4 semanas con criterio de cierre.	Restaurar sin verificar la fecha real de limpieza del backup; cerrar el incidente nada más restaurar servicio; no comprobar que las reglas nuevas funcionan de verdad.

7. El informe de incidente: la estructura profesional

Un incidente sin informe escrito, claro y accionable es, a efectos organizativos, un incidente que no se aprendió. El informe cumple tres funciones: registro de auditoría y diligencia debida (relevante también para notificación regulatoria y seguros de ciberriesgo), comunicación a dirección sin jerga técnica, y base de conocimiento para detección futura vía los IOC/TTP documentados.

Sección	Contenido	Audiencia
1. Resumen ejecutivo	Qué pasó, impacto en negocio, estado actual, en menos de una página, sin jerga.	Dirección, comité de crisis
2. Cronología	Secuencia de eventos con marca de tiempo, desde el acceso inicial hasta el cierre.	Equipo técnico, auditoría
3. Alcance	Sistemas, cuentas, datos y ubicaciones afectados; confirmado vs. descartado.	Técnico, legal, DPO
4. Vector de acceso inicial	Cómo entró el atacante, con evidencia de soporte.	Técnico, seguridad
5. TTP (MITRE ATT&CK)	Tácticas y técnicas con su ID (T1078, T1003.006, T1558.001…).	Técnico, threat intel
6. IOC	Hashes, IP, dominios, claves de registro, servicio/tarea, en formato reutilizable.	SOC, otros equipos
7. Impacto	Operativo, económico, de datos (exfiltrado, personas afectadas), reputacional.	Dirección, legal, DPO
8-10. Contención / Erradicación / Recuperación	Qué se hizo, cuándo, y con qué criterio de decisión.	Técnico, auditoría, dirección
11. Recomendaciones	Acciones priorizadas, con responsable y plazo.	Dirección, IT, seguridad
12. Lecciones aprendidas	Qué funcionó, qué no, qué cambiar en el proceso de IR.	Equipo IR, dirección

Plantilla resumida para arrancar un informe real:

INFORME DE INCIDENTE DE SEGURIDAD
Referencia: IR-2026-XXX | Clasificación: CONFIDENCIAL
Fecha de detección: [timestamp] | Fecha de cierre: [timestamp]
Autor(es): [nombre, rol] | Revisado por: [IR Lead / CISO]

1. RESUMEN EJECUTIVO
   - Qué ocurrió (2-3 frases, sin jerga) / Impacto en negocio
   - Estado: [Contenido / Erradicado / Recuperado / Cerrado]

2. CRONOLOGÍA
   D-11 03:xx  Acceso inicial vía [vector]
   D-9  xx:xx  Movimiento lateral (retrospectivo)
   D-6  xx:xx  Persistencia establecida ([mecanismo])
   D-1  xx:xx  Exfiltración de datos
   D    03:14  Despliegue ransomware / detección SIEM
   D    03:22  Contención automática (EDR)
   D    06:40  Escalado a IR Lead
   D+3  xx:xx  Erradicación completada
   D+4  xx:xx  Vuelta a producción validada

3. ALCANCE: sistemas / cuentas / datos (¿personales? sí/no)
4. VECTOR DE ACCESO INICIAL: [descripción técnica + evidencia]
5. TTP (MITRE ATT&CK): T1078, T1021.002, T1003.006, T1558.001, T1486...
6. IOC: [tabla: tipo | valor | primera observación | fuente]
7. IMPACTO: horas de inactividad | coste estimado | interesados afectados
8-10. ACCIONES: contención / erradicación / recuperación (ver checklist §3-5)
11. RECOMENDACIONES: [acción | responsable | prioridad | plazo]
12. LECCIONES APRENDIDAS: [ver §9]

ANEXOS: capturas forenses, hashes de evidencia, logs relevantes

8. Métricas: MTTD, MTTR y dwell time

Un informe sin métricas cuantificadas es narrativa, no dato accionable. Dirección, auditoría y las aseguradoras de ciberriesgo van a pedir tres:

MTTD (Mean Time To Detect): tiempo entre el inicio real del compromiso y su detección. En Ferralla, acceso inicial D-11 03:xx y detección (alerta del cifrado) D 03:14: ~11 días hasta el evento que disparó la alerta.
MTTR (Mean Time To Respond/Resolve): se descompone en MTTR de contención (detección → contención efectiva: 8 minutos, gracias al EDR automatizado) y de resolución completa (detección → recuperación validada: ~4 días).
Dwell time: presencia total no detectada del atacante, desde el acceso inicial hasta la contención real. En Ferralla: 11 días. Los informes del sector (M-Trends de Mandiant, IBM Cost of a Data Breach) sitúan el dwell time medio en intrusiones de ransomware con exfiltración típicamente por encima de una semana, porque el atacante necesita tiempo para moverse lateralmente y escalar antes de cifrar.

Agregadas por trimestre, estas métricas indican si el programa de seguridad mejora de verdad o si cada incidente se resuelve bien de forma aislada sin aprendizaje sistémico.

9. Lecciones aprendidas: la reunión post-mortem sin culpas

NIST SP 800-61r2 dedica una fase completa (la «L» de PICERL) a esto: sin ella, el ciclo se repite y el mismo vector de acceso, la misma falta de MFA, la misma persistencia no detectada por falta de telemetría, vuelve a explotarse porque nadie formalizó el aprendizaje.

Blameless por diseño: entender por qué una decisión razonable con la información disponible llevó a ese resultado, no señalar culpables. Personalizar la culpa mata la honestidad futura: la próxima vez, los problemas se ocultarán en vez de reportarse.
Timing: idealmente 1-2 semanas tras el cierre operativo, con los detalles aún frescos pero sin el pulso acelerado.
Preguntas, no acusaciones: ¿qué funcionó y debe repetirse? ¿qué no funcionó y por qué (proceso, herramienta, formación, comunicación)? ¿qué habría reducido el dwell time o el MTTR? ¿la comunicación interna fue clara y a tiempo?
Salida obligatoria: acciones con responsable y plazo, no buenas intenciones. En Ferralla: MFA obligatorio en VPN, retención de logs ampliada de 30 a 180 días, detección específica de DCSync en todos los DC, y revisión trimestral de Domain Admins.

10. Aspectos legales y de notificación en España y la UE

Un incidente técnicamente bien gestionado pero con notificación legal tardía o ausente puede generar sanción y daño reputacional mayor que el propio ataque. La obligación corresponde al Responsable del Tratamiento (asesorado por el DPO), no al equipo técnico directamente, pero el IR aporta los datos que permiten cumplir el plazo.

10.1 RGPD: artículos 33 y 34

El Reglamento (UE 2016/679) establece dos obligaciones distintas: Art. 33 — si el incidente es una violación de seguridad de datos personales, notificarla a la autoridad de control (en España, la AEPD) sin dilación indebida y, de ser posible, en un plazo máximo de 72 horas desde que se tenga constancia; si se supera el plazo, debe acompañarse de justificación motivada. La AEPD dispone de sede electrónica con campos que exigen justo lo que un buen informe técnico ya recopila: naturaleza de la violación, categorías y número aproximado de interesados/registros, consecuencias probables, medidas adoptadas. Art. 34 — si hay alto riesgo para los derechos de las personas, comunicación directa a los afectados, en lenguaje claro, describiendo la violación y las medidas recomendadas.

En Ferralla, los 340 GB exfiltrados incluían una base de clientes (nombre, NIF, dirección, facturación) de ~4.200 personas físicas, más nóminas de los 180 empleados: se activaron ambas obligaciones. Notificación a la AEPD dentro de las 72 horas desde que el DPO tuvo constancia razonable del alcance (el reloj corre desde el conocimiento con certeza razonable, no desde la primera sospecha), y comunicación directa a los interesados dado el alto riesgo (datos identificativos y económicos, riesgo de fraude/suplantación).

10.2 Directiva NIS2

La Directiva (UE) 2022/2555 amplía el alcance de la anterior NIS a más sectores (energía, transporte, banca, infraestructura digital, administración pública, fabricación, y otros «esenciales» o «importantes»), con notificación al CSIRT/autoridad competente (en España, coordinado por CCN-CERT/INCIBE-CERT) en esquema escalonado: alerta temprana en 24 horas, notificación completa en 72 horas, informe final en un mes. Conviene verificar el estado de la transposición en España y si la organización entra en el ámbito de sujetos obligados, mucho más amplio que antes. Ferralla, distribuidora sin actividad en sector regulado por NIS2, no estaría sujeta en este caso, pero toda organización debe clasificarse activamente como parte de su preparación de IR, no descubrirlo en mitad de un incidente.

10.3 Conservación de evidencia y denuncia penal

Con independencia de las notificaciones regulatorias, este tipo de incidente constituye probablemente varios delitos del Código Penal (arts. 197/197 bis, acceso ilícito a sistemas; art. 264, daños informáticos; posible extorsión). La evidencia debe seguir cadena de custodia formal desde el primer momento, porque puede requerirse en un procedimiento penal ante Policía Nacional o Guardia Civil. La decisión de denunciar es de dirección y legal, pero el IR debe preservar la evidencia como si la denuncia fuera a producirse siempre, porque una vez contaminada no hay forma de recuperarla.

11. Laboratorio: redacta el informe de incidente del caso Ferralla

Con la información desarrollada en este módulo, redacta el informe completo de «Distribuciones Ferralla S.A.» usando la plantilla de la sección 7. Tu entrega debe incluir, como mínimo:

Resumen ejecutivo de máximo 150 palabras, sin ningún término técnico sin explicar, apto para el consejo de administración.
Cronología completa en tabla, con al menos 10 hitos temporales.
Mapeo de TTP a MITRE ATT&CK: al menos 6 técnicas con su ID correcto (verifícalas en la matriz pública, no las inventes).
Tabla de IOC con al menos 5 indicadores de al menos 3 tipos distintos (hash, IP/dominio, artefacto de persistencia).
Cálculo explícito de MTTD, MTTR (contención y resolución) y dwell time, con el razonamiento, no solo el número.
Justificación razonada de reconstruir vs. limpiar para cada sistema afectado.
Borrador de los campos clave para la AEPD (naturaleza de la violación, categorías de datos, número aproximado de interesados, medidas adoptadas), y justificación de si se activa o no el art. 34.
Mínimo 5 recomendaciones priorizadas con responsable y plazo.

Entrega esperada: documento único de 1500-2500 palabras. No hay una única solución correcta; se evalúa el rigor del razonamiento y la trazabilidad entre evidencia y conclusión.

12. Errores comunes

Erradicar sin scoping completo: eliminar el malware visible y dar el incidente por resuelto sin buscar de forma sistemática toda la persistencia redundante. Causa más frecuente de reinfección semanas después.
No resetear krbtgt dos veces tras confirmar o sospechar un Golden Ticket: un solo reseteo deja válido el hash intermedio de la ventana de replicación.
Olvidar la notificación legal o tratarla como trámite de última hora, en vez de coordinar con el DPO/legal desde el minuto uno de la contención.
Restaurar backups sin verificar que son anteriores al compromiso y no están manipulados, reintroduciendo persistencia que se creía erradicada.
Cerrar el incidente nada más recuperar el servicio, sin el periodo de monitorización reforzada, precisamente cuando el mismo atacante suele reintentar.
Informe puramente técnico sin resumen ejecutivo real, o al revés, tan genérico que no sirve para threat hunting futuro.
Reunión de lecciones aprendidas que deriva en buscar culpables, garantizando que la próxima vez los problemas se oculten en vez de reportarse.

13. Ejercicio final integrador

Retoma el caso de ransomware y cambia una variable crítica: el IR no detecta el incidente hasta 6 semanas después del acceso inicial (no 11 días), y el atacante ha desplegado, además del Golden Ticket, un segundo mecanismo de persistencia mediante un certificado de dominio malicioso emitido a través de una plantilla de AD CS (Active Directory Certificate Services) mal configurada —persistencia que sobrevive incluso al reseteo de krbtgt, porque un certificado válido permite autenticación Kerberos mediante PKINIT sin depender del hash de esa cuenta—.

Redacta, en no más de 800 palabras: (1) cómo cambia tu estrategia de scoping y de decisión reconstruir-vs-limpiar dado el dwell time de 6 semanas; (2) qué erradicación adicional necesitas para neutralizar la persistencia vía AD CS (investiga qué es un ataque ESC1/ESC8 si no lo conoces, y qué acción —más allá de resetear krbtgt— se necesita); (3) cómo cambian tus métricas de MTTD/dwell time y qué dicen sobre la madurez de detección; y (4) si el dwell time más largo cambia tu análisis de la obligación del art. 33 RGPD (el plazo de 72 horas no cambia, pero sí puede cambiar tu valoración del alcance real y el contenido de lo que notificas).

Preguntas frecuentes

¿Por qué no basta con cambiar todas las contraseñas del dominio tras un incidente grave?

Porque no invalida sesiones, tokens o tickets Kerberos ya activos, ni mecanismos de persistencia que no dependen de una contraseña concreta (el Golden Ticket depende del hash de krbtgt; un certificado PKINIT fraudulento permite autenticación sin contraseña alguna). La rotación completa debe combinarse con invalidación de sesiones activas, reseteo de krbtgt si hubo indicios de Golden Ticket, y revisión de la PKI si hubo abuso de AD CS.

¿Es obligatorio notificar a la AEPD cualquier incidente de seguridad?

No. El art. 33 se activa solo cuando hay violación de seguridad de datos personales, y existe excepción: si es improbable que entrañe riesgo para los derechos y libertades de las personas, no es obligatorio notificar a la AEPD (aunque conviene documentar internamente el análisis de riesgo). Un incidente que solo afecta a sistemas o datos corporativos sin datos personales no activa el art. 33, aunque puede activar otras obligaciones, como NIS2 si el sector aplica.

¿Cuál es la diferencia práctica entre MTTD y dwell time?

MTTD suele medir el tiempo hasta la primera señal de detección, que puede ser parcial. El dwell time mide la presencia total no controlada del atacante hasta la contención real y efectiva, que puede ser posterior si el triaje inicial fue lento o la alerta solo capturó parte del compromiso. En incidentes con varias fases, como Ferralla, ambas métricas pueden coincidir o no, dependiendo de qué evento se tome como «detección».

¿Cuándo está justificado reconstruir un sistema completo en vez de limpiarlo?

Cuando el nivel de certeza alcanzable sobre «he encontrado el 100% de la persistencia» no es suficientemente alto para el riesgo del activo. Regla práctica: si el atacante alcanzó privilegios de administrador/SYSTEM/Domain Admin, si el dwell time fue largo, si hay indicios de persistencia avanzada (rootkit, firmware, AD CS), o si el activo es crítico, el coste de reconstruir casi siempre es menor que el coste esperado de una reinfección no detectada. La limpieza in situ se reserva para alcance bien acotado, privilegio limitado y activo no crítico, documentando la decisión.

¿Quién decide si se denuncia el incidente a la Policía o Guardia Civil?

La decisión corresponde a dirección, asesorada por legal, no al equipo técnico de IR. Pero el IR tiene una responsabilidad independiente de esa decisión: preservar toda la evidencia con cadena de custodia formal desde el primer momento, como si la denuncia fuera a producirse siempre —la decisión legal puede tardar días o semanas (o revisarse si aparece, por ejemplo, una demanda de rescate posterior), y para entonces la evidencia volátil ya se habrá perdido si no se preservó a tiempo.

«Containment provides time for developing a tailored remediation strategy. An essential part of containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions)… Eradication may be necessary to eliminate components of the incident, such as deleting malware and disabling breached user accounts, as well as identifying and mitigating all vulnerabilities that were exploited. During eradication, it is important to identify all affected hosts within the organization so that they can be remediated.» — NIST Special Publication 800-61 Revision 2, «Computer Security Incident Handling Guide», National Institute of Standards and Technology, sección 3.3 (Containment, Eradication, and Recovery).

Módulo 12: Contención, erradicación, recuperación e informe