Parte: 9 — Forense digital y respuesta a incidentes · Fuente: NIST SP 800-61 Rev. 3 y documentación técnica de plataforma ⏱️ Duración estimada: 110 min · Nivel: Intermedio
Dominar tres grupos de trabajo de la respuesta: contener reduciendo impacto y preservando evidencia pertinente, erradicar accesos y condiciones dentro del alcance conocido, y recuperar la operación con confianza justificada. Al terminar sabrás decidir entre aislar u observar, buscar persistencia por varias fuentes y validar criterios de recuperación sin prometer certeza absoluta.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Contención corto vs. largo plazo | Rapidez vs. estabilidad |
| 2 | Aislar vs. observar | Trade-off inteligencia/riesgo |
| 3 | Preservar evidencia al contener | No romper la forense |
| 4 | Erradicación de persistencia | El atacante no debe volver |
| 5 | Reconstrucción vs. limpieza | Confianza en el sistema |
| 6 | Rotación de credenciales | Cerrar el acceso robado |
| 7 | Recuperación monitorizada | Detectar reinfección |
| 8 | Validación de erradicación | Criterio para cerrar |
Contener limita impacto; erradicar elimina causas y persistencia; recuperar restablece servicio confiable. Aislar demasiado pronto puede cortar C2 y también alertar al adversario, perder evidencia o detener negocio. La decisión combina riesgo técnico, criticidad, visibilidad y autoridad.
Erradicación incluye credenciales, tokens, reglas cloud y vectores, no solo borrar malware. Recuperar desde backup requiere comprobar que el backup precede al compromiso y no conserva persistencia. Se fijan criterios de salud, propietario y ventana de observación. Las acciones mantienen un log común para relacionar cambios operativos con evidencia.
La contención inmediata busca frenar daño; la de largo plazo crea un estado sostenible mientras se comprende y erradica. Aislar un endpoint desde EDR, bloquear una cuenta, segmentar una subred o deshabilitar una integración producen efectos distintos. Cada acción se evalúa por velocidad, alcance, reversibilidad, evidencia que altera e impacto empresarial. El criterio se registra con lo que se sabía en ese momento.
Observar al adversario puede ampliar inteligencia, pero también permite daño adicional. Solo se justifica con autoridad, monitoreo, límites de tiempo y criterios de interrupción. En la mayoría de escenarios donde continúa cifrado o exfiltración, reducir impacto domina; aun así, preservar memoria o conexiones puede ejecutarse en paralelo si no retrasa una contención crítica.
Borrar el binario visible no revoca tokens, claves API, tareas, servicios, aplicaciones OAuth, reglas de reenvío ni vulnerabilidades explotadas. Se construye una matriz de activos, identidades, persistencias y vector inicial; cada elemento recibe acción y evidencia de verificación. La rotación se ordena para evitar que una sesión comprometida capture las nuevas credenciales.
La reconstrucción desde una imagen confiable suele reducir incertidumbre frente a una limpieza compleja, pero tampoco es una «garantía plena»: firmware, credenciales, imágenes base, automatización y backups pueden conservar el problema. Se valida procedencia y fecha de la base, se aplica configuración actual y se prueban controles antes de reconectar.
La recuperación define servicio mínimo, criterios de salud, dependencias, validación de datos y plan de reversión. Los sistemas vuelven por etapas y con telemetría reforzada. Una ausencia breve de alertas no demuestra erradicación; la ventana se justifica por ciclos de negocio, persistencia observada y riesgo.
El cierre exige demostrar que las rutas conocidas de acceso están eliminadas, el servicio funciona, las fuentes de detección reportan y las acciones pendientes tienen dueño. Si queda incertidumbre relevante, se comunica en vez de transformar «no observado» en «no existe».
Un servidor muestra una herramienta remota y autenticaciones de una cuenta administrativa hacia tres hosts. Aislar solo el servidor limita una ruta, pero la identidad permite continuar. El equipo preserva telemetría, deshabilita temporalmente la cuenta, revoca sesiones y busca su uso en controladores, VPN, nube y endpoints. La rotación incluye secretos de servicios dependientes y se coordina para no romper recuperación.
Dos hosts se reconstruyen desde una imagen validada; el tercero se conserva para análisis porque contiene evidencia única. Antes de reconectar, se corrige el vector inicial, se aplican controles, se prueban logs y se ejecuta búsqueda de persistencia conocida. El cierre enumera qué se verificó, cuánto duró la observación y qué riesgo residual permanece.
Dominas la clase cuando comparas opciones de contención por riesgo, reversión e impacto; amplías erradicación a activos, identidad y nube; validas una reconstrucción más allá del sistema operativo; y defines recuperación y cierre mediante evidencia positiva en lugar de una simple ausencia de alertas.
autoruns (persistencia Windows), revisión de cron/systemd (Linux).Sobre una VM de laboratorio propia previamente "comprometida" por ti.
powershell
autorunsc.exe -a * -c > autoruns.csv
Revisa servicios, tareas programadas, claves Run, y WMI. 4. En Linux, revisa cron, systemd y perfiles de shell (clase 206), y declara qué otras superficies quedan fuera de esa enumeración. 5. Erradica: elimina cada mecanismo identificado y el malware. Si el compromiso fue profundo (root/SYSTEM), planifica reconstrucción desde cero. 6. Rota credenciales: cambia contraseñas, revoca tokens/sesiones y claves API que el atacante pudo ver. 7. Recupera el sistema con monitoreo reforzado: EDR en alerta, logging aumentado, y una regla que avise si reaparecen los IOCs. 8. Valida: define un periodo de observación y los criterios ("cero IOCs, cero conexiones al C2, cero reintentos de la persistencia") para cerrar.
En una VM comprometida por ti, ejecuta las tres fases: contiene documentando cambios sobre evidencia, busca y elimina la persistencia conocida mediante varias fuentes y valida recuperación con criterios explícitos y riesgo residual.
Criterio de aceptación: documentas (a) cómo aislaste y qué evidencia pudo cambiar, (b) mecanismos de persistencia buscados, hallados y eliminados más límites de cobertura, (c) rotación y revocación ordenadas, y (d) criterios cumplidos y riesgo residual para declarar la recuperación.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El malware reaparece tras limpiar | Quedó persistencia sin eliminar. Enumera TODA con Autoruns/cron/systemd. |
| Perdiste la RAM al contener | Apagaste el equipo. Aísla por red, no por apagado. |
| El atacante vuelve con la misma clave | No rotaste credenciales. Cámbialas y revoca sesiones. |
| Limpiaste pero no confías en el host | Compromiso profundo. Reconstruye desde cero. |
| Cerraste demasiado pronto | Sin periodo de validación. Monitorea antes de declarar resuelto. |
❓ ¿Aislar u observar? Aísla si el riesgo de daño es alto; observa solo si necesitas inteligencia y puedes contener el daño. Ante la duda, aísla.
❓ ¿Limpiar o reconstruir? Ante compromiso con privilegios altos o rootkits, reconstruir desde una base validada suele reducir más incertidumbre que limpiar. También debes revisar firmware, identidad, datos, imágenes y automatización relacionadas.
❓ ¿Cuándo roto credenciales? Cuando el alcance indique acceso posible o exposición: contraseñas, tokens, claves API y secretos de servicio. Define el orden para revocar sesiones antes de emitir reemplazos utilizables.
❓ ¿Cómo sé que erradiqué de verdad? Con monitoreo reforzado durante un periodo y criterios objetivos: cero IOCs activos, cero conexiones al C2, cero reintentos de persistencia.
Clase 215 — Playbooks de respuesta a incidentes