Hacer que una VM crea que tiene un ventilador de CPU para engañar al malware

• Los malwares verifican la presencia de hardware como un ventilador de CPU para evitar ejecutarse en entornos virtuales
• La información del ventilador de CPU puede consultarse mediante la clase Win32_Fan de WMI, y esos datos se almacenan en SMBIOS
• En Xen, para insertar datos SMBIOS personalizados se requieren un parche y configuración adicional, y es necesario configurar tanto las tablas Cooling Device (Type 27) como Temperature Probe (Type 28)
• En QEMU/KVM, se puede aplicar SMBIOS personalizado fácilmente con la opción -smbios sin parches adicionales
• Con esto, se puede hacer creer a la máquina virtual que existe un ventilador de CPU, intentando evadir la detección del malware

---

¿Por qué hacer esto?

• Algunos malwares verifican la presencia de cierto hardware (por ejemplo, un ventilador de CPU) para comprobar si se están ejecutando en un entorno virtual
• Inspeccionan el hardware con clases WMI como Win32_Fan, y si esa información no existe, concluyen que se trata de una máquina virtual y evitan ejecutarse
• La intención es impedir que los analistas puedan estudiar el malware
• Existen varias clases WMI como Win32_CacheMemory y Win32_VoltageProbe, pero este artículo se enfoca en el ventilador de CPU

¿Cómo sabe una computadora si tiene un ventilador de CPU?

• La computadora lee la información de SMBIOS para reconocer la presencia de un dispositivo de enfriamiento (ventilador de CPU)
• La instancia de Win32_Fan la proporciona cimwin32.dll, y esa DLL lee la información del ventilador desde la entrada type 27 de SMBIOS
• También sería posible usar técnicas como hooking de DLL, pero manipular SMBIOS directamente es un mejor enfoque

SMBIOS Type 27

• SMBIOS type 27 significa "Cooling Device"
• Es posible comprobar directamente los datos de Cooling Device de SMBIOS con la utilidad dmidecode
• Ejemplo:
  • Type: Chip Fan
  • Status: OK
  • Description: CPU Fan
  • Nominal Speed: 5600 rpm, etc.

Cómo configurar datos SMBIOS personalizados en Xen

• En Xen, se puede especificar directamente información SMBIOS en formato binario mediante la opción smbios_firmware del archivo de configuración del domain
• Se crea un archivo smbios.bin e insertan en él los datos de Cooling Device (type 27)
• El tamaño de la estructura SMBIOS (por ejemplo, 24 bytes) debe anteponerse como entero little-endian de 32 bits

Problema: limitación al sobrescribir estructuras

• Xen restringe la sobrescritura solo a las estructuras 0, 1, 2, 3, 11, 22 y 39
• type 27 no está permitido de forma predeterminada, por lo que hace falta parchear el código fuente
• En el foro de desarrolladores de Xen también se propuso un parche relacionado, pero no fue aceptado oficialmente (hay que aplicar el parche y compilar)

También se necesita Type 28

• Cooling Device (type 27) está vinculado con Temperature Probe (type 28)
• Si no existe una entrada type 28 en SMBIOS, la clase Win32_Fan no se muestra correctamente
• Para que el reconocimiento sea preciso, hay que obtener los datos type 28 del sistema host y añadirlos a smbios.bin

Estructura final de smbios.bin

• Incluye tanto los datos Type 27 como Type 28
• Antes de cada estructura se inserta la información de tamaño (little-endian)
• Ejemplo: formato como 18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ...

Aplicación y verificación en Xen

• Después de arrancar la máquina virtual de Windows con el comando de creación del domain, se comprueba en WMI si la clase Win32_Fan se reconoce correctamente
• Si aparece Description: Cooling Device y Status: OK, el ventilador de CPU fue reconocido con éxito

Configuración de datos SMBIOS en QEMU/KVM

• En QEMU/KVM, es fácil configurar SMBIOS personalizado con la opción -smbios file=ruta
• Se usan solo datos raw, sin información del tamaño de la estructura
• También se pueden reutilizar tal cual los datos SMBIOS del host

Material de referencia

• Documentación del archivo de configuración de domains de Xen, notas de configuración de mcnewton, archivo del parche rechazado de Xen, System Management BIOS Reference, parche QEMU Anti Detection, etc.

[GN⁺]

Comentarios de Hacker News

• Como nuevo método antimalware, también se menciona comprar una PC con refrigeración pasiva, y que configurar un teclado ruso es un tip para bloquear malware fraudulento; se puede consultar el enlace relacionado

  • De hecho yo uso una PC Linux Streacom FC8 Evo con refrigeración pasiva y teclado ruso, pero al revisar con el comando dmidecode la información del dispositivo de enfriamiento sigue existiendo y el sistema realmente detecta el hardware de refrigeración; también se puede confirmar la temperatura con datos de sensores

  • Incluso usando una PC con refrigeración pasiva, la placa madre normalmente sigue teniendo headers para ventiladores, así que aunque no haya nada conectado probablemente no haga mucha diferencia

• Se menciona que no deberíamos usar expresiones como “smol pp”, señalando que ese lenguaje incorpora burlas sobre el cuerpo

  • En mi ciudad hay alguien con una placa personalizada que dice “SML PP”; no sé por qué

  • También hay quien opina que, aunque se use la expresión “nuestro lenguaje”, es ambiguo que alguien en la sección de comentarios de un blog hable en nombre de “nosotros”

• Hay una opinión de que hacer que el sistema operativo parezca una máquina virtual podría mejorar la seguridad y ayudar a los investigadores; si alguien quiere un entorno no virtualizado, tendría que obtener permiso obligatoriamente, y así el malware quizá ni siquiera apunte a usuarios comunes para evitar a los analistas, con lo que al final todos ganan excepto los creadores de malware

  • Más que hacer que un sistema operativo normal parezca una VM, sería mejor que la máquina virtual ni siquiera supiera que está virtualizada; según un comentario, los sistemas lpars de IBM funcionan de esa manera

  • También se menciona que con este enfoque las empresas de software anticheat saldrían perdiendo; yo quiero saber claramente dónde corre mi software, pero también hay muchos jugadores multijugador que odian más a los tramposos que al propio anticheat, así que en la práctica no sería fácil cambiar eso

  • En el mundo del desarrollo móvil, según otro comentario, este marco ya es una realidad

• Nunca he visto en una motherboard de consumo que la descripción SMBIOS coincida de verdad con el hardware real; un malware que revise esto podría fallar en 50% del hardware físico, pero si al menos bloquea con certeza el 100% de las VM o de los depuradores, desde la perspectiva del malware sigue valiendo la pena aunque falle; aun así, parece más confiable verificarlo midiendo tiempos que con este enfoque

  • Este problema de que la descripción SMBIOS no coincida con el hardware real es especialmente común en cajas chinas baratas; valores sin completar como “to be filled in by OEM” aparecen muy seguido al codificar imágenes BIOS reales, así que ya solo con eso la situación resulta bastante absurda

  • El malware también tiene muchos bugs; igual que en casos pasados donde errores en el código de red hicieron que un virus se propagara a la mitad de la velocidad prevista, no hace falta que infecte todos los dispositivos para causar daños enormes

  • Últimamente me da curiosidad cómo detecta Linux los ventiladores; no sé si usa ACPI o EFI, y en mis equipos la mayoría de los ventiladores/sensores se detectan correctamente

  • También preguntan si esta verificación de SMBIOS la hace malware real o si solo aparece en muestras creadas por investigadores

• Puede parecer simpático que el malware use trucos con APIs para dificultar el análisis, pero la mayoría de estas llamadas se detectan fácilmente en análisis estático y, si el binario no está ofuscado, hasta pueden jugarle en contra; quien comparte la experiencia comenta que los programas con un objetivo real suelen distribuirse con firmas de una CA confiable, así que desde el análisis de seguridad ese comportamiento sospechoso se detecta bien; cuando era junior incluso atrapaba este tipo de uso de APIs con patrones de regex, y era bastante efectivo para detener malware básico distribuido masivamente

  • Últimamente el malware también firma archivos con bastante frecuencia; ya no se puede asumir que las bandas de malware no van a firmar sus binarios, y se menciona que los certificados de firma de código robados son comunes, además de que Microsoft es reacio a revocarlos por miedo a romper software de clientes existentes; también es frecuente que el malware aproveche drivers vulnerables para meterse al kernel, así que en la práctica un pequeño binario sospechoso que hace llamadas WMI genera más alertas que una utilidad de overclocking llena de vulnerabilidades haciendo exactamente las mismas consultas; en realidad, este método busca menos evadir la detección que evitar que el payload del malware se active en la PC del analista; si se detecta análisis, no baja el segundo payload y se pospone la actividad de C&C que podría lanzar el ataque real

  • Desde el punto de vista de seguridad, se propone que quizá sería mejor ejecutar todo el software dentro de una VM

  • También se argumenta que es dudoso que un antivirus pueda decidir si algo es malware solo con análisis estático; en ese caso, el resultado sería casi el mismo que usar una lista blanca y permitir solo software confiable, tratando todo lo demás como malware

  • Se critica la realidad en la que empresas como CrowdStrike reciben firma oficial para software mediocre que corre a nivel kernel y toca todas las system calls sin que a nadie le importe; da igual si hay VM o no: igual se despliega en producción código y releases no verificados, y cuando el mundo realmente se rompe, se retrasan vuelos o fallan infraestructuras críticas, nadie asume bien la responsabilidad; de hecho, se critica que empresas legítimas pueden causar más daño que hackers o actores estatales, y se opina que el incidente de la utilidad xz fue un gran desastre de seguridad comparable a SolarWinds y ClownStrike

• He visto a un amigo del sector infosec pasar la mayor parte de su tiempo haciendo que honeypots de malware se parezcan por completo a hardware real; impresiona ver lo meticuloso que es al configurar desde termostatos basados en Windows XP hasta controladores PLC de Siemens y escritorios bancarios

  • Ojalá no exista en el mundo ningún termostato que funcione con Windows XP

• Esto me recordó que al configurar un Hackintosh era indispensable elegir un SMBIOS adecuado; durante las últimas décadas se han introducido muchas APIs de PC relativamente menores, y a menudo se usan para probar qué tan bien las reflejan el software de virtualización o el malware; si se quiere ir un paso más allá, también haría falta simular sensores de temperatura que cambien dinámicamente según la carga real del CPU

• Según Mitre ATT&CK T1497.001 (VM Detection), revisar SMBIOS es un vector conocido; yo también lo probé y pude configurar la fuente de poder como HotReplaceable=Yes, Status=OK para que se mostrara como si fuera un servidor bare metal de $5,000; el comando usado fue pip install dmigen después dmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1

  • Como referencia, en Hacker News hace falta dejar dos o más saltos de línea o indentar cada línea con dos espacios para que se vea como código y se respete el salto de línea real