Métodos de evasión de una sandbox

En este artículo se va a hablar sobre el sandboxing y algunos de los diferentes métodos anti-sandbox que existen y que muchos malware usan para evitar ser analizados en entornos virtuales.

Existen varios modelos estándar que se dedican a ejecutar malware en una sandbox para intentar dilucidar el comportamiento que tiene en un sistema como, por ejemplo, Cuckoo Sandbox. Sin embargo, la realidad es que a día de hoy cualquier malware medio serio supera muchos de estos mecanismos de análisis dinámico y, por tanto, consigue evadir su ejecución en un entorno virtual.

Hay multitud de métodos para conocer si se está en un entorno virtual o no, los cuales van desde comprobaciones simples a pruebas más complejas. A continuación, vamos a hablar de las más

generalizadas y curiosas, a pesar de que la mayoría son antiguas, aunque debido a fallos de

configuración o gestión se siguen utilizando hoy día.

Métodos simples de evasión de sandbox

Los métodos de evasión alcanzan desde parámetros hasta metodologías de comprobación o rutinas programadas complejas. Los primeros, por norma

general, son debidos a una serie de malas configuraciones o descuidos, siendo fácilmente detectables y, por tanto, eludibles.

• Número de cores del sistema.
• Tamaño y nombre del disco.
• Nombres de carpetas compartidas.
• Nombre de los adaptadores virtuales o de pantalla.
• Tamaño de la memoria RAM.
• Nombre del usuario o del dispositivo Hardware.
• Número de serie de la BIOS.
• Nombres de procesos o servicios determinados.
• Nombres y valores de claves de registro determinadas.
• MAC determinadas.
• Directorios específicos.

Cuando se está en entornos virtualizados como VMWare, Virtualbox, Qemu, KVM, etc, suelen ser

comunes este tipos de configuraciones, las cuales son evitables.

En este caso se va a usar un Windows 10 sobre la plataforma de virtualización VMWare para hacer

la demostración. Con únicamente detectar alguna de las siguientes configuraciones, un malware podría parar su ejecución, o bien, no ejecutar su payload, realizando acciones benignas en su lugar.

Todas las comprobaciones las vamos a hacer con el gestor de windows mediante líneas de comandos (Windows Management Instrumentation Command-Line, WMIC), la cual tiene librerías para diferentes lenguajes de programación, pudiendo usarse de forma sencilla por cualquier persona que desarrolle malware.

El número de cores es un dato del sistema que delata inequívocamente a una máquina virtual,

debiendo ser al menos dos.

Otro ejemplo es el modelo del sistema, el cual en este caso es claro. Otros valores típicos que

pueden delatar un entorno sandbox son «VBox», «QEMU» o «Virtual HD» en función del motor de

virtualización usado.

El número de serie de la BIOS es otro factor común de evasión, debido a que al principio es típico que muestre el nombre de la plataforma de virtualización.

Los adaptadores, tanto virtuales como de pantalla, también suelen tener como nombre, o al menos como parte de ellos, el nombre del motor de virtualización. Es típico nombres de dispositivos virtuales como los siguientes:

• \.\VBoxMiniRdrDN
• \.\VBoxGuest
• \.\pipe\VBoxMiniRdDN
• \.\VBoxTrayIPC
• \.\pipe\VBoxTrayIPC
• \.\HGFS
• \.\vmci

Todos los nombres anteriormente listados, más cualquier otro por el estilo que pudiese delatar un

entorno sandbox, podría provocar que un malware evada el entorno, evitando así un análisis dinámico válido.

Del mismo modo que los anteriores parámetros delatan a un entorno virtual, el tamaño del disco es uno de los primeros que suele comprobarse para detectar una sandbox. Por este motivo, el tamaño mínimo del disco debe ser superior a 60 GB para no ser considerada como máquina virtual.

La dirección MAC del equipo es otro de los elementos más comunes de detección, ya que mediante comprobación online se puede verificar cualquier rango de direcciones de las compañías de virtualización. La página del IEEE permite buscar empresas y el rango de MAC asignadas a las mismas, siendo típicas en VMWare las siguientes:

• 00-1C-14-00-00 – 00-1C-14-FF-FF
• 00-0C-29-00-00 – 00-0C-29-FF-FF
• 00-50-56-00-00 – 00-50-56-FF-FF
• 00-05-69-00-00 – 00-05-69-FF-FF

Los procesos o los servicios son otra fuente de la que bebe un malware para conocer el tipo de

entorno en el que está siendo ejecutado. Si alguno coincide con lo típicos, automáticamente puede pararse la ejecución del payload o al menos se evita aquella parte que pueda ser maligna.

Son típicos en VMWare los siguientes procesos:

• vmtoolsd.exe
• vmwaretray.exe
• vmwareuser.exe

Recorriendo las claves de registro del sistema se pueden encontrar muchas comunes a tecnologías de virtualización, siendo típicas algunas dentro de SOFTWARE o HARDWARE.

Estos son sólo algunos de los métodos más típicos y primitivos de comprobar si la ejecución de un fichero se está produciendo en una máquina virtual o en una física normal. Lo recomendable para evitar que una sandbox sea descubierta por un malware, es echarle un ratito y cambiar cualquiera de los parámetros descritos anteriormente o cualquier otro que se nos ocurra que pueda ser indicativo de una sandbox. También es necesario advertir que pese a todos nuestros esfuerzos, los cibercriminales desarrollarán nuevos métodos o formas de evadir una sandbox, sólo necesitan estudiar, es decir, tiempo e imaginación.

Como recomendación, mencionar la existencia de herramientas como Pafish que nos pueden ayudar a conocer el valor de los parámetros típicos y, así, poder actuar en consecuencia.

Métodos complejos de evasión sandbox

Timing de la CPU

Conocido como RDTSC, que no es más que conocer la velocidad con la que un procesador es capaz de procesar órdenes. Lo normal es comprobar el timing mediante el envío de órdenes a la CPU para verificar su velocidad.

Time acceleration

Hace ya bastante que el sistema es capaz de cambiar el valor devuelto por el RDTSC. Por tanto, si al enviar las órdenes a la CPU y medir el tiempo de procesado un malware se da cuenta que está siendo ejecutado en una sandbox puede, o bien comportarse de forma benigna y en vez de conectarse a la botnet enviar peticiones a sitios «limpios» de Internet, o bien ni ser bueno ni malo, es decir, puede, por ejemplo, cargarse su propio payload y no hacer nada que pueda delatarlo.

Sleep

Hay muchos malware que duermen durante un tiempo para evitar que los motores antivirus detecten su actividad al analizarlos. Realmente, este método se volvió contra los malware, ya que se convirtió en un claro indicativo de que un programa «podría ser» un fichero sospechoso de contener actividad maliciosa, pudiendo así vigilar de cerca el proceso y su respectivo fichero en ejecución.

Delay

Es un sleep con matices, ya que en vez de un sleep, el malware lanza actividad sin

importancia para dejar constancia que tiene actividad y no es maliciosa, con la clara intención de ganar tiempo hasta que los motores anti-malware confíen en él. También es típico que durante el delay se intente ver si realmente existe movimiento en el equipo y no es una máquina virtual sin más, sino que realmente haya un usuario.

De nuevo, esta última técnica está superada ya que existen programas de actividad automática de usuario que cualquier sandbox medianamente seria usa.

Timing attack

Son malware que se ejecutan y, por tanto, despiertan sólo ciertos días o a ciertas horas para hacer su actividad maliciosa.

Lo que se hace para contrarrestar este tipo de malware es cambiar la hora del sistema y así poder analizarlos sin problemas. Esto garantiza que se despiertan a la hora deseada, es decir, despiertan del sleep creyendo que es la hora correcta y realizan la actividad, conociendo así sus verdaderas intenciones.

Anti-Hook attack

Los hooks son mecanismos de manejo de llamadas del sistema donde una aplicación puede instalar una subrutina para monitorizar las órdenes que van al sistema y procesarlas antes de que lleguen al procedimiento de destino.

Los malware, sabiendo de este hecho, buscan los puntos que actúan como hooks y se las cargan, para poder así actuar a sus anchas en el sistema sin que nadie sepa que está obteniendo información o realizando acciones mediante órdenes al sistema.

Anti-AV attack

Muchos malware saben que existen una serie de firmas de antivirus que pueden complicarle la vida, por tanto, lo primero que hacen al introducirse en el sistema es buscar y cargarse los clientes antivirus, evitando de esta forma males mayores.

Software Detection

Existen softwares muy comunes como Wireshark, Dumpcap, ProcessHacker, SysAnalyzer, HookExplorer, SysInspector, PETools, Process Explorer, Process Monitor, Regmon, Filemon, TCPView, Autorums, WinDBG, IDA Pro, etc, que suelen usarse para detectar, en más o menos

medida, actividad en el sistema y, por ende, malware. Es decir, son un problema, por tanto, o el malware los elimina o bien el malware no se ejecuta de como debería.

Ficheros no típicos

Los malwares cada vez tienden más a estar en ficheros poco típicos como pueden ser RTF, tipo de fichero usado por Wannacry. Se suelen evitar ejecutables de Windows (MSEXE) o de MAC, PDF, DOCX, EXCEL, BAT, Shell Script, JavaScript, etc. Es decir, formatos típicos para los que ya

existen herramientas donde un análisis pueda detectarlos. Lo que buscan es ganar tiempo, es decir, evitar que los analistas tengan medios para su reversing de forma inmediata y que mientras la protección frente a ellos se diseña, las consecuencias desatadas surtan efecto.

Ejecución con argumentos

Existen muchos malware que, para evitar ejecutarse en entornos virtuales, requieren de la introducción de un argumento adicional. Ejemplo «cmd.exe malware.exe 123456».

Este comportamiento no es muy habitual pero si es una muy buena idea, ya que finalmente requiere de otro fichero (el dropper que lo descarga normalmente) para ejecutarse. Ese código del argumento ya lo usa como mejor le viene, pudiendo ir desde coger ese parámetro

entero como entrada o coger los últimos 2 bytes, o darle la vuelta al parámetro y coger 2 bytes … ya lo que se le ocurra al que lo ha desarrollado.

En resumen, si se quiere analizar de forma óptima un malware, es necesario tener todo lo anterior en cuenta más otras muchas más características que se descubren día a día y que los malware usan. Por este motivo, los motores estándar de análisis dinámicos han dejado de ser herramientas óptimas de análisis malware. A día de hoy lo que más o menos funciona es un cargador que coja un malware, lo cargue en memoria y analice su comportamiento. Además es necesario que posea un proceso heurístico que una vez analizadas x líneas del código sea capaz de saber que va a estar limpio o es realmente malware. El problema como siempre son los falsos negativos y positivos, que hacen que estas soluciones tampoco sean óptimas

Para mejorar todas estas soluciones, el mercado está volcado con la Inteligencia Artificial para que en un corto plazo la detección de malware se realice mediante técnicas de aprendizaje automático. Es decir, extraer una serie de características de un fichero que irán a un motor de inteligencia artificial donde se predecirá si es malware o no.

Como se ha podido apreciar, el mundo del malware es muy dinámico y actualizado donde día a día tanto los cibercriminales como los analistas van innovando para cazarse los unos a los otros continuamente.