El incidente llega tarde: alguien detecta conexiones salientes anómalas desde un servicio en Kubernetes, pero el pod ya fue reprogramado por auto-scaling y el contenedor original no existe. En cloud esto no es una rareza; es el comportamiento normal del sistema. El reto forense no es “entrar al contenedor” (porque ya no está), sino reconstruir una línea temporal fiable a partir de evidencias externas, inmutables y previamente habilitadas.
Si tu respuesta a incidentes depende de “me conecto al host y miro /var/log”, en entornos efímeros vas a perder siempre. La única manera de tener forense útil es diseñar antes del incidente: decidir qué telemetría se conserva, cómo se protege contra manipulación y qué mecanismos permiten capturar estado (disco/memoria) bajo cuarentena en el momento correcto.
Qué salió mal cuando la evidencia desaparece (y por qué no es “mala suerte”)
En un entorno con auto-scaling, nodos spot o serverless, la infraestructura está optimizada para disponibilidad y coste, no para retención de evidencia. Un pod comprometido puede vivir minutos; el nodo puede reciclarse; el runtime puede limpiar capas; y los logs locales pueden irse con el contenedor. Si no había un canal centralizado e inmutable, el atacante no necesita borrar nada: la plataforma lo hace por él.
El fallo habitual en empresas es operativo, no técnico: se asume que “ya veremos” cómo investigar cuando pase. Luego, en mitad de un IR, se improvisa: se activan logs tarde, se cambian configuraciones (contaminando la escena) o se pide a plataforma “que no escale” sin un plan claro. Eso genera dos consecuencias reales: pérdida de trazabilidad (no puedes atribuir acciones) y tiempos de contención mayores (porque no sabes qué tocar sin romper producción).
Reconstruir la línea temporal sin el contenedor: evidencias externas que sí sobreviven
Cuando el contenedor ya no existe, tu forense se apoya en señales que viven fuera del ciclo de vida del pod: red, plano de control y ejecución. En la práctica, lo que más salva incidentes es haber retenido logs de red (para responder “quién habló con quién, cuándo y cuánto”) y logs de ejecución (para responder “qué se ejecutó y con qué identidad”). Sin eso, la investigación se vuelve una colección de hipótesis difíciles de demostrar.
Dos fuentes suelen ser obligatorias en cloud corporativo por su valor forense y por su bajo nivel de ambigüedad: VPC Flow Logs (o equivalente) y Execution Logs de la capa de cómputo (funciones, gateways, runtimes, auditoría del plano de control). La clave no es solo activarlos, sino retenerlos el tiempo suficiente, con integridad y con un esquema que permita consultas rápidas durante IR.
- VPC Flow Logs: dan contexto de exfiltración, C2 y movimientos laterales a nivel de red incluso cuando el contenedor murió.
En empresa, esto permite correlacionar picos de egress con despliegues, cambios de imagen o rotaciones de pods. También ayuda a demostrar impacto: no es lo mismo un intento de conexión bloqueado por SG/NACL que sesiones establecidas con transferencia de bytes.
- Execution Logs (y auditoría de plano de control): capturan llamadas, errores, invocaciones y, sobre todo, identidades y contexto de ejecución.
En un caso real típico, un atacante no “rompe” Kubernetes; abusa de credenciales del workload. Los logs de ejecución y del plano de control son los que te dicen si hubo creación de pods, cambios en roles, lectura de secretos, o invocaciones inusuales. Si faltan, se pierde la atribución interna: no sabes si fue un pod específico, un pipeline o un operador humano.
Contención sin destruir evidencia: snapshots bajo cuarentena de discos y nodos
Cuando sospechas compromiso, la tentación es reiniciar o redeployar. Eso suele ser correcto para disponibilidad, pero es malo para forense si no capturas estado primero. En cloud, el equivalente corporativo de “clonar el disco” es crear snapshots (por ejemplo, EBS o discos gestionados) y tratarlos como evidencia: con permisos restringidos, retención definida y cadena de custodia operativa.
El matiz importante: en contenedores, el filesystem del contenedor suele ser efímero, pero los nodos y volúmenes persistentes pueden contener piezas críticas (binaries descargados, herramientas del atacante, dumps, artefactos en /tmp, logs del runtime o del agente). Si el pod usaba PV/PVC, el snapshot del volumen es una de las pocas evidencias “materiales” que sobreviven a la muerte del contenedor.
- Snapshot del volumen persistente (si existe): prioriza el disco que el workload montaba (por ejemplo, datos o cachés) antes de que procesos de limpieza o rotación lo alteren.
Esto es útil cuando el atacante dejó artefactos en rutas de trabajo o manipuló datos. En IR corporativo, además, te permite trabajar en paralelo: contienes en producción y analizas fuera, sin bloquear a operaciones.
- Snapshot del disco del nodo (cuando aplica): si el nodo aloja artefactos del runtime, logs del agente o capas que no se replican en otro sitio, capturarlo puede marcar la diferencia.
En la práctica, esto requiere disciplina: etiquetar el recurso, aislarlo (quarantine account/proyecto o al menos IAM restrictivo) y evitar que alguien lo “reutilice” para pruebas. Un antipatrón frecuente es compartir snapshots por conveniencia entre equipos sin control de acceso; eso rompe la integridad de la evidencia y complica auditorías internas.
Cómo hacerlo en la práctica: captura de memoria y estado en Kubernetes antes de que el pod muera
Si el pod todavía está vivo, tu ventana es corta. La memoria puede contener indicadores que nunca llegarán a disco: credenciales en claro, conexiones activas, inyección en procesos, o payloads fileless. En entornos Kubernetes, lo viable suele ser apoyarse en herramientas open-source y en capacidades del kernel (eBPF / tracing) para extraer señales sin depender de entrar “a mano” al contenedor con sesiones interactivas que alteren el estado.
Lo operativo aquí es tener un playbook y permisos previamente definidos. En empresas, el bloqueo típico no es técnico: es que el equipo de seguridad no tiene RBAC para crear un pod/daemonset de respuesta, o no tiene acceso al nodo. Cuando eso se negocia en caliente, el pod ya murió y lo único que queda son logs incompletos.
- Preparar un DaemonSet de respuesta bajo control: despliega (solo cuando se autorice) un agente forense open-source que pueda recolectar artefactos del nodo y, si procede, dumps de memoria de procesos.
En producción corporativa, esto se maneja como “break glass”: manifiestos versionados, revisados por seguridad y plataforma, y desplegables con una aprobación explícita. La ventaja es que reduces improvisación y aseguras que lo que capturas es consistente entre incidentes.
- Recolectar primero lo volátil: conexiones activas, procesos, mapas de memoria y eventos recientes del runtime antes de intentar copiar archivos.
La consecuencia práctica: si empiezas por “copiar el filesystem”, muchas veces llegas tarde a lo importante. La memoria cambia por segundo. En un caso de cryptominer o reverse shell, capturar conexiones y procesos en el minuto correcto puede darte el dominio/IP de C2 y el binario inyectado, lo que acelera contención en toda la flota.
Ejemplo de control IAM (AWS) para snapshots con etiquetas y aislamiento:
Una forma realista de evitar errores es permitir solo la creación de snapshots cuando el volumen/disco esté marcado para IR, y negar el borrado. Este patrón reduce la probabilidad de que alguien capture “lo que sea” o elimine evidencia por accidente.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateSnapshotOnlyForIRTaggedVolumes",
"Effect": "Allow",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateTags"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/IR": "true"
}
}
},
{
"Sid": "DenyDeleteSnapshots",
"Effect": "Deny",
"Action": [
"ec2:DeleteSnapshot"
],
"Resource": "*"
}
]
}
Cómo validarlo en AWS durante un incidente: verifica en CloudTrail que CreateSnapshot se ejecutó por el rol de IR previsto, revisa que el snapshot tiene tags de caso (ID de incidente, propietario, timestamp) y confirma que el rol no puede ejecutar DeleteSnapshot. Si tu consulta de CloudTrail no muestra el evento, el snapshot puede haberse hecho en otra cuenta/región o con otra identidad (un hallazgo en sí mismo).
Recomendaciones para entornos corporativos
Si el contenedor comprometido ya no existe, el forense depende de lo que sobrevive al ciclo de vida efímero: logs de red (como VPC Flow Logs), logs de ejecución y auditoría del plano de control. En la práctica, estos registros son los que permiten reconstruir una línea temporal defendible y reducir el tiempo de contención sin basarte en suposiciones.
Cuando hay que capturar estado, los snapshots bajo cuarentena (volúmenes persistentes y, si aplica, discos de nodo) son el mecanismo más operativo en cloud, siempre que estén gobernados por IAM y por un proceso de etiquetado y retención. Y si el pod aún vive, la ventana útil se gana con preparación previa: permisos, playbooks y herramientas open-source para recolectar memoria/señales volátiles antes de que el scheduler haga su trabajo y borre la escena.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.
Francisco Sepúlveda
Instructor de Cloud Computing y Ciberseguridad, Diseñador de Experiencias Formativas
Instructor y consultor en Cloud Computing, Ciberseguridad e IA, con más de 25 años de experiencia en entornos empresariales reales. Diseño e imparto programas de formación técnica combinando experiencia profunda en la materia con diseño de experiencias formativas, para que los conceptos complejos de seguridad realmente se queden. Comparto análisis técnico aplicado en Cloud Security in Practice.
Conoce más →