GhostForensicsMódulo 17Caso práctico

Respuesta a incidentes: triage y contención en vivo

Todo lo anterior asumía una evidencia ya adquirida y tiempo para analizarla con calma. En un incidente real, el analista casi nunca llega con ese lujo: llega con el atacante posiblemente todavía dentro, decisiones que tomar en minutos, y la tensión permanente entre dos objetivos que compiten —parar el daño cuanto antes, y no destruir la evidencia que explica qué pasó. Este módulo abre la última fase del curso con esa disciplina: el triage.

Objetivos de la unidad

Distinguir el triage en vivo del análisis forense completo, y saber cuándo basta uno y cuándo hace falta el otro.
Usar KAPE para recolectar los artefactos críticos de un equipo en minutos, sin adquirir la imagen completa.
Decidir entre aislar, apagar o dejar correr un sistema comprometido, con criterio y no por costumbre.
Aplicar el ciclo de vida de respuesta a incidentes del NIST como marco de referencia.
Entender por qué la comunicación durante un incidente activo necesita un canal fuera de banda.

📦 Caso práctico descargable

Descarga el paquete de evidencia, descomprímelo y lee el LEEME.md antes de empezar. Verifica el hash según el módulo 2 antes de analizar nada:

Hashes de referencia (ver también LEEME.md):

estado_al_llegar.txt → d7f73add888c752f6e0041e9d16bff69380b25d89b547bf8c830aec59b33e33a
kape_collection_log.txt → 94a6e1a8f71c2e302280d8716e6c00b2f51ac7b6b8c690fef314da7d57e5ef80

⬇️ Descargar M17_RespuestaIncidentes.zip Ver solución paso a paso →

1. Triage vs análisis forense completo

El triage responde a una pregunta mucho más acotada que todo el curso hasta ahora: no "qué pasó exactamente, con todo detalle y evidencia exhaustiva" (eso es el análisis completo de los módulos 3-16), sino "¿qué tengo que saber ya mismo para decidir si contengo, cómo y dónde". Es deliberadamente superficial en algunos puntos a cambio de ser rápido en todos — la profundidad llega después, cuando ya no hay fuego que apagar.

2. KAPE: recolección selectiva en minutos

KAPE (Kroll Artifact Parser and Extractor) resuelve el problema central del triage: adquirir una imagen de disco completa (módulo 2) de un servidor de varios terabytes puede llevar horas que, en plena contención, no existen. KAPE recolecta solo los artefactos con valor forense conocido —MFT, hives de registro, Prefetch, Event Logs, exactamente los artefactos de los módulos 3 a 6— en minutos, mediante dos fases:

Fase	Qué hace
Targets	Copia los ficheros de interés (definidos en plantillas ya hechas, como `!BasicCollection` o específicas por artefacto) a una carpeta de destino, respetando permisos de solo lectura cuando es posible.
Modules	Ejecuta automáticamente los parsers correspondientes (muchos de ellos las propias Eric Zimmerman Tools ya vistas en los módulos 5-6) sobre lo recolectado, entregando resultados ya legibles sin pasos manuales adicionales.

analista@lab (salida real)

$ kape.exe --tsource C: --tdest E:\triage_caso17 --target !BasicCollection --mdest E:\triage_caso17_parsed --module !EZParser
Processing target: !BasicCollection
  Collected: MFT, Registry hives (SYSTEM/SOFTWARE/SAM/NTUSER.DAT), Prefetch, EVTX
Running modules: !EZParser
  PECmd, AmcacheParser, EvtxECmd, RECmd ejecutados sobre lo recolectado
Completed in 4m 12s

Cuatro minutos frente a las horas que llevaría una imagen completa, con exactamente los artefactos que ya se trabajaron a fondo en los módulos 3-6 — KAPE no sustituye ese conocimiento, lo aplica a mayor velocidad cuando el tiempo es el recurso más escaso.

3. Aislar, apagar o dejar correr: una decisión, no un reflejo

Opción	Qué preserva	Qué arriesga
Aislar de la red (manteniendo el equipo encendido)	La memoria RAM sigue disponible para adquisición (módulo 8); se corta la comunicación con el C2 y se detiene la exfiltración en curso.	Malware con lógica de auto-destrucción al detectar pérdida de red puede activarse; el atacante puede notar la desconexión si está interactuando en tiempo real.
Apagar ("pull the plug")	Detiene cualquier cifrado de ransomware en curso de forma inmediata.	Destruye toda la memoria RAM (módulo 8) y cualquier evidencia que solo vivía ahí — exactamente lo que el orden de volatilidad del módulo 1 advierte no hacer sin pensar.
Dejar correr, bajo vigilancia	Permite observar comportamiento adicional del atacante (útil para threat hunting, módulo 18).	El daño y la exfiltración continúan mientras se observa; rara vez justificable fuera de un entorno de investigación controlado y autorizado explícitamente.

La recomendación por defecto, salvo que el caso diga lo contrario: aislar de la red antes que apagar. Preserva la memoria para su adquisición (módulo 8) y corta el canal activo del atacante (módulo 12) sin perder la evidencia más volátil de todas. Apagar se reserva para los casos donde el daño en curso (cifrado activo de ransomware, por ejemplo) es más urgente que preservar la memoria.

4. Contención más allá de la red local

Cuando el incidente ya ha tocado identidades o infraestructura cloud —como el propio caso que viene siguiendo el curso, con la clave de acceso creada en AWS en el módulo 16—, la contención no termina en el cable de red:

Deshabilitar la cuenta comprometida, no solo cambiar su contraseña: una sesión o token ya emitido puede seguir siendo válido hasta que se revoque explícitamente.
Revocar tokens y sesiones activas en el proveedor de identidad (Entra ID, por ejemplo) y en servicios cloud (la CreateAccessKey del módulo 16 debería desactivarse de inmediato en cuanto se detecta).
Rotar credenciales relacionadas que el atacante haya podido ver o usar, no solo la cuenta de entrada inicial.

5. El ciclo de vida de respuesta a incidentes (NIST)

Fase	Qué incluye
Preparación	Todo lo que debe existir antes del incidente: logging activado (módulo 16), playbooks, contactos de emergencia, acceso a herramientas como KAPE ya preparado.
Detección y análisis	Confirmar que hay un incidente real, su alcance inicial — el triage de este módulo.
Contención, erradicación y recuperación	Aislar (punto 3), eliminar la causa (el proceso/persistencia de los módulos 6 y 9), restaurar servicios de forma segura.
Actividad post-incidente	El informe final (módulo 20) y las lecciones aprendidas que retroalimentan la fase de preparación del siguiente incidente.

🧰 Guided Lab relacionado (Ghost Academy)

Laboratorio guiado ya publicado en Ghost Academy que puedes usar para practicar esta herramienta:

KAPE DFIR (lab) · Incident Response

6. Comunicación fuera de banda

Si el atacante comprometió el correo o el chat corporativo, puede estar leyendo la coordinación de la propia respuesta al incidente. Se han dado casos reales donde el equipo de respuesta discutió por correo electrónico comprometido los pasos que iba a tomar, y el atacante reaccionó en tiempo real. La comunicación crítica durante un incidente activo —qué se sabe, qué se va a hacer, cuándo— debe ir por un canal que se sepa no comprometido: llamada telefónica, una plataforma de mensajería completamente distinta a la habitual, o en persona.

Autoevaluación

¿Qué diferencia principal hay entre el objetivo del triage y el del análisis forense completo de los módulos 3-16?
¿Qué dos fases tiene KAPE, y qué hace cada una?
Un servidor con ransomware cifrando activamente ficheros, visible en tiempo real. ¿Aislarías de la red o apagarías, y por qué en este caso concreto la respuesta por defecto del punto 3 podría no aplicar?
En el caso que viene siguiendo el curso, ¿qué acción de contención cloud específica correspondería a la CreateAccessKey detectada en el módulo 16?
¿Por qué la coordinación de la respuesta a un incidente no debería hacerse por los mismos canales que pudo haber comprometido el propio atacante?