¿Qué hace diferente al forense de contenedores del forense tradicional?

Los contenedores son efímeros por diseño: pueden crearse y destruirse en segundos. La evidencia existe en capas de imagen, volúmenes y logs del orquestador, no en discos persistentes. Si no se actúa con rapidez, la evidencia desaparece irreversiblemente.

¿Se puede usar evidencia de contenedores Docker en un juicio?

Sí, siempre que se documente la cadena de custodia, se preserven los hashes de las imágenes y capas, se exporten los logs con sus marcas temporales y se siga una metodología forense reconocida como ISO 27037.

¿Qué ocurre con la evidencia cuando un contenedor se destruye?

El sistema de archivos del contenedor desaparece, pero las capas de la imagen base permanecen, los volúmenes montados pueden conservar datos, y los logs del daemon Docker y del orquestador Kubernetes mantienen registros de la actividad.

Forense de Contenedores - Docker y Kubernetes

¿Qué es el forense de contenedores?

El forense de contenedores es la rama del análisis forense digital que se ocupa de la investigación de incidentes de seguridad en entornos basados en contenedores, principalmente Docker y Kubernetes. A diferencia del forense tradicional, donde la evidencia reside en discos duros persistentes que pueden clonarse con calma, en contenedores la evidencia es efímera por diseño: un contenedor puede nacer, ejecutarse y destruirse en cuestión de segundos, llevándose consigo todos los datos de su sistema de archivos temporal.

Esta especialidad ha ganado una relevancia enorme en los últimos años. Según datos de CNCF (Cloud Native Computing Foundation), más del 90% de las organizaciones que utilizan la nube emplean contenedores en producción. Esto significa que cada vez más incidentes de seguridad, fraudes y delitos digitales dejan sus rastros en infraestructuras contenerizadas, y los peritos informáticos deben saber dónde buscar y cómo preservar esa evidencia antes de que desaparezca.

El reto fundamental es doble: por un lado, la volatilidad extrema de los contenedores exige protocolos de respuesta inmediata; por otro lado, la complejidad de las arquitecturas de microservicios distribuye la evidencia entre decenas o cientos de componentes interconectados, requiriendo una visión global del sistema para reconstruir lo que ocurrió.

La evidencia desaparece en segundos

En un entorno Kubernetes con auto-scaling, un pod comprometido puede ser destruido automáticamente por el orquestador y reemplazado por uno nuevo en cuestión de segundos. Si no se han configurado previamente mecanismos de retención de logs y captura de estado, la evidencia se pierde de forma irreversible. El tiempo de reacción es crítico.

Arquitectura de contenedores: lo que el perito debe entender

Capas de imagen Docker

Docker construye imágenes mediante un sistema de capas (layers) apiladas. Cada instrucción en un Dockerfile genera una capa inmutable. El contenedor en ejecución añade una capa de escritura temporal encima.

Anatomía de un contenedor Docker:
┌──────────────────────────────────┐
│ Capa de escritura (efímera)      │ ← Cambios del contenedor en ejecución
│ Se pierde al destruir contenedor │
├──────────────────────────────────┤
│ Capa de imagen: app instalada    │ ← Inmutable, con hash SHA-256
├──────────────────────────────────┤
│ Capa de imagen: dependencias     │ ← Inmutable, con hash SHA-256
├──────────────────────────────────┤
│ Capa base: ubuntu:22.04          │ ← Inmutable, con hash SHA-256
└──────────────────────────────────┘
│ Volúmenes montados (persistentes)│ ← Datos que sobreviven al contenedor
└──────────────────────────────────┘

Componente	Persistencia	Valor forense
Capas de imagen	Permanente hasta borrado explícito	Hash verificable, contenido inmutable
Capa de escritura	Solo mientras el contenedor existe	Cambios realizados en runtime, alta volatilidad
Volúmenes	Permanente (independiente del contenedor)	Datos de aplicación, bases de datos, logs
Bind mounts	Permanente (en el host)	Archivos del host accesibles desde el contenedor
tmpfs mounts	Solo en memoria RAM	Se pierde al parar el contenedor

Arquitectura Kubernetes

En Kubernetes, la complejidad aumenta significativamente. Los componentes relevantes para el forense son:

Componente	Función	Evidencia que genera
Pod	Unidad mínima de despliegue (uno o más contenedores)	Logs de contenedores, estado del pod
Node	Máquina (física o virtual) que ejecuta pods	Logs de kubelet, containerd/Docker, sistema
etcd	Base de datos del estado del clúster	Historial de configuraciones, secretos, despliegues
API Server	Punto de entrada para todas las operaciones	Audit logs de todas las llamadas a la API
Controller Manager	Gestiona el estado deseado vs. real	Logs de escalado, reinicios, reconfiguraciones
Ingress/Services	Gestión de tráfico de red	Logs de acceso, IPs de origen

Kubernetes audit logs: la joya forense

Los audit logs del API Server de Kubernetes registran quién hizo qué, cuándo y desde dónde. Son el equivalente a los Event Logs de Windows para entornos Kubernetes. Si están habilitados con nivel RequestResponse, capturan incluso el contenido completo de las peticiones y respuestas, proporcionando una reconstrucción detallada de todas las acciones realizadas en el clúster.

Fuentes de evidencia en contenedores

Evidencia del daemon Docker

Fuente	Ubicación típica	Información contenida
Docker daemon logs	`/var/log/docker.log` o journald	Creación, inicio, parada y eliminación de contenedores
Container logs	`/var/lib/docker/containers/<id>/<id>-json.log`	stdout/stderr de la aplicación
Image layers	`/var/lib/docker/overlay2/`	Contenido inmutable de las capas de imagen
Container layer	`/var/lib/docker/overlay2/<id>/diff/`	Cambios realizados en runtime
Docker events	`docker events` (en tiempo real)	Timeline de operaciones sobre contenedores
Docker inspect	`docker inspect <container>`	Configuración completa, variables de entorno, mounts
Volúmenes	`/var/lib/docker/volumes/`	Datos persistentes de la aplicación

Evidencia del orquestador Kubernetes

Fuente	Comando / ubicación	Información contenida
Audit logs	Configurado en API Server	Todas las llamadas API con usuario, recurso, acción
Pod logs	`kubectl logs <pod>`	Salida de aplicación (rotación según configuración)
Events	`kubectl get events`	Eventos del clúster (solo retención 1 hora por defecto)
etcd snapshots	`etcdctl snapshot save`	Estado completo del clúster en un momento dado
Node logs	journald en cada nodo	kubelet, containerd, kernel
Network policies	`kubectl get networkpolicies`	Reglas de comunicación entre pods
RBAC config	`kubectl get clusterrolebindings`	Permisos de usuarios y service accounts

Evidencia de red en contenedores

Fuente	Herramienta	Utilidad forense
CNI plugin logs	Calico, Cilium, Flannel	Comunicación entre pods, políticas aplicadas
Service mesh	Istio, Linkerd (Envoy sidecar)	Tráfico HTTP detallado entre microservicios
Ingress controller	Nginx, Traefik logs	Peticiones externas con IPs de origen
DNS logs	CoreDNS queries	Resolución de nombres, posible exfiltración DNS
Network flow logs	Cilium Hubble, Calico logs	Flujos de red entre pods con timestamps

Metodología de investigación forense

Detección y contención inmediata: Al detectar un contenedor comprometido, NO destruirlo. Aislarlo de la red (Network Policy deny-all) pero mantenerlo vivo para preservar la capa de escritura y la memoria.
Captura de evidencia volátil: Exportar el sistema de archivos del contenedor (docker export), capturar logs en tiempo real, guardar el estado del pod (kubectl describe pod), y si es posible, capturar la memoria del proceso.
Preservación de imágenes: Guardar la imagen exacta del contenedor (docker save) con todos sus layers. Documentar el hash SHA-256 de cada capa. Comparar con la imagen original del registro para detectar alteraciones.
Adquisición de logs: Exportar logs del contenedor, del daemon Docker, del API Server de Kubernetes, de etcd, y de cualquier sistema de logging centralizado (ELK, Loki, Datadog).
Análisis de capas: Comparar cada capa de la imagen con la versión conocida del registro. Las diferencias revelan modificaciones realizadas por el atacante. Analizar la capa de escritura para encontrar archivos creados, modificados o eliminados durante la ejecución.
Correlación y timeline: Unificar timestamps de todas las fuentes de evidencia para reconstruir la secuencia de eventos. Correlacionar actividad del contenedor comprometido con otros pods, servicios y accesos al API Server.
Documentación y cadena de custodia: Documentar cada paso con hashes SHA-256, capturas de pantalla con timestamps y metodología reproducible, siguiendo las directrices de ISO 27037.

Técnicas de análisis forense en Docker

Análisis de capas de imagen

Cada capa de una imagen Docker tiene un hash SHA-256 único. Comparar las capas de un contenedor sospechoso con la imagen original del registro permite detectar modificaciones.

Técnica	Comando	Propósito
Listar capas	`docker history --no-trunc <image>`	Ver todas las capas y sus comandos
Exportar imagen	`docker save <image> -o image.tar`	Obtener archivo tar con todas las capas
Exportar contenedor	`docker export <container> -o container.tar`	Sistema de archivos completo aplanado
Comparar con original	`docker diff <container>`	Archivos añadidos (A), cambiados (C) o eliminados (D)
Inspeccionar config	`docker inspect <container>`	Variables de entorno, puertos, mounts, command

Análisis de la capa de escritura

La capa de escritura contiene todos los cambios realizados durante la ejecución del contenedor. Es la fuente de evidencia más valiosa y la más efímera.

Estructura de overlay2 (driver por defecto):
/var/lib/docker/overlay2/
├── <layer-id>/
│   ├── diff/          ← Contenido de la capa
│   ├── merged/        ← Vista unificada de todas las capas
│   ├── work/          ← Directorio de trabajo de overlayfs
│   └── lower          ← Referencia a capas inferiores
└── <container-layer-id>/
    └── diff/          ← CAMBIOS del contenedor en ejecución
        ├── tmp/       ← Archivos temporales creados
        ├── var/log/   ← Logs generados
        └── etc/       ← Configuración modificada

Análisis de imágenes maliciosas

En ataques de supply chain, los atacantes comprometen imágenes base o dependencias para inyectar código malicioso.

Indicador	Qué buscar	Herramienta
Capas inesperadas	Instrucciones RUN que descargan binarios externos	`docker history`, Dive
Binarios sospechosos	Ejecutables no presentes en la imagen original	Trivy, Grype
Variables de entorno	Credenciales, tokens API, URLs de C2	`docker inspect`, Syft
Puertos expuestos	Puertos no documentados en la aplicación	`docker inspect`, Dockerfile
Entrypoint modificado	Script de inicio diferente al esperado	`docker inspect`
Vulnerabilidades conocidas	CVEs en paquetes instalados	Trivy, Snyk Container

Imágenes troyanizadas en registros públicos

Se han documentado múltiples casos de imágenes maliciosas publicadas en Docker Hub con nombres similares a imágenes legítimas (typosquatting). En 2024, investigadores de Sysdig identificaron miles de imágenes en Docker Hub que contenían criptomineros, backdoors o herramientas de exfiltración. Verificar la procedencia y los hashes de las imágenes utilizadas en producción es una medida de seguridad básica y un paso forense esencial.

Análisis forense en Kubernetes

Investigación de pods comprometidos

Paso	Acción	Evidencia obtenida
1	`kubectl describe pod <pod>`	Estado, eventos, contenedores, mounts, service account
2	`kubectl logs <pod> --all-containers --timestamps`	Salida de todos los contenedores con marcas temporales
3	`kubectl exec <pod> -- cat /proc/1/cmdline`	Comando real ejecutado por el proceso principal
4	`kubectl exec <pod> -- ls -laR /tmp /var/tmp`	Archivos temporales sospechosos
5	`kubectl get pod <pod> -o yaml`	Especificación completa del pod incluyendo secretos referenciados
6	`kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa>`	Permisos del service account del pod

RBAC y escalada de privilegios en Kubernetes

La escalada de privilegios en Kubernetes tiene vectores específicos:

Vector	Descripción	Indicador forense
Service Account con exceso de permisos	SA con cluster-admin o permisos amplios	`kubectl get clusterrolebindings`
Pod con privileged: true	Contenedor con acceso total al host	Pod spec, audit logs de creación
hostPID/hostNetwork	Pod que comparte namespace del host	Acceso a procesos y red del nodo
Montaje de /var/run/docker.sock	Acceso al daemon Docker desde el contenedor	Puede crear contenedores privilegiados
Montaje de hostPath /	Acceso completo al filesystem del nodo	Lectura de secrets, kubeconfig, etc.
Token de SA montado automáticamente	Permite llamadas API desde el pod	`/var/run/secrets/kubernetes.io/serviceaccount/token`

Escape de contenedores

El escape de contenedores es una de las amenazas más graves: un atacante que consigue salir del contenedor obtiene acceso al host subyacente.

Técnica de escape	Requisito	Impacto
Contenedor privilegiado	`privileged: true`	Acceso completo al host
CVE-2019-5736 (runc)	runc vulnerable	Ejecución en host via `/proc/self/exe`
CVE-2022-0185	Kernel vulnerable + `CAP_SYS_ADMIN`	Escape via file_system_context
Docker socket montado	`/var/run/docker.sock` accesible	Crear contenedor privilegiado en host
Kernel exploit desde contenedor	`CAP_SYS_ADMIN` o seccomp deshabilitado	Explotación directa del kernel
cgroups release_agent	cgroup v1 + privileged	Escritura en release_agent del host

Caso práctico: criptominero en clúster Kubernetes

Escenario

Una empresa SaaS con infraestructura en Kubernetes detecta un incremento del 300% en su factura de cloud computing. Los costes de CPU se han disparado sin motivo aparente. Se sospecha de un criptominero desplegado en el clúster.

Investigación forense

Fase 1: Detección y contención

Descubrimientos iniciales:
├── Pod sospechoso: "monitoring-agent-7f8b9" en namespace "kube-system"
│   └── Imagen: registry.internal/monitoring:latest (no coincide con registro)
│   └── CPU request: 100m, pero consumo real: 4000m (40x superior)
├── Contenedor ejecutando proceso "xmrig" (criptominero Monero)
│   └── Pool: stratum+tcp://pool.minexmr.com:4444
│   └── Wallet: 4Abc...xyz (dirección Monero del atacante)
└── Network policy: sin restricciones de salida (egress allow all)

Fase 2: Preservación de evidencia

Acción	Comando	Hash SHA-256 de evidencia
Exportar pod spec	`kubectl get pod -o yaml > pod-spec.yaml`	Documentado
Exportar logs	`kubectl logs --timestamps > pod-logs.txt`	Documentado
Guardar imagen	`docker save registry.internal/monitoring:latest > image.tar`	Documentado
Capturar audit logs	Exportar desde API Server los últimos 30 días	Documentado
Snapshot de etcd	`etcdctl snapshot save etcd-backup.db`	Documentado
Network flows	Exportar registros de Cilium Hubble	Documentado

Fase 3: Análisis de la imagen maliciosa

Comparación de capas:
Imagen legítima (monitoring:v2.3.1):
├── Layer 1: alpine:3.18 (sha256:abc123...)  ✓ Coincide
├── Layer 2: prometheus libraries             ✓ Coincide
└── Layer 3: monitoring binary                ✓ Coincide

Imagen desplegada (monitoring:latest):
├── Layer 1: alpine:3.18 (sha256:abc123...)  ✓ Coincide
├── Layer 2: prometheus libraries             ✓ Coincide
├── Layer 3: monitoring binary                ✓ Coincide
└── Layer 4: NUEVA CAPA SOSPECHOSA           ✗ No existe en original
    ├── /usr/bin/xmrig (criptominero)
    ├── /etc/xmrig/config.json (configuración del pool)
    └── /usr/local/bin/entrypoint.sh (script modificado)

Fase 4: Reconstrucción del ataque via audit logs

Timeline del incidente:
├── Día -21: Creación de service account "monitoring-sa" con permisos de deploy
│   └── Audit: user "dev-carlos" (comprometido via phishing anterior)
│   └── IP: 185.xx.xx.xx (VPN comercial, no corporativa)
├── Día -20: Push de imagen troyanizada al registro interno
│   └── Tag: monitoring:latest (sobrescribe imagen legítima)
│   └── Capa extra con xmrig embebido
├── Día -20: Deployment actualizado para usar :latest en vez de :v2.3.1
│   └── Audit: kubectl set image deployment/monitoring
│   └── Réplicas: 1 → 3 (más capacidad de minado)
├── Día -19 a -1: Minado activo (21 días)
│   └── Consumo: ~12 CPU cores constante
│   └── Coste cloud estimado: 3.800€
└── Día 0: Equipo de finanzas alerta por factura anómala

Fase 5: Hallazgos clave

Evidencia	Fuente	Significado
Imagen con capa extra	Registro interno (harbor)	Supply chain comprometido
Service account creado	Kubernetes audit logs	Acceso no autorizado al clúster
Credenciales de dev-carlos	Análisis de phishing previo	Vector de acceso inicial
Conexiones a pool.minexmr.com	Network flow logs (Cilium)	Exfiltración de recursos (criptominado)
Wallet Monero	config.json del xmrig	Beneficiario del ataque

Conclusiones del informe pericial

El informe documenta que el atacante comprometió credenciales de un desarrollador mediante phishing, usó esas credenciales para acceder al clúster Kubernetes, creó un service account con permisos de despliegue, inyectó un criptominero en una imagen Docker del registro interno, y minó criptomoneda Monero durante 21 días, generando un perjuicio económico de aproximadamente 3.800 euros en costes de cloud.

Marco legal en España

Tipificación penal del ataque a contenedores

Artículo CP	Tipo delictivo	Aplicación al caso
Art. 197 bis	Acceso ilícito a sistemas	Acceso no autorizado al clúster Kubernetes
Art. 256	Uso no autorizado de recursos	Criptominado con recursos de la empresa
Art. 264	Daños informáticos	Modificación de imágenes y despliegues
Art. 264 bis	Obstrucción de sistemas	Degradación del rendimiento por consumo de CPU
Art. 248	Estafa informática	Beneficio económico obtenido mediante acceso ilícito

Relevancia de la ISO 27037 en contenedores

El estándar ISO 27037 es especialmente relevante porque establece principios para la preservación de evidencia que deben adaptarse al contexto efímero de los contenedores:

Principio de no alteración: Usar docker export (solo lectura) en vez de interactuar con el contenedor
Cadena de custodia: Documentar hash SHA-256 de cada capa de imagen y log exportado
Proporcionalidad: Equilibrar la urgencia de la captura con la completitud de la evidencia
Reproducibilidad: Documentar los comandos exactos utilizados para la adquisición

Obligaciones RGPD

Si el contenedor comprometido procesaba datos personales (aplicaciones web, APIs, bases de datos):

Notificación a la AEPD en 72 horas si hay brecha confirmada
Determinar si los datos fueron exfiltrados o solo accedidos
Evaluar el impacto en los derechos de los interesados
Documentar las medidas de seguridad del clúster Kubernetes

Herramientas forenses para contenedores

Herramienta	Función principal	Uso forense
Dive	Explorar capas de imagen Docker	Identificar capas añadidas o modificadas
Trivy	Escáner de vulnerabilidades	Detectar CVEs y secretos en imágenes
Sysdig Inspect	Captura de actividad de sistema en contenedores	Reconstruir syscalls, I/O de archivos y red
Falco	Detección de comportamiento anómalo runtime	Alertas de actividad sospechosa en contenedores
kube-forensics	Automatización de captura forense en K8s	Crear snapshots de pods sospechosos
Grype	Análisis de composición de imágenes	Verificar integridad de dependencias
Syft	SBOM (Software Bill of Materials)	Inventario de componentes de la imagen
Cilium Hubble	Observabilidad de red en Kubernetes	Flujos de red entre pods con timestamps
kubectl-capture	Plugin kubectl para captura forense	Automatizar preservación de evidencia en pods
Autopsy	Análisis forense de disco	Analizar volúmenes persistentes exportados

Sysdig: la herramienta clave

Sysdig captura todas las llamadas al sistema (syscalls) realizadas por los procesos dentro de un contenedor, incluyendo acceso a archivos, conexiones de red y ejecución de comandos. Es el equivalente a una “caja negra” del contenedor. Si se configura previamente, proporciona evidencia forense incluso después de que el contenedor haya sido destruido.

Relación con otros conceptos

El forense de contenedores no es una disciplina aislada, sino que se complementa con otras áreas del análisis forense digital:

Cloud Forensics: Los contenedores casi siempre se ejecutan en la nube. El forense de contenedores es una especialización dentro del cloud forensics que se centra en la capa de contenedorización, mientras que cloud forensics abarca también la infraestructura IaaS subyacente (VMs, redes, almacenamiento).
Cloud Activity Analysis: Los audit logs del proveedor cloud (CloudTrail en AWS, Activity Log en Azure) complementan los logs del clúster Kubernetes. Un ataque a contenedores frecuentemente deja rastros tanto en la API de Kubernetes como en la API del proveedor cloud.
Logs de Sistema: Los logs son la columna vertebral del forense de contenedores. Desde los logs del daemon Docker hasta los audit logs de Kubernetes, pasando por los logs de la aplicación y del orquestador, todo el análisis se basa en correlacionar logs de múltiples fuentes.
ISO 27037: Proporciona el marco metodológico para la adquisición y preservación de evidencia digital, que debe adaptarse a las particularidades de los entornos efímeros de contenedores.

Buenas prácticas de preparación forense

Práctica	Implementación	Impacto en capacidad forense
Habilitar Kubernetes audit logs	Nivel RequestResponse en API Server	Registro completo de todas las acciones
Logging centralizado	ELK, Loki, Datadog con retención de 90+ días	Logs disponibles incluso tras destruir pods
Imágenes firmadas (Sigstore/Cosign)	Verificar firmas en admission controller	Detectar imágenes no autorizadas
Immutable tags	Prohibir `latest`, usar tags versionados	Trazabilidad de qué imagen se ejecutó
Network policies restrictivas	Default deny + allow explícito	Limitar exfiltración y detectar tráfico anómalo
Runtime security (Falco/Sysdig)	Monitorización de syscalls en tiempo real	Detección temprana y captura de evidencia
RBAC mínimo privilegio	Auditar service accounts y roles	Limitar alcance de credenciales comprometidas
Backup regular de etcd	Snapshots diarios con retención	Reconstruir estado del clúster en cualquier momento

Conclusión

El forense de contenedores es una especialidad cada vez más necesaria a medida que las empresas migran sus aplicaciones a arquitecturas basadas en Docker y Kubernetes. El reto principal es la naturaleza efímera de los contenedores: la evidencia puede desaparecer en segundos si no se actúa con rapidez y metodología.

Para el perito informático forense, dominar esta disciplina requiere:

Comprender la arquitectura de capas de Docker y el funcionamiento de Kubernetes
Saber dónde reside la evidencia (daemon logs, audit logs, image layers, etcd)
Actuar con extrema rapidez para preservar la evidencia volátil
Adaptar la metodología ISO 27037 al contexto efímero de los contenedores
Utilizar herramientas especializadas (Sysdig, Dive, Trivy, Falco) para el análisis
Correlacionar múltiples fuentes de evidencia distribuidas entre contenedores, nodos y orquestadores

La preparación previa es fundamental: una empresa que no tiene logging centralizado ni audit logs habilitados tendrá muy poca evidencia disponible cuando ocurra un incidente. Configurar estas capacidades de antemano es una inversión directa en capacidad de respuesta forense.

¿Necesitas investigar un incidente en tu infraestructura de contenedores? Contacta con Digital Perito para un análisis forense especializado en Docker y Kubernetes.

Última actualización: 10 de febrero de 2026 Categoría: Técnico Código: CNT-001