Analisis de Malware en Lab Aislado: Setup Seguro con FlareVM y REMnux

Sacaste un sample sospechoso de una campana de phishing real, lo descomprimiste en el escritorio y te diste cuenta demasiado tarde de que Defender ya mando el hash a MAPS. Felicidades: acabas de quemar un indicador, contaminar telemetria y quiza avisar al adversario. Antes de tocar cualquier binario con extension .exe, .iso o .lnk, necesitas un lab aislado, reproducible y desechable. La combinacion de FlareVM para analisis en Windows y REMnux para red y tooling defensivo en Linux es el estandar de facto desde 2020. Esta guia lo monta desde cero en VirtualBox con snapshots versionados y una red host-only que no rutea a nada real, y luego recorre el workflow completo de detonacion que convierte un blob opaco en capacidades nombradas e indicadores compartibles.

Por que el aislamiento no es negociable

El malware es codigo escrito para hacerle algo a un host, y en el momento en que corre en una maquina que alcanza tus archivos, tu red o internet, le entregaste exactamente lo que quiere. Los analistas se queman de tres formas: el sample llama a casa y avisa a su operador que detono; se propaga lateralmente por una red en bridge hacia activos reales; o un antivirus en la nube lo sube en silencio y destruye la confidencialidad de la investigacion. El lab existe para romper las tres. Todo ocurre dentro de maquinas virtuales sin shared folders, sin clipboard, sin drag and drop, sin USB passthrough, y con una red que termina en una caja de servicios falsos en vez de un gateway. Si un sample no puede notar que lo observan y no puede escapar, tu eres dueno del encuentro.

Hypervisor y disposicion de red

VirtualBox 7.1 o VMware Workstation 17 sirven ambos; evita KVM crudo salvo que ya domines libvirt y VLANs, porque configurar mal un bridge y exponer el sample a tu LAN de casa es un error real y comun. Crea dos maquinas virtuales: un Windows 10 22H2 (no 11, porque algunos implants revisan el build) con cuatro vCPU, 8 GB de RAM y un disco dinamico de 80 GB que sera FlareVM, y un Ubuntu que sera REMnux. Desactiva toda integracion con el host. Usa una red host-only sin DHCP y asigna 10.66.66.10 a Windows y 10.66.66.20 a REMnux a mano. No hay ruta default a internet; lo unico con lo que Windows puede hablar es la caja Linux fingiendo ser el mundo entero.

Montando la caja de analisis FlareVM

La instalacion de FlareVM exige un Windows recien instalado, sin dominio, sin updates pendientes, con Defender desactivado temporalmente por local policy para que el instalador no pelee con la proteccion en tiempo real. El install.ps1 de Mandiant del repo FLARE-VM baja decenas de paquetes Chocolatey: x64dbg, IDA Free, Ghidra, dnSpy, PE-bear, Detect It Easy, FLOSS, CAPA y pestudio. Presupuesta unas dos horas y 30 GB de descarga. Cuando termina, toma un snapshot llamado Clean-FlareVM-Base antes de correr cualquier sample. Ese snapshot es tu rollback sagrado: cada sample detonado vuelve a el, garantizando que el experimento dos arranque en el mismo estado que el uno. Registra cada version de herramienta en un archivo versionado, porque CAPA 7.x y 8.x producen outputs incompatibles y la reproducibilidad depende de saber exactamente que corrio.

REMnux e INetSim: fingir internet

REMnux sirve como tap pasivo y servidor de servicios falsos. En vez de instalar desde cero, agarra la appliance OVA oficial de Lenny Zeltser, importala, y en el primer boot corre remnux update y luego remnux upgrade. Configura INetSim en /etc/inetsim/inetsim.conf para bindear en 10.66.66.20 con HTTP, HTTPS, DNS, SMTP, IRC y FTP activos. Del lado de FlareVM, apunta el gateway default y el DNS a esa direccion. El resultado es que cualquier servidor de command-and-control que la malware intente alcanzar cae en INetSim, que responde con binarios falsos y loguea cada byte. Obtienes la misma visibilidad que da un proxy web, pero a nivel de paquete crudo, y el sample cree que alcanzo a su operador cuando solo hablo con tu trampa.

La captura de trafico es el segundo pilar

Corre Wireshark en REMnux en modo promiscuo sobre el adaptador host-only, y corre tcpdump en paralelo escribiendo PCAPs rotados de 100 MB para no perder nada si la GUI se cuelga. Pon Suricata como IDS con el ruleset ET Open, sumando Emerging Threats Pro si tienes licencia de investigacion, para que las familias conocidas se enciendan por firma. Para samples que hablan TLS, levanta mitmproxy con un root cert empujado al trust store de Windows. Si, eso rompe el certificate pinning, pero la mayoria de stealers commodity como Redline, Vidar y Lumma no lo implementan, asi que lees sus beacons en claro. Equipo mas pesado como beacons de Cobalt Strike o implants de Sliver puede requerir unhooking y manejo mas deliberado, que es una disciplina aparte de la triage.

Analisis estatico antes de correr nada

Copia el sample con shared folders desactivados; usa scp de REMnux a FlareVM sobre un servicio SSH temporal y luego mata el servicio. Calcula el SHA-256 con Get-FileHash y registralo junto a fuente, fecha e hipotesis inicial. Corre FLOSS para extraer strings ofuscadas y de stack, CAPA para mapear capacidades a tecnicas MITRE ATT&CK, y Detect It Easy para fingerprintear el packer y el compilador. PE-bear revela la tabla de secciones, imports y entropia: una seccion de texto con entropia por arriba de 7.0 grita packing. pestudio marca imports sospechosos como VirtualAllocEx y WriteProcessMemory que insinuan process injection. Nada de esto ejecuta el codigo, y una cantidad sorprendente del veredicto ya es visible antes de que corra la primera instruccion.

Analisis dinamico: el workflow de detonacion

Ahora arranca los monitores y detona. Lanza Procmon con un filtro en el arbol de procesos del sample y Process Hacker para ver handles, threads y memoria inyectada en tiempo real, luego corre el binario. Vigila los indicadores de filesystem y registro conforme aparecen: una copia a %APPDATA%, una clave Run para persistencia, una tarea programada, un mutex que evita doble ejecucion. Correlaciona eso con el trace de red en INetSim para ver el patron de callback. Si el sample esta packeado, el analisis estatico se estanca en el stub de unpacking; un binario packeado con UPX cede a upx -d, mientras un packer custom necesita x64dbg con ScyllaHide contra anti-debugging, un breakpoint en el original entry point y un dump de memoria en ese momento. Cuando termines, vuelve al snapshot limpio y verifica que la caja esta pristina antes de la siguiente corrida.

La seguridad operativa separa al pro de paciente cero

La higiene es lo que te evita volverte la victima. Nunca conectes la VM de analisis a tu LAN real, nunca inicies sesion en una cuenta personal dentro de ella, y trata cada hash como potencialmente ligado a un actor capaz de represalia. Las submissions a VirusTotal son publicas, asi que asume que un adversario sofisticado monitorea sus propios hashes y se entera en el momento que subes; usalo solo cuando el sample ya sea ampliamente conocido. Colecta de Malware Bazaar, triagea en Any.Run para detonacion publica cuando tus reglas de engagement lo permitan, y manten los samples cifrados en contenedores VeraCrypt offline para que un doble clic accidental nunca corra malware vivo contra tu propia workstation.

Errores y un checklist de reproducibilidad

Los errores clasicos son predecibles: dejar shared folders activos para que el sample escape al host; olvidar el snapshot para que la segunda corrida quede contaminada por la primera; confiar en el veredicto de una sola herramienta; y correr samples con acceso a internet porque INetSim parecio demasiado setup. Antes de declarar el lab listo, confirma que todas las integraciones con el host estan apagadas, que existe Clean-FlareVM-Base, que INetSim responde en cada protocolo configurado, que Wireshark y tcpdump ambos capturan, y que un sample conocido de Malware Bazaar con tag Emotet o AgentTesla se comporta identico en dos ciclos consecutivos de detonar y revertir. Si no puedes reproducir el mismo resultado dos veces, el lab no esta listo y cualquier investigacion real que corras sobre el ya es sospechosa.

De la triage a la forensia de memoria

La triage de comportamiento te dice que hace un sample; la forensia de memoria te dice que escondio. Muchos loaders modernos nunca escriben su payload real al disco, la descifran directo en una region recien alocada y la corren ahi, asi que un snapshot de RAM es el unico lugar donde existe el codigo desempacado. Capturalo en el pico de la infeccion con una herramienta como WinPMEM o DumpIt, luego analiza la imagen cruda con Volatility 3. Los plugins caballo de batalla son windows.pslist y windows.pstree para la jerarquia de procesos, windows.malfind para sacar a la luz memoria inyectada y ejecutable pero sin respaldo, windows.netscan para recuperar los sockets de C2 que INetSim ya logueo, y windows.dlllist para detectar cargas de modulo sospechosas. Como tomaste la captura dentro de una VM con snapshot, puedes re-correr la detonacion y agarrar una segunda imagen en otra etapa, luego diffear ambas para ver la persistencia y la inyeccion desplegarse. El analisis de memoria cierra el ciclo que la triage estatica y dinamica dejan abierto, y es donde las amenazas fileless por fin se vuelven visibles.

FAQ

Puede el malware detectar que corre en una VM y negarse a detonar? Si; muchas familias chequean artefactos de VirtualBox, pocos cores, discos chicos o uptime corto y se quedan dormidas. Contralo con un perfil de hardware realista, escondiendo strings del hypervisor, calentando la maquina antes de detonar y, para samples tercos, moviendote a un host de analisis bare-metal que reimages entre corridas.

Sigo necesitando un lab si puedo simplemente subir a un servicio sandbox? Los sandboxes publicos son geniales para triage pero son publicos, pueden perder triggers especificos del entorno y te quitan la decision de confidencialidad de las manos. Un lab local te da visibilidad total de paquetes, manejo privado y la capacidad de interactuar con el sample, cosa que los sandboxes automaticos no pueden.

Takeaway practico: gasta tu primer fin de semana montando el lab y machacando samples conocidos de Malware Bazaar, porque los tags Emotet y AgentTesla son excelentes rueditas de aprendizaje. Corre tres ciclos de detonar, revertir y verificar que INetSim capturo el trafico exactamente como se esperaba antes de tocar un sample real de cliente. La reproducibilidad le gana a la velocidad siempre, y un lab en el que puedes confiar dos veces vale mas que una respuesta rapida que no puedes defender.