Malware en Contenedores: Docker y Kubernetes como Superficie de Ataque

Contenedores: la nueva superficie de ataque masiva

Docker y Kubernetes han transformado cómo se despliega software. Con más del 90% de las organizaciones usando contenedores en alguna capacidad, la superficie de ataque se ha expandido enormemente. Los contenedores no son máquinas virtuales: comparten el kernel del host, lo que significa que un compromiso del contenedor puede escalar al host.

El ecosistema de amenazas en contenedores es diferente al de servidores tradicionales. Las imágenes se descargan de registries públicos (potencialmente maliciosas), los pods en Kubernetes se crean y destruyen constantemente (dificultando la forensia), y los recursos abundantes de los clusters (CPU, RAM, red) son ideales para cryptojacking.

Vectores de ataque en entornos containerizados

Vector 1: imágenes Docker maliciosas

Los registries públicos (Docker Hub, GitHub Container Registry) permiten a cualquiera publicar imágenes. Los atacantes publican imágenes con nombres similares a imágenes populares (typosquatting):

Imagen legítima	Imagen maliciosa (ejemplo)	Malware incluido
nginx	nignx, nginx-latest	Cryptominer
ubuntu	ubunttu, ubuntu-base	Backdoor
mysql	mysqI (I mayúscula)	Credential stealer
alpine	alpinelinux	Reverse shell
python	python-3.11-slim (sin publisher oficial)	Supply chain

Estadísticas: Sysdig reportó más de 1.600 imágenes maliciosas en Docker Hub en un solo análisis de 2023.

Contenido malicioso típico en imágenes:

• Cryptominer (XMRig) ejecutándose como entrypoint
• Reverse shell que conecta al C2 del atacante
• Script que roba variables de entorno (credenciales, API keys)
• Script que escanea la red interna del cluster

Vector 2: APIs expuestas sin autenticación

API	Puerto default	Riesgo si se expone
Docker API	2375 (HTTP), 2376 (HTTPS)	RCE: crear contenedores privilegiados
Kubernetes API	6443, 8443	Control total del cluster
kubelet API	10250	Ejecución de comandos en pods
etcd	2379	Lectura de todos los secrets de Kubernetes

Docker API expuesta: permite crear contenedores con cualquier configuración:

# Un atacante que encuentra Docker API expuesta puede:
curl -X POST http://target:2375/containers/create \
  -H "Content-Type: application/json" \
  -d '{"Image":"alpine","Cmd":["sh"],"Privileged":true,
       "Binds":["/:/host"]}'
# Crea un contenedor privilegiado con el filesystem del host montado en /host
# → Acceso completo al host

Shodan reporta miles de instancias de Docker API expuestas en Internet.

Vector 3: escape de contenedor (container breakout)

Técnicas para salir de un contenedor comprometido al sistema host:

3a. Contenedor privilegiado (--privileged)

Un contenedor privilegiado tiene casi los mismos permisos que root en el host:

# Dentro de un contenedor privilegiado:
# Montar el filesystem del host
mkdir /mnt/host
mount /dev/sda1 /mnt/host

# Acceso al host filesystem
chroot /mnt/host

# O ejecutar comandos via nsenter
nsenter --target 1 --mount --uts --ipc --net --pid -- bash

3b. Socket Docker montado

Si el socket Docker del host está montado en el contenedor:

# Dentro del contenedor con /var/run/docker.sock montado:
# Instalar Docker CLI
apt install docker.io

# Crear un nuevo contenedor privilegiado con acceso al host
docker run -v /:/host --privileged -it alpine chroot /host

3c. CVE-2019-5736 (runc)

Vulnerabilidad en runc que permitía sobrescribir el binario de runc en el host desde un contenedor. Un contenedor malicioso podía obtener ejecución de código como root en el host cuando se ejecutaba docker exec.

3d. Capabilities excesivas

Capability	Riesgo
SYS_ADMIN	mount, umount, pivot_root. Escape trivial
SYS_PTRACE	ptrace en procesos del host. Inyección de código
DAC_READ_SEARCH	Leer cualquier archivo del host
NET_ADMIN	Manipular red del host
SYS_MODULE	Cargar módulos del kernel (rootkit)

Vector 4: supply chain en imágenes

Comprometer la cadena de suministro de imágenes Docker:

• Comprometer una cuenta de Docker Hub con imágenes populares
• Inyectar malware en un layer de una imagen base
• Comprometer un pipeline CI/CD para inyectar código en la imagen durante el build
• Dependency confusion: publicar un paquete con el mismo nombre que uno interno

Malware específico de contenedores

TeamTNT

El grupo más documentado en ataques a contenedores (2020-2022):

Aspecto	Detalle
Objetivo	Cryptojacking en Docker y Kubernetes
Vector	Docker APIs expuestas, credenciales cloud robadas
Payload	XMRig (Monero miner)
Persistencia	Cronjobs, systemd, Docker images troyanizadas
Lateral movement	Escaneo de red interna, robo de SSH keys y credenciales AWS
Innovación	Primer grupo documentado robando credenciales de AWS y GCP de metadata services

Kinsing

Cryptominer que explota vulnerabilidades en aplicaciones containerizadas:

• Explota CVEs en Apache Struts, WebLogic, PHPUnit
• Se propaga lateralmente dentro del cluster Kubernetes
• Persiste creando cronjobs y modificando authorized_keys
• Desactiva agentes de seguridad y competidores (otros miners)

Doki

Backdoor Linux que usa Dogecoin blockchain como C2:

• Desplegado en contenedores Docker comprometidos
• Genera la dirección C2 dinámicamente basándose en transacciones Dogecoin
• Extremadamente difícil de bloquear porque el C2 está en la blockchain

Detección en entornos containerizados

Escáners de imágenes

Herramienta	Tipo	Qué detecta
Trivy (Aqua)	Open source	Vulnerabilidades en imágenes, IaC misconfigs, secrets expuestos
Grype (Anchore)	Open source	Vulnerabilidades en imágenes
Snyk Container	Comercial	Vulnerabilidades, recomendaciones de imagen base
Clair (Quay)	Open source	Vulnerabilidades en layers de imágenes
Docker Scout	Docker Inc.	Vulnerabilidades, SBOM

# Escanear imagen con Trivy
trivy image nginx:latest
trivy image --severity HIGH,CRITICAL myregistry/myapp:1.0

# Escanear imagen con Grype
grype myregistry/myapp:1.0

Runtime security

Herramienta	Tipo	Qué detecta
Falco (Sysdig)	Open source	Syscalls anómalas en contenedores (shell spawn, network, file access)
Tetragon (Cilium)	Open source	eBPF-based runtime enforcement
Sysdig Secure	Comercial	Runtime detection + forensics
Aqua Runtime Protection	Comercial	Behavioral analysis en containers

Reglas Falco para detección de malware

# Detectar shell spawneada en contenedor
- rule: Shell Spawned in Container
  desc: A shell was spawned inside a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, dash, ksh)
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name image=%container.image.repository
     command=%proc.cmdline)
  priority: WARNING

# Detectar cryptominer
- rule: Detect crypto miners using the Stratum protocol
  desc: Malicious process communicating with mining pool
  condition: >
    spawned_process and container and
    (proc.cmdline contains "stratum+tcp" or
     proc.cmdline contains "xmrig" or
     proc.cmdline contains "minerd" or
     proc.cmdline contains "pool.minexmr")
  priority: CRITICAL

# Detectar acceso al Docker socket desde dentro de un contenedor
- rule: Docker Socket Accessed Inside Container
  desc: A process inside a container accessed the Docker socket
  condition: >
    evt.type=connect and container and
    fd.name=/var/run/docker.sock
  priority: CRITICAL

Kubernetes security

# kube-bench: verificar CIS benchmarks
kube-bench run

# kube-hunter: scan de vulnerabilidades del cluster
kube-hunter --remote [cluster-ip]

# Kubescape: scan comprensivo
kubescape scan

Hardening de contenedores

Docker

# NUNCA ejecutar contenedores privilegiados en produccion
docker run --privileged  # ← PROHIBIDO

# Usar usuario no-root
docker run --user 1000:1000 myimage

# Limitar capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE myimage

# Read-only filesystem
docker run --read-only --tmpfs /tmp myimage

# Sin acceso a la red (si no la necesita)
docker run --network none myimage

# Limitar recursos
docker run --memory=256m --cpus=0.5 myimage

# No montar Docker socket
# docker run -v /var/run/docker.sock  # ← NUNCA

Kubernetes

# Pod Security Context restrictivo
apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"

Mapeo MITRE ATT&CK

Técnica	ID	Contexto containers
Deploy Container	T1610	Desplegar contenedor malicioso
Escape to Host	T1611	Container breakout
Container Administration Command	T1609	Exec en container comprometido
Exploit Public-Facing Application	T1190	Vulnerabilidad en app containerizada
Resource Hijacking	T1496	Cryptojacking
Unsecured Credentials	T1552	Secrets de K8s, env vars, metadata
Build Image on Host	T1612	Construir imagen maliciosa en host

---

Fuentes y referencias

• Rice, L. "Container Security." O'Reilly Media, 2020.
• Martin, A. & Hausenblas, M. "Hacking Kubernetes." O'Reilly Media, 2021.
• Aqua Security. "Cloud Native Threat Report 2024." Aqua Security.
• Sysdig. "Cloud Threat Report 2024." Sysdig.
• Falco. "Container Runtime Security." https://falco.org/
• Trivy. "Container Image Vulnerability Scanner." https://github.com/aquasecurity/trivy
• MITRE ATT&CK. "Containers Matrix." https://attack.mitre.org/matrices/enterprise/containers/
• CrowdStrike. "TeamTNT Analysis." CrowdStrike Intelligence.
• Trend Micro. "Container Threats 2024." Trend Micro Research.