Cómo montar un laboratorio de análisis de malware aislado

¿Qué es exactamente un laboratorio de análisis aislado?

Un laboratorio de análisis de malware aislado es un conjunto de máquinas virtuales sin ninguna ruta de red hacia tu equipo, tu red local o Internet, en el que puedes ejecutar código malicioso y observar qué hace. Lo que define el laboratorio no es el hipervisor ni las herramientas que instales: es la topología de red. Si la muestra puede alcanzar algo que te importe, no tienes un laboratorio, tienes un incidente.

Esta guía monta ese laboratorio de principio a fin con VirtualBox, explica por qué tres de los cuatro modos de red que ofrece cualquier hipervisor no sirven, y dedica una sección entera a lo que casi ningún tutorial incluye: comprobar que el aislamiento funciona de verdad antes de acercarte a una muestra real.

Doy por hecho que sabes instalar un sistema operativo en una máquina virtual. Todo lo demás va explicado. Los comandos son de VirtualBox porque es gratuito y multiplataforma; en VMware los conceptos son idénticos y solo cambian los nombres (lo que VirtualBox llama red interna, VMware lo llama segmento de LAN).

¿De qué te tienes que proteger exactamente?

«Aislar el malware» suena obvio hasta que te preguntas de qué. Merece la pena enumerarlo, porque cada riesgo se mitiga con una decisión de diseño distinta y es fácil taparlos a medias:

El tercero es el que más se subestima. Si detonas una muestra con salida real a Internet, no solo te expones: además avisas al operador, que puede retirar la infraestructura antes de que termines de documentarla. En un análisis serio, la salida a Internet no se corta solo por seguridad, se corta por método.

¿Qué modo de red aísla de verdad y cuál solo lo parece?

Aquí es donde se cae la mayoría de laboratorios caseros. Todo hipervisor ofrece cuatro modos de red y solo uno sirve para detonar malware:

El modo correcto es la red interna: un switch virtual puramente en memoria del hipervisor, sin ningún adaptador en el host. Las máquinas conectadas a él se ven entre sí y con nada más. La contrapartida es que pierdes también el acceso legítimo (no puedes copiar herramientas por red), y por eso el laboratorio necesita una segunda máquina que haga de Internet falso.

¿Cómo se construye el laboratorio paso a paso?

Dos máquinas virtuales: una de análisis (Windows, que es donde vive el 90 % del malware que vas a ver) y una de servicios (Linux, que simula Internet y captura el tráfico).

1. La máquina de servicios

Usa REMnux, una distribución basada en Ubuntu mantenida por Lenny Zeltser y orientada precisamente a esto. Trae INetSim, FakeNet-NG, Wireshark y el resto del utillaje ya instalado y configurado, así que te ahorra una tarde entera.

2. La máquina de análisis

Un Windows 10 o 11 limpio y, encima, FLARE-VM, el instalador de Mandiant que despliega el arsenal de ingeniería inversa. Instálalo con la red todavía en NAT, porque necesita descargar paquetes; en cuanto termine, se corta la salida y no se vuelve a abrir.

3. Cortar la salida y unir las dos máquinas

Con ambas VM apagadas, se pasan las dos a la misma red interna. El nombre (labnet) es arbitrario, pero tiene que coincidir: es lo que actúa de switch.

# Ambas VM apagadas antes de tocar nada
VBoxManage modifyvm "Analisis-Win10" --nic1 intnet --intnet1 "labnet"
VBoxManage modifyvm "Servicios-REMnux" --nic1 intnet --intnet1 "labnet"

# Sin puentes hacia el host: portapapeles y arrastrar-y-soltar fuera
VBoxManage modifyvm "Analisis-Win10" --clipboard-mode disabled
VBoxManage modifyvm "Analisis-Win10" --draganddrop disabled

4. Direccionamiento estático

En la red interna no hay servidor DHCP, así que las direcciones se ponen a mano. Un esquema que funciona bien:

Fíjate en que la máquina de análisis apunta a la de servicios como puerta de enlace y como DNS. Ese es el truco: todo lo que el malware intente resolver o contactar acaba en INetSim.

5. Snapshots antes de nada

El snapshot no es una comodidad, es parte del método: sin él no puedes repetir un análisis en condiciones idénticas ni garantizar que lo que observas viene de esta muestra y no de la anterior.

# Estado limpio, con herramientas instaladas y red ya aislada
VBoxManage snapshot "Analisis-Win10" take "base-limpia" \
  --description "Win10 + FLARE-VM, intnet, sin muestras"

# Y para volver a él entre muestra y muestra
VBoxManage snapshot "Analisis-Win10" restore "base-limpia"

¿Cómo simulas Internet sin dar salida real?

Una muestra sin red hace muy poco. Si no resuelve su dominio de mando y control, muchas familias abortan la ejecución y te quedas sin ver la fase interesante. La solución es darle una Internet falsa que responda a todo.

INetSim levanta servidores DNS, HTTP, HTTPS, SMTP, FTP e IRC simulados. Su gracia está en el DNS comodín: cualquier dominio que la muestra pida resuelve a la IP de la máquina de servicios, y cualquier petición recibe una respuesta plausible.

# /etc/inetsim/inetsim.conf — las líneas que hay que tocar

# Escuchar en la interfaz del laboratorio, no en localhost
service_bind_address    10.13.37.2

# Todo dominio consultado resuelve aquí
dns_default_ip          10.13.37.2

# Responder en nombre de cualquier dominio, no solo de una lista
dns_default_hostname    www
dns_default_domainname  local

La alternativa es FakeNet-NG, que se ejecuta dentro de la propia máquina de análisis e intercepta el tráfico antes de que salga por la tarjeta de red. Es más cómodo para triaje rápido de una sola máquina; INetSim es mejor cuando quieres el tráfico limpio en una máquina aparte, que es la situación normal cuando estás documentando.

¿Cómo compruebas que el aislamiento funciona de verdad?

Esta es la sección que falta en casi todas las guías, y es la única que te separa de una infección propia. Se hace antes de acercarte a ninguna muestra real, con la máquina de análisis todavía limpia.

1. 1Desde la máquina de análisis, haz ping 10.13.37.2. Debe responder: si no, el switch virtual está mal configurado y no verás tráfico.
2. 2Haz ping 8.8.8.8. Debe fallar. Si responde, tienes salida real y el laboratorio no está aislado.
3. 3Prueba a resolver un dominio cualquiera con nslookup ejemplo-que-no-existe.test. Debe devolver 10.13.37.2, señal de que el DNS comodín funciona.
4. 4Abre un navegador contra cualquier URL. Debe aparecer la página de INetSim, no un error de red y desde luego no la web real.
5. 5Desde tu host, ejecuta VBoxManage list hostonlyifs. La red del laboratorio no debe aparecer: una red interna no crea adaptador en el host, y esa ausencia es precisamente la prueba.
6. 6Intenta alcanzar el router de tu casa desde la máquina de análisis (ping 192.168.1.1 o la que sea). Debe fallar.

¿Qué hace el malware para detectar que está en una máquina virtual?

Muchas familias comprueban si están siendo analizadas y, si lo detectan, se quedan quietas o se cierran. En la matriz de MITRE ATT&CK esto es la técnica T1497 (Virtualization/Sandbox Evasion). Lo que suelen mirar:

Ahora la parte honesta: para la mayoría del trabajo no necesitas endurecer nada. Si estás haciendo triaje de un correo sospechoso o de un binario común, la muestra se ejecutará sin más. El endurecimiento cuesta tiempo y aporta cuando persigues familias dirigidas que sí implementan estas comprobaciones. Empieza con el laboratorio funcionando y endurece cuando te topes con una muestra que no arranca.

Y ojo con el equilibrio: quitar las guest additions te resta comodidad (nada de portapapeles compartido, resolución fija) pero reduce a la vez la superficie de escape del hipervisor, así que en este caso concreto lo cómodo y lo seguro apuntan en direcciones opuestas. Yo las quito.

¿Cómo se manejan las muestras sin infectarte por accidente?

El laboratorio puede estar perfecto y aun así infectarte el equipo si manipulas mal el fichero antes de meterlo dentro. La disciplina de manejo importa tanto como la topología.

1. 1Descarga la muestra siempre dentro de un contenedor cifrado. La convención del sector, y la que usan repositorios como MalwareBazaar, es un ZIP con la contraseña infected.
2. 2No descomprimas nunca en el host. El fichero pasa a la máquina de análisis todavía comprimido, por disco virtual adjunto o carpeta compartida de solo lectura desmontada después, nunca por una carpeta compartida permanente.
3. 3Calcula el hash antes de tocar nada, para poder referenciar la muestra sin ambigüedad: sha256sum muestra.zip en Linux o Get-FileHash -Algorithm SHA256 muestra.zip en PowerShell.
4. 4Cambia la extensión mientras la mueves (.exe a .exe_, o directamente sin extensión). Evita el doble clic accidental, que es un clásico.
5. 5Desactiva el antivirus solo dentro de la máquina de análisis. Si Defender está activo te borrará la muestra a mitad de análisis y perderás el trabajo.
6. 6Cuando termines, restaura el snapshot limpio. No borres el fichero y sigas: restaura.

Los errores que se repiten una y otra vez

• Confundir solo-anfitrión con aislamiento. Es el fallo número uno y deja tu propio equipo al alcance de la muestra.
• Dejar una segunda tarjeta de red en NAT «para copiar cosas». Basta una para que el aislamiento no exista.
• Restaurar un snapshot antiguo tomado antes de aislar la red, que revierte también la configuración de red sin avisarte.
• Analizar sin capturar tráfico. Si no tenías Wireshark grabando, la mitad del comportamiento se ha perdido y toca repetir.
• Reutilizar la máquina entre muestras sin restaurar. Acabas atribuyendo a una muestra la persistencia que dejó la anterior.
• Carpetas compartidas permanentes. Son la vía más directa para que el ransomware de la VM cifre ficheros del host.

Con el laboratorio en pie, el siguiente paso natural es tener un método de análisis y no ir picoteando herramientas. Ese recorrido —triaje estático, decompilación, análisis dinámico y de red hasta llegar a una regla de detección— es exactamente lo que trabajamos en la ruta de Malware en Windows, y puedes verlo aplicado de principio a fin en nuestro análisis paso a paso de AgentTesla.