2.1 El dispositivo del operador

La pregunta de "¿uso una VM o hardware dedicado para operar?" no tiene una respuesta única. Depende del modelo de amenaza. Para un pentester que trabaja desde casa atacando laboratorios, una VM bien configurada es suficiente y práctica. Para alguien con un adversario capaz de explotar vulnerabilidades del hypervisor, la VM es un riesgo real.

Qué es un VM breakout

Un VM breakout (o VM escape) es una vulnerabilidad que permite a un proceso dentro de una máquina virtual escapar del entorno aislado y ejecutar código en el sistema anfitrión o en otras VMs del mismo hypervisor. Si el breakout tiene éxito, el aislamiento que creías tener no existe.

No son ataques teóricos. Hay CVEs documentados contra los hypervisors más usados:

• VMware: CVE-2017-4902, CVE-2019-5514 (VMSA-2019-0005) — escape por el dispositivo virtual de gráficos y el servidor de drag-and-drop
• VirtualBox: CVE-2019-2525, CVE-2021-2145 — escape vía dispositivos virtuales de red y USB
• QEMU/KVM: CVE-2015-3456 (VENOM) — escape vía el controlador de disquetera virtual, afectó a miles de servidores cloud
• Hyper-V: CVE-2017-0075 — escape en el componente de síntesis de video

Vectores de breakout más comunes

Hardware dedicado: cuándo vale la pena

El hardware dedicado elimina por completo la superficie de ataque del hypervisor. No hay capa de virtualización que explotar, no hay SO anfitrión que comprometer. El sistema operativo corre directamente sobre el hardware.

Tiene sentido en estos escenarios:

• Modelo de amenaza alto: adversarios con capacidad de explotar vulnerabilidades del hypervisor (Estados-nación, grupos APT). Para la mayoría de pentesters esto es excesivo.
• Análisis de malware avanzado: cuando el malware que analizas puede detectar que corre en VM y modificar su comportamiento, o cuando su explotación podría escapar del sandbox.
• Sistema operativo especializado: Qubes OS, Tails y Whonix funcionan mejor — o solo funcionan correctamente — en hardware dedicado.
• Operaciones de larga duración: un laptop dedicado exclusivamente a operaciones sensibles, que nunca toca redes corporativas ni se usa para nada más.

Tails (The Amnesic Incognito Live System) es un sistema operativo diseñado para no dejar rastro. Arranca desde un USB, enruta todo el tráfico por Tor, y cuando lo apagas no queda ningún dato en el equipo — todo lo que ocurrió en esa sesión desaparece de la RAM y el disco nunca fue tocado.

Es la herramienta de elección de periodistas, activistas y operadores que necesitan trabajar en equipos que no controlan (bibliotecas, cibercafés, equipos prestados) sin dejar evidencia de esa actividad.

Crear el USB de Tails

# 1. Descargar la imagen desde la web oficial (siempre verificar la firma GPG)
# https://tails.boum.org/install/download/

# 2. Importar la clave GPG de Tails
gpg --keyserver keyserver.ubuntu.com --recv-keys A490D0F4D311A4153E2BB7CADBB802B258ACD84F

# 3. Verificar la firma de la imagen
gpg --verify tails-amd64-6.x.img.sig tails-amd64-6.x.img

# 4. Identificar el dispositivo USB (¡cuidado con el dispositivo correcto!)
lsblk
# Identifica tu USB, por ejemplo /dev/sdb

# 5. Escribir la imagen al USB con dd
sudo dd if=tails-amd64-6.x.img of=/dev/sdb bs=16M oflag=direct status=progress

# 6. Esperar a que termine y sincronizar
sync
# El USB está listo para arrancar

Almacenamiento persistente cifrado

Por defecto Tails es completamente amnésico — cada sesión empieza de cero. Esto es ideal para OPSEC pero incómodo si necesitas guardar configuraciones, claves PGP, documentos de trabajo o marcadores. La solución es el Almacenamiento Persistente: una partición cifrada con LUKS en el mismo USB que solo se desbloquea con tu passphrase.

Lo que puedes persistir (configurable en la aplicación de Almacenamiento Persistente):

• Archivos personales — documentos, scripts, evidencias de trabajo
• Claves OpenPGP — tu llavero GnuPG, imprescindible si usas PGP con regularidad
• Contraseñas — base de datos KeePassXC cifrada
• Configuración de red — redes WiFi guardadas, configuración de puentes Tor
• Software adicional — paquetes Debian que no vienen por defecto en Tails
• Configuración de Tor Browser — extensiones, configuración de seguridad

Puentes Tor (bridges) para entornos censurados

En algunos países o redes corporativas, la conexión directa a Tor está bloqueada. Los puentes son repetidores Tor no listados públicamente que actúan como punto de entrada alternativo. Tails incluye soporte nativo para configurarlos.

## Tipos de bridges disponibles en Tails:

obfs4       → El más recomendado. Ofusca el tráfico para que no parezca Tor.
              Útil cuando el tráfico Tor está bloqueado o monitorizado.

Snowflake   → Usa WebRTC sobre HTTPS. Muy difícil de bloquear porque
              el tráfico parece una videoconferencia normal.
              El más resistente a la censura activa.

meek-azure  → Usa domain fronting a través de la CDN de Azure.
              El tráfico parece ir a microsoft.com.
              Lento pero muy difícil de bloquear sin bloquear Azure entero.

## Obtener bridges:
# Desde el navegador Tor: https://bridges.torproject.org
# Por correo: bridges@torproject.org (enviar "get transport obfs4")
# Desde la propia interfaz de Tails al conectar a Tor

Para configurar bridges en Tails: al arrancar, antes de conectar a Tor aparece el asistente de conexión. Selecciona "This is a censored network" y elige el tipo de bridge o introduce los tuyos propios.

Whonix aplica un principio elegante: separar en dos máquinas distintas la función de gestionar la conexión Tor y la función de hacer el trabajo. Si la máquina donde trabajas se compromete, el atacante solo ve una IP interna — nunca tu IP real, porque la conexión a internet pasa obligatoriamente por la puerta de enlace.

Cómo funciona la arquitectura

• Whonix-Gateway: una VM Debian mínima cuya única función es gestionar la conexión a Tor. No tiene entorno de escritorio, no se usa para trabajar. Conecta al exterior y presenta al interior una red interna aislada.
• Whonix-Workstation: la VM donde realmente trabajas. Solo tiene una interfaz de red que conecta al Gateway. No puede acceder a internet directamente — si el Gateway no está funcionando, la Workstation no tiene red.
• Red interna: las dos VMs se comunican por una red virtual privada (10.152.152.0/24 por defecto). La Workstation tiene como gateway la IP del Gateway Whonix.

La consecuencia de seguridad más importante: incluso si la Workstation se compromete completamente — un malware con root, un exploit que toma el control total — el atacante solo obtiene la IP interna 10.152.152.10 del Gateway Whonix, nunca tu IP real. Para obtenerla tendría que comprometer también el Gateway, que es una superficie de ataque mucho más pequeña (no ejecuta código de usuario, no navega por webs).

Instalación en VirtualBox

# 1. Descargar las imágenes OVA desde la web oficial
# https://www.whonix.org/wiki/VirtualBox
# Descargar: Whonix-Gateway*.ova y Whonix-Workstation*.ova

# 2. Verificar las firmas antes de importar (imprescindible)
gpg --keyserver keyserver.ubuntu.com --recv-keys 916B8D99C38EAF5E8ADC7A2A8208F7AE42C23B87
gpg --verify Whonix-Gateway*.ova.asc Whonix-Gateway*.ova
gpg --verify Whonix-Workstation*.ova.asc Whonix-Workstation*.ova

# 3. Importar ambas OVAs en VirtualBox
VBoxManage import Whonix-Gateway*.ova
VBoxManage import Whonix-Workstation*.ova

# 4. Arrancar primero el Gateway, luego la Workstation
VBoxManage startvm "Whonix-Gateway" --type headless
VBoxManage startvm "Whonix-Workstation"

# Credenciales por defecto: usuario "user", contraseña "changeme"
# Cambiarlas en el primer arranque es obligatorio

Hardening de Whonix

# 1. Cambiar contraseña del usuario por defecto
passwd user

# 2. Actualizar el sistema
sudo apt update && sudo apt upgrade -y

# 3. Verificar que todo el tráfico sale por Tor (comprobar desde la Workstation)
curl https://check.torproject.org/api/ip
# Debe devolver una IP de nodo de salida Tor, nunca tu IP real

# 4. Comprobar que no hay fugas DNS
nslookup check.torproject.org
# La resolución debe ir por Tor

# 5. Desactivar el portapapeles compartido y carpetas compartidas en VirtualBox
VBoxManage modifyvm "Whonix-Workstation" --clipboard-mode disabled
VBoxManage modifyvm "Whonix-Workstation" --drag-and-drop disabled

# 6. Snapshot del estado inicial limpio
VBoxManage snapshot "Whonix-Gateway" take "inicial-limpio"
VBoxManage snapshot "Whonix-Workstation" take "inicial-limpio"

Errores comunes que rompen el anonimato

• Iniciar sesión en cuentas vinculadas a tu identidad real desde la Workstation. Whonix oculta la IP, no los metadatos de la cuenta.
• Compartir archivos con metadatos — documentos Office, imágenes con EXIF, PDFs con autor. Usa mat2 antes de enviar cualquier archivo.
• Copiar y pegar entre la Workstation y el anfitrión con el portapapeles compartido activo — fuga de datos sensibles al sistema anfitrión.
• Usar el reloj del sistema sin cuidado — si tu zona horaria real se filtra (por ejemplo en timestamps de archivos), puede correlacionarse con tu ubicación geográfica.
• Arrancar la Workstation sin el Gateway activo — sin el Gateway, algunas aplicaciones pueden intentar conexiones directas.

Qubes OS lleva la compartimentalización al extremo: en lugar de tener un sistema operativo con aplicaciones, tienes un gestor de VMs (Xen) que corre decenas de máquinas virtuales ligeras, cada una con un propósito específico. El navegador que usas para banca online corre en una VM distinta al cliente de correo, que corre en una VM distinta al entorno de trabajo, que corre en una VM distinta al análisis de malware.

Si un sitio web explota tu navegador, el atacante obtiene la VM del navegador — que no tiene acceso a tus documentos, a tu correo, ni a tu VPN. El daño queda contenido.

Arquitectura: qubes, templates y dom0

• dom0: el dominio privilegiado que controla el hypervisor Xen y gestiona la pantalla. Nunca tiene acceso a red. Si dom0 se compromete, el sistema entero está comprometido — por eso no se usa para nada más que gestionar el entorno.
• Templates: VMs de solo lectura que sirven como base para los qubes de aplicación. Actualizas el template una vez y todos los qubes que lo usan reciben la actualización. Los cambios que hagas en un qube de aplicación no modifican el template.
• AppVMs (qubes de aplicación): las VMs ligeras donde realmente trabajas. Arrancan en segundos porque el sistema de archivos es el del template (solo lectura) más un disco pequeño para datos del usuario.
• DispVMs (VMs desechables): qubes que se crean al abrirlos y se destruyen al cerrarlos. Para abrir PDFs sospechosos, visitar URLs dudosas, o cualquier cosa que no deba dejar rastro.
• sys-net y sys-firewall: qubes especiales que gestionan la red. El qube de trabajo nunca toca directamente la red física.

Organizar los dominios de seguridad

La forma más efectiva de usar Qubes es definir dominios según el nivel de confianza y el tipo de actividad. Un esquema típico para un operador:

Comandos útiles desde dom0

# Ver todos los qubes y su estado
qvm-ls

# Arrancar un qube
qvm-start pentest

# Apagar un qube
qvm-shutdown pentest

# Abrir un terminal en un qube específico
qvm-run pentest "gnome-terminal"

# Ejecutar un comando en un qube desde dom0
qvm-run -u root vault "apt update"

# Copiar un archivo de dom0 a un qube
qvm-copy-to-vm vault /ruta/al/archivo

# Abrir una URL en un qube desechable (sin dejar rastro)
qvm-open-in-dvm https://url-sospechosa.com

# Ver el consumo de recursos de todos los qubes
xl top

# Crear un nuevo qube basado en un template
qvm-create --template debian-12 --label red nuevo-pentest

# Configurar el networking de un qube (via sys-whonix para Tor)
qvm-prefs anon netvm sys-whonix

Un dispositivo sin disco local es un dispositivo donde el sistema operativo no vive en el hardware del equipo sino en otro lugar: en la red (netboot/PXE) o completamente en RAM. La ventaja para OPSEC es radical: si el equipo es confiscado, no hay nada que analizar. No hay disco, no hay datos, no hay evidencia.

PXE y netboot: arrancar desde la red

PXE (Preboot eXecution Environment) es un estándar que permite a un equipo arrancar desde la red en lugar de desde un disco local. El equipo contacta a un servidor DHCP que le dice la dirección de un servidor TFTP, descarga el bootloader y el SO desde ahí, y arranca completamente en RAM.

# En el servidor (por ejemplo, una Raspberry Pi en tu red local)

# 1. Instalar dnsmasq (DHCP + TFTP) y nginx (para servir el SO)
sudo apt install -y dnsmasq nginx

# 2. Configurar dnsmasq para PXE
cat > /etc/dnsmasq.d/pxe.conf << 'EOF'
interface=eth0
dhcp-range=192.168.100.50,192.168.100.100,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp
log-dhcp
EOF

# 3. Crear el directorio TFTP y copiar los archivos de arranque
sudo mkdir -p /srv/tftp/pxelinux.cfg
sudo apt install -y pxelinux syslinux-common
sudo cp /usr/lib/PXELINUX/pxelinux.0 /srv/tftp/
sudo cp /usr/lib/syslinux/modules/bios/ldlinux.c32 /srv/tftp/

# 4. Configuración del menú de arranque PXE
cat > /srv/tftp/pxelinux.cfg/default << 'EOF'
DEFAULT kali
LABEL kali
  MENU LABEL Kali Linux Live (RAM)
  KERNEL vmlinuz
  APPEND initrd=initrd.img boot=live fetch=http://192.168.100.1/kali.squashfs
EOF

# 5. Reiniciar dnsmasq
sudo systemctl restart dnsmasq

Sistema completamente en RAM

La aproximación más simple al sistema sin disco es arrancar Tails o cualquier distribución live desde USB y asegurarse de que no monta particiones locales. Tails ya hace esto por defecto. Para Kali en modo live RAM-only, el parámetro de kernel relevante es toram:

# En el menú de arranque de Kali Live, editar la entrada y añadir "toram"
# Esto copia el sistema de archivos completo a RAM al arrancar
# Una vez en RAM el USB puede retirarse

linux /live/vmlinuz boot=live toram quiet splash

# Ventajas de toram:
# - El USB puede retirarse (no hay evidencia física del medio)
# - Más rápido que leer del USB durante la sesión
# - Al apagar, la RAM se descarga y no queda nada

# Requisito: suficiente RAM (Kali Live necesita ~4-8 GB en RAM)

Un equipo air-gapped está físicamente desconectado de cualquier red: sin WiFi, sin Ethernet, sin Bluetooth, sin NFC. La teoría dice que sin conexión de red no hay forma de exfiltrar datos ni de comprometer el sistema remotamente. La realidad es más complicada.

Los servicios de inteligencia y los investigadores de seguridad han demostrado durante los últimos años que el air-gap no es una barrera impenetrable. Hay múltiples canales de exfiltración que no usan redes convencionales.

El vector USB: la brecha más común

El mayor riesgo práctico para los equipos air-gapped no son los ataques electromagnéticos sofisticados — es el USB. La mayoría de air-gap se rompen por USB maliciosos, ya sea porque alguien conecta un dispositivo comprometido sin saberlo, o por un ataque deliberado como el que usó Stuxnet para saltar el air-gap de las instalaciones nucleares iraníes en 2010.

• BadUSB: un dispositivo USB cuyo firmware está reprogramado para emular un teclado u otro dispositivo HID. Al conectarse parece un pendrive normal pero envía pulsaciones de teclado que ejecutan comandos. No hay forma de detectarlo visualmente.
• Rubber Ducky y similares: dispositivos comerciales diseñados para ataques BadUSB — parecen pendrives normales, actúan como teclados de inyección de comandos.
• USB kill: dispositivo que descarga un pulso eléctrico para destruir físicamente el equipo al conectarse.
• Stuxnet (caso real): el gusano más conocido que saltó un air-gap. Se propagó por USB infectados entre técnicos que no sabían que llevaban el malware. Una vez dentro, saboteó centrifugadoras de uranio durante meses antes de ser descubierto.

# Deshabilitar completamente el kernel USB HID (teclados y ratones USB)
# Solo si usas teclado PS/2 o estás seguros de los dispositivos conectados
echo "blacklist usbhid" | sudo tee /etc/modprobe.d/blacklist-usbhid.conf

# Autorizar solo USBs específicos mediante su ID de fabricante y producto
# USBGuard es la herramienta estándar para esto
sudo apt install -y usbguard

# Generar una política basada en los USBs actualmente conectados (los de confianza)
sudo usbguard generate-policy > /etc/usbguard/rules.conf

# Activar USBGuard (cualquier USB no autorizado quedará bloqueado)
sudo systemctl enable --now usbguard

# Ver dispositivos USB conectados y su estado de autorización
sudo usbguard list-devices

# Autorizar manualmente un dispositivo específico
sudo usbguard allow-device 3   # el número viene de list-devices

# Bloquear un dispositivo
sudo usbguard block-device 5

Emisiones TEMPEST: los canales electromagnéticos

TEMPEST es el nombre que la NSA y otros organismos dan a las investigaciones sobre emanaciones electromagnéticas involuntarias de equipos electrónicos — y a las técnicas para interceptarlas. Todo equipo electrónico en funcionamiento emite radiación electromagnética que puede ser capturada con antenas y procesada para reconstruir información.

Los ataques TEMPEST demostrados incluyen:

• Van Eck phreaking: reconstruir la imagen de un monitor CRT o LCD capturando las emisiones del cable de vídeo y el controlador gráfico. Demostrado en 1985 por Wim van Eck. Con equipos modernos y antenas SDR, el rango práctico es de decenas de metros.
• Ataque al bus de memoria: las señales del bus DDR emiten suficiente radiación para reconstruir parcialmente los datos que pasan por él.
• TEMPEST sobre FM (AirHopper): investigadores del Ben-Gurion University demostraron en 2014 que la GPU puede modularse para emitir señales FM capturables con un receptor de radio a varios metros.
• GSMem: emisiones del bus de memoria moduladas para transmitir datos a un teléfono móvil cercano.
• NOISE: exfiltración usando las emisiones de los ventiladores del CPU modificando la carga del procesador.
• PowerHammer: exfiltración de datos a través de las fluctuaciones de voltaje en la línea eléctrica.

Otros canales de exfiltración probados