Análisis forense en Kubernetes y Docker - El nuevo desafío del peritaje informático

Una empresa de fintech descubre a las 6 de la mañana que su API de pagos ha estado procesando transacciones hacia cuentas desconocidas durante la noche. Su infraestructura corre sobre Kubernetes en AWS EKS con 200 pods distribuidos. El problema: los contenedores comprometidos ya han sido reemplazados automáticamente por el orquestador. La escena del crimen se ha limpiado sola.

Este es el nuevo paradigma del análisis forense digital. Los contenedores son efímeros por diseño: se crean, ejecutan y destruyen en segundos. Un perito informático tradicional, acostumbrado a clonar discos duros, está completamente perdido en este entorno.

Mi experiencia como CTO diseñando y operando arquitecturas Kubernetes de producción me permite investigar estos incidentes donde otros peritos no saben ni por dónde empezar.

Por qué los contenedores rompen la forensia tradicional

El problema fundamental: la efimeralidad

En forensia tradicional, el principio básico es preservar la escena. En Kubernetes, esto es imposible:

• Los pods se reinician automáticamente ante cualquier fallo
• El auto-scaling crea y destruye instancias según demanda
• Las imágenes son inmutables: el contenedor no guarda cambios en disco
• Los logs locales desaparecen cuando el pod termina

Qué evidencia existe (y dónde buscarla)

Como arquitecto de sistemas distribuidos, sé que aunque los contenedores son efímeros, dejan rastros si sabes dónde buscar:

Metodología de investigación en entornos containerizados

Fase 1: Contención sin destrucción (0-30 minutos)

El instinto de un equipo de operaciones ante un incidente es matar y recrear los pods comprometidos. Esto destruye evidencia. Mi primera acción es contener sin destruir:

# Aislar pods sospechosos de la red sin terminarlos
kubectl label pods -l app=payment-api quarantine=true
kubectl patch networkpolicy payment-api-netpol -p '
{
  "spec": {
    "podSelector": {
      "matchLabels": {
        "quarantine": "true"
      }
    },
    "policyTypes": ["Ingress", "Egress"],
    "ingress": [],
    "egress": []
  }
}'

# Suspender deployments para evitar recreación
kubectl scale deployment payment-api --replicas=0

Fase 2: Captura de estado del contenedor en vivo

Antes de que el pod desaparezca, capturo todo lo posible:

# Obtener shell en el contenedor comprometido
kubectl exec -it payment-api-compromised-pod -- /bin/sh

# Dentro del contenedor, capturar estado
ps aux > /tmp/processes.txt
netstat -tulpn > /tmp/connections.txt
cat /proc/*/environ > /tmp/environment.txt
cat /etc/passwd /etc/shadow > /tmp/users.txt
find / -mtime -1 -type f > /tmp/modified-files.txt

# Copiar evidencia fuera del contenedor
kubectl cp payment-api-compromised-pod:/tmp/ ./evidence/

Fase 3: Snapshot del sistema de archivos del contenedor

Aunque los contenedores son efímeros, puedo capturar su estado actual:

# Obtener el container ID en el nodo
CONTAINER_ID=$(kubectl get pod payment-api-compromised-pod \
  -o jsonpath='{.status.containerStatuses[0].containerID}' | sed 's/docker:\/\///')

# En el nodo worker (requiere acceso SSH)
sudo docker export $CONTAINER_ID > container-filesystem-$(date +%Y%m%d-%H%M%S).tar

# Calcular hash para cadena de custodia
sha256sum container-filesystem-*.tar > filesystem-hashes.txt

Fase 4: Análisis de la imagen Docker

La imagen base del contenedor es evidencia inmutable:

# Descargar la imagen exacta que se ejecutaba
docker pull registry.empresa.com/payment-api:v2.3.1

# Analizar capas de la imagen
docker history registry.empresa.com/payment-api:v2.3.1 --no-trunc

# Exportar y analizar el sistema de archivos de la imagen
docker save registry.empresa.com/payment-api:v2.3.1 -o image-backup.tar
mkdir image-layers && tar -xf image-backup.tar -C image-layers/

# Buscar diferencias entre imagen y contenedor comprometido
diff -r image-layers/ container-filesystem/

Fase 5: Correlación de logs del orquestador

Kubernetes genera logs a múltiples niveles que debo correlacionar:

# Logs del API server (quién hizo qué en el cluster)
kubectl logs -n kube-system kube-apiserver-master --since=24h > apiserver.log

# Eventos del pod comprometido
kubectl describe pod payment-api-compromised-pod > pod-events.txt

# Audit logs de Kubernetes (si están habilitados)
# Contienen todas las llamadas a la API con usuario y timestamp

Consulta de audit logs para actividad sospechosa:

-- En sistema de logs centralizado
SELECT
  timestamp,
  user.username,
  verb,
  objectRef.resource,
  objectRef.name,
  sourceIPs
FROM kubernetes_audit_logs
WHERE objectRef.namespace = 'production'
  AND timestamp > NOW() - INTERVAL '24 hours'
  AND verb IN ('create', 'update', 'patch', 'delete', 'exec')
ORDER BY timestamp;

Análisis de imágenes Docker comprometidas

Detectar modificaciones maliciosas

Una técnica común de ataque es modificar la imagen en el registry para inyectar código malicioso:

# Comparar digests de imagen entre registry y lo que corre
RUNNING_DIGEST=$(kubectl get pod payment-api-pod \
  -o jsonpath='{.status.containerStatuses[0].imageID}')
REGISTRY_DIGEST=$(docker inspect registry.empresa.com/payment-api:v2.3.1 \
  --format='{{.RepoDigests}}')

if [ "$RUNNING_DIGEST" != "$REGISTRY_DIGEST" ]; then
  echo "ALERTA: La imagen en ejecución difiere del registry"
fi

Análisis de capas para detectar inyección

# Herramienta dive para analizar capas
dive registry.empresa.com/payment-api:v2.3.1

# Buscar archivos sospechosos en cada capa
for layer in image-layers/*/layer.tar; do
  echo "=== Analizando $layer ==="
  tar -tvf "$layer" | grep -E '\.(sh|py|js|php)$'
done

Búsqueda de malware en imágenes

# Escanear imagen con Trivy
trivy image registry.empresa.com/payment-api:v2.3.1

# Escanear con Clair
clair-scanner --ip $(hostname -i) registry.empresa.com/payment-api:v2.3.1

# Análisis manual de binarios sospechosos
strings container-filesystem/usr/local/bin/suspicious-binary | head -100

Caso de estudio: Cryptominer en cluster Kubernetes

El incidente

Una empresa de e-commerce nota que su factura de AWS se ha triplicado. El consumo de CPU en su cluster EKS está al 95% constante, pero las ventas no han aumentado.

Mi investigación

Hora 0-1: Detección y contención

# Identificar pods con consumo anómalo
kubectl top pods --all-namespaces | sort -k3 -n -r | head -20

# Resultado: 15 pods del namespace "monitoring" consumiendo 8 CPUs cada uno
# El namespace "monitoring" solo debería tener Prometheus y Grafana

# Aislar el namespace completo
kubectl label namespace monitoring quarantine=true
kubectl patch networkpolicy -n monitoring default-deny -p '...'

Hora 1-4: Análisis de la imagen comprometida

# La imagen de "prometheus" era sospechosa
kubectl get deployment prometheus -n monitoring -o yaml | grep image
# Resultado: gcr.io/empresa-gcp/prometheus:v2.30.0-security-patch

# Esta imagen no existe en nuestros registros oficiales
# Alguien modificó el deployment para usar una imagen maliciosa

# Descargar y analizar la imagen
docker pull gcr.io/empresa-gcp/prometheus:v2.30.0-security-patch
docker history gcr.io/empresa-gcp/prometheus:v2.30.0-security-patch

# La última capa añadía un binario llamado "metrics-collector"
# En realidad era xmrig (cryptominer)

Hora 4-8: Reconstrucción del vector de ataque

# Análisis de audit logs de Kubernetes
# Encontré:
# - Acceso con ServiceAccount de CI/CD
# - Modificación del deployment de prometheus
# - Cambio de imagen a la versión maliciosa

# El atacante comprometió las credenciales del pipeline de CI/CD
# a través de un repositorio de GitHub público que contenía
# el kubeconfig por error

Timeline reconstruido

Resultado forense

El informe pericial documentó:

• Vector de ataque: Credencial expuesta en repositorio público
• Impacto: $47,000 en costes de computación fraudulenta
• Evidencia técnica: Imagen maliciosa preservada, logs de acceso, timeline completo
• Responsabilidad: Error humano (no malicia interna)

La empresa utilizó el informe para:

1. Reclamación al seguro de ciberseguridad
2. Mejora de políticas de gestión de secretos
3. Documentación para auditoría de compliance

Herramientas especializadas que utilizo

Para análisis de contenedores

Para análisis de Kubernetes

Consideraciones legales específicas

Jurisdicción en clusters multi-región

Un cluster Kubernetes puede tener nodos en múltiples regiones geográficas:

• La evidencia puede estar sujeta a diferentes jurisdicciones
• GDPR aplica si hay datos de ciudadanos UE
• La cadena de custodia debe documentar la ubicación física de cada pieza de evidencia

Preservación de evidencia volátil

Para que la evidencia de contenedores sea admisible:

• Documentar el método de captura antes de ejecutarlo
• Calcular hashes inmediatamente tras la captura
• Mantener integridad de imágenes en registry con firmas digitales
• Timestamp certificado de cada acción de preservación

Cuándo necesitas un perito especializado en contenedores

• Cryptomining detectado en tu infraestructura Kubernetes
• Fuga de datos desde aplicaciones containerizadas
• Compromiso de pipeline CI/CD que despliega a producción
• Modificación de imágenes en tu registry privado
• Escalada de privilegios dentro del cluster

La forensia de contenedores es un campo especializado donde la experiencia operativa es tan importante como el conocimiento forense. No todos los peritos informáticos están preparados para estos entornos.

Sobre el autor: Jonathan Izquierdo es perito informático forense con certificación AWS Security Specialty y más de 15 años diseñando y operando arquitecturas Kubernetes y microservicios en producción. Esta experiencia operativa permite investigaciones más profundas en entornos que la mayoría de peritos nunca han tocado.

> Ver servicios de peritaje cloud y contenedores