Módulo 1: Técnicas contra máquinas virtuales y entornos de pruebas
El primer obstáculo que el malware suele intentar superar es la detección del entorno en el que se ejecuta. Al identificar si se está ejecutando en una máquina virtual o en un entorno de pruebas automatizado, puede decidir adoptar un comportamiento inofensivo o, simplemente, detenerse. Es una forma sencilla pero eficaz de evitar ser detectado por los investigadores y las herramientas de seguridad automatizadas.
La detección se lleva a cabo generalmente buscando determinados indicios: claves de registro, archivos, servicios o procesos específicos de un hipervisor. Por ejemplo, nombres como VBoxGuest, vmtoolsd.exe, vm3dservice o vboxservice son objetivos habituales. Herramientas comoProcmon permiten observar estas búsquedas en tiempo real.
Pero el malware no se limita a estas firmas. También analiza parámetros del sistema como el tamaño del disco duro, la cantidad de memoria RAM disponible o elnúmero de núcleos del procesador. Dado que estas características suelen ser limitadas en los entornos de prueba, constituyen indicios fiables para el malware.
Otra táctica consiste en enumerar los procesos que se están ejecutando. Si el malware detecta un proceso relacionado con un entorno de pruebas, una herramienta de depuración o un producto de seguridad, puede decidir no continuar. Esta es una técnica utilizada, entre otros, por la familia de malwareBumblebee, que interrumpe su ejecución si detecta procmon.exe, processhacker.exe o wireshark.exe.
Por último, algunos programas maliciosos comprueban si hay actividad de red o historial de usuario para asegurarse de que no se encuentran en un entorno estéril. Esto puede traducirse en la comprobación de la caché del navegador o de los archivos abiertos recientemente. Si no encuentran nada, concluyen que están siendo vigilados.
Para sortear estas técnicas, el analista dispone de varias opciones:
- Modificar u ocultar los elementos de los editores de máquinas virtuales (archivos, claves del Registro, servicios).
- Utilizar herramientas como VBoxCloak, que automatizan el ocultamiento de un entorno VirtualBox.
- Simular la actividad de un usuario, abriendo archivos, ejecutando aplicaciones legítimas o llenando la caché del navegador.
- Simular una conexión de red creíble utilizando herramientas como FakeNet-NG, que interceptan y responden al tráfico del malware de forma controlada.
Cuando se trata de técnicas de evasión más avanzadas, se puede utilizar x64dbg para modificar dinámicamente las instrucciones del malware, con el fin de eludir las comprobaciones o alterar sus resultados (por ejemplo, forzar que una instrucción «cmp» siempre dé resultado positivo). Del mismo modo, el análisis estático en IDA Pro permite identificar llamadas sospechosas a RegOpenKeyEx, FindFirstFileW, GetDiskFreeSpaceEx, etc.
Lo que hay que recordar
- El malware busca indicios de un entorno virtual: claves del Registro, rutas de archivos, procesos sospechosos.
- Ils peuvent mesurer des ressources matérielles minimales pour éviter les environnements de test (ex. < 4 Go RAM, < 80 Go disque).
- La comprobación de los procesos o de la ausencia de actividad del usuario permite detectar los entornos de pruebas automatizados.
- Cuando no hay conexión a la red, el malware suele dejar de ejecutarse: FakeNet permite simular un entorno realista.
- Herramientas como VBoxCloak y VMwareCloak ocultan los rastros de la virtualización.
- El ingeniero de ingeniería inversa puede modificar las rutas y los valores, o saltarse instrucciones críticas mediante IDA o x64dbg.
Módulo 2 – Técnicas anti-depuración
Una vez que ha eludido el entorno de virtualización, el malware intentará averiguar si estásiendo depurado activamente. Esta fase es especialmente crítica para el analista, ya que el malware intentará autodestruirse, ocultar su comportamiento o engañar al analista.
Las llamadas a la API de Windows como IsDebuggerPresent o CheckRemoteDebuggerPresent se utilizan a menudo para detectar un depurador. Estas funciones leen valores de la estructuraPEB (Process Environment Block), en particular el campo BeingDebugged. También es habitual comprobar el indicador NtGlobalFlag en el PEB.
Pero las técnicas no se limitan a eso. Algunas utilizan llamadas como OutputDebugString, NtQueryInformationProcess o llamadas al sistema de bajo nivel. Otras emplean métodos temporales como:
- GetTickCount, que devuelve el tiempo transcurrido desde el inicio del sistema (útil para detectar un inicio reciente).
- GetLocalTime, que permite implementar «bombas de tiempo» (por ejemplo: solo se ejecuta a partir del 1 de junio de 2025).
- RDTSC (Read Time-Stamp Counter), que mide el tiempo transcurrido entre dos instrucciones, revelando las interrupciones provocadas por el depurador.
El malware también puede intentar retrasar la ejecución de forma intencionada, mediante Sleep, NtDelayExecution o bucles de «stalling». Este retraso puede superar la ventana de ejecución
de un entorno aislado, lo que hace que el comportamiento malicioso pase desapercibido. Por último, algunas técnicas tienen como objetivo detectar puntos de interrupción de software (0xCC) o ganchos de software (0xE9) en funciones críticas. Para ello, el malware puede escanear la memoria mediante VirtualQuery o ReadProcessMemory.
Ante estos mecanismos, existen varias soluciones:
- Modificar dinámicamente las instrucciones mediante x64dbg (por ejemplo: sustituir «je» por «jmp»).
- Cambia la fecha del sistema o deja que el sistema funcione unos minutos antes del análisis.
- Utiliza ScyllaHide, un complemento de x64dbg capaz de ocultar automáticamente el depurador.
- Es preferible utilizar puntos de interrupción físicos, que son más discretos, cuando un programa malicioso detecta los puntos de interrupción lógicos.
Lo que hay que recordar
- El malware utiliza IsDebuggerPresent, NtQueryInformationProcess, GetTickCount y RDTSC para detectar depuradores.
- Las «bombas de tiempo» o comprobaciones del tiempo de activación permiten que el programa se ejecute únicamente en contextos reales.
- RDTSC mide los ciclos de CPU: cualquier latencia anómala puede indicar la presencia de un depurador.
- Los tiempos de espera (Sleep) se utilizan para eludir los entornos de pruebas automatizados, que suelen funcionar durante un breve periodo de tiempo: su valor se puede modificar.
- Los puntos de interrupción de software (0xCC) y los hooks (0xE9) pueden detectarse mediante la inspección de memoria.
- El uso de ScyllaHide o de parches dinámicos es fundamental para sortear estos obstáculos.
- Es posible forzar un salto (jmp) o simular un valor del sistema modificando los registros.
Módulo 3 – Llamadas indirectas al sistema y MutationGate
Este módulo aborda técnicas más avanzadas y recientes destinadas a eludir los sistemas de detección de comportamiento, como los EDR (Endpoint Detection & Response). En lugar de llamar directamente a las funciones API clásicas de Windows, el malware genera sus propias llamadas al sistema de forma indirecta para pasar desapercibido.
Llamadas al sistema indirectas
El enfoque de las llamadas al sistema indirectas, popularizado por SysWhispers3, permite eludir los ganchos que los EDR colocan en torno a funciones sensibles (como NtOpenProcess o NtAllocateVirtualMemory). Al construir manualmente la llamada al sistema —inicializando los registros, colocando el identificador de la función (SSN) en EAX y ejecutando la instrucción syscall—, el malware evita los puntos de vigilancia clásicos.
SysWhispers ofrece varios métodos:
- Jumper: salta directamente a la instrucción syscall en ntdll.dll.
- Incorporado: integra la llamada a la función syscall directamente en el binario.
- Egg-hunter: código «dañado» a propósito, pero reparado en memoria por un cargador.
- Jumper-randomized: añade aleatoriedad a la elección de la función que se va a llamar.
Estas técnicas complican el análisis, ya que no se ve ninguna API en la tabla de importación y no aparecen los nombres de las funciones.
MutationGate: una técnica de evasión aún más discreta
La técnica conocida como MutationGate, documentada recientemente en la comunidad, introduce un método aún más sigiloso. Utiliza controladores de excepciones vectoriales (VEH) para desviar dinámicamente las llamadas al sistema. La idea es sencilla pero brillante: el malware llama a una función inocua (como NtDrawText) en la que se ha colocado un punto de interrupción de hardware. Cuando llega a ese punto, se genera una excepción. El controlador asociado intercepta la excepción y modifica sobre la marcha el registro RAX, inyectando en él el SSN de la verdadera función
deseada (por ejemplo, NtOpenProcess), justo antes de la ejecución de la llamada al sistema.
Este mecanismo permite ocultar por completo la verdadera intención del código:
- No hay ningún registro en la tabla de importaciones.
- No hay ninguna referencia directa a funciones peligrosas.
- Ocultación del comportamiento hasta el último momento, dentro del controlador.
Durante el análisis, solo una inspección detallada del controlador VEH permite identificar su verdadero comportamiento. El malware suele utilizar varios puntos de interrupción de hardware (hasta cuatro) para gestionar diferentes redireccionamientos de llamadas.
Lo que hay que recordar
- Las llamadas al sistema indirectas permiten eludir los hooks de EDR llamando directamente a las llamadas al sistema a través de stubs personalizados.
- MutationGate va más allá al insertar el SSN en el registro RAX en el momento de producirse una excepción, lo que hace que la llamada al sistema sea indetectable.
- Es posible analizar estos comportamientos mediante x64dbg e IDA, colocando puntos de interrupción en las instrucciones críticas (syscall, RAX, controladores VEH).
Conclusión
A lo largo de estos tres módulos, se observa que las técnicas de evasión del malware ya no son únicamente defensivas, sino que se han vuelto proactivas. Su objetivo es confundir al analista, engañar a las herramientas automatizadas y manipular las capas inferiores del sistema para permanecer ocultas. Para contrarrestar estas técnicas, el analista debe contar con una metodología rigurosa, herramientas adecuadas y, sobre todo, un conocimiento profundo de los mecanismos internos de Windows.
Este informe ilustra la evolución tecnológica y estratégica del malware. Desde simples pruebas de virtualización hasta llamadas al sistema ofuscadas mediante gestores de excepciones, las técnicas de evasión se están volviendo cada vez más complejas, lo que exige al analista una vigilancia constante y una actualización continua de sus métodos.
No obstante, para cada nivel de evasión existen soluciones: ocultación del entorno, modificación dinámica del código, emulación de red... Esta experiencia es ahora fundamental en ámbitos como la gestión de incidentes, la búsqueda de amenazas o el análisis post mortem.
