¿Cómo detecta y evade el malware los sandboxes de análisis, y cómo lo contrarrestas?
Respuesta breve
El malware consciente del sandbox comprueba si lo están observando antes de portarse mal. Busca artefactos de VM e hipervisor (drivers, prefijos MAC, claves de registro, CPUID), herramientas de análisis y depuradores (nombres de proceso, IsDebuggerPresent, temporización del single-stepping), y señales de un usuario real (pocos procesos, sin documentos recientes, sin movimiento de ratón, poco uptime, disco pequeño). Puede demorarse con sleeps largos o solo activarse en una fecha, idioma o dominio concretos. Los analistas lo contrarrestan endureciendo la VM para que parezca real, parcheando las comprobaciones, adelantando los sleeps, simulando actividad del usuario y confirmando el comportamiento con desensamblado estático.
El análisis dinámico solo es útil si el malware ejecuta de verdad su código malicioso mientras observas. Los entrevistadores preguntan esto porque las muestras modernas dan por hecho que serán detonadas en un sandbox y ocultan su comportamiento cuando detectan uno. Entender este juego del gato y el ratón es central para el trabajo.
Qué comprueba el malware
- Artefactos del entorno. Huellas de VM e hipervisor: drivers y claves de registro de VMware/VirtualBox, prefijos de dirección MAC conocidos, el bit de hipervisor de
CPUID, cadenas de la BIOS, y disco pequeño o poca RAM. Presencia de herramientas de análisis (Procmon, Wireshark, x64dbg) por nombre de proceso o de ventana. - Detección de depurador.
IsDebuggerPresent,CheckRemoteDebuggerPresent, flags del PEB, comprobaciones de temporización que notan la ralentización del single-stepping, y trucos basados en excepciones. - Señales de usuario real. Los sandboxes parecen estériles: pocos procesos en ejecución, sin documentos recientes, nombres de usuario por defecto, sin movimiento de ratón, poco uptime y un historial de navegador limpio. El malware que ve una máquina prístina asume que está siendo analizado.
- Bombas lógicas y stalling. Llamadas largas a
Sleepo bucles de ocupación para sobrevivir a la ventana de análisis del sandbox; disparadores condicionados a una fecha, idioma del sistema, distribución de teclado o dominio concretos para que solo se active en el objetivo previsto.
Cómo lo contrarrestan los analistas
Haces que la VM parezca habitada: instalas software común, pueblas documentos e historial, simulas actividad de ratón y teclado, fijas un uptime realista y eliminas los artefactos obvios de herramientas. En un depurador parcheas las comprobaciones anti-debug o enganchas la API para que mienta, y adelantas los sleeps enganchando Sleep/NtDelayExecution. De forma crucial, recurres al desensamblado estático para leer la lógica de evasión y las condiciones objetivo que nunca se disparan dinámicamente.
Una respuesta sólida lo enmarca como una carrera armamentística y subraya que el análisis estático y el dinámico cubren mutuamente sus puntos ciegos.
Posibles preguntas de seguimiento
- ¿Cómo harías que una VM de análisis pareciera la estación de trabajo de un usuario real?
- ¿Qué es el stalling basado en sleep y cómo lo vences?
- ¿Cómo puede el análisis estático revelar la lógica de evasión que nunca se dispara dinámicamente?