El análisis dinámico es un enfoque ampliamente adoptado para la detección de software malicioso. Sin embargo, muchos ejemplares intentan evadir la detección identificando la presencia del entorno de análisis, y absteniéndose de llevar a cabo acciones maliciosas. Debido a la sofisticación de las técnicas utilizadas por los atacantes, hasta ahora el análisis y detección de malware evasivo han sido en gran parte un proceso manual.
Los sistemas de sandboxing, o sistemas automatizados de análisis de malware, ejecutan una muestra desconocida en entornos de análisis preparados y supervisan su ejecución. Aunque han sido utilizados como parte del proceso de análisis manual, se utilizan cada vez más como el núcleo de los procesos de detección automatizados. La ventaja es clara: permiten identificar malware previamente desconocido (zero-day) por comportamiento.
Características de un buen entorno de pruebas
En nuestro afán por crear el correcto entorno de ejecución, debemos mantener en mente tres objetivos a lograr: visibilidad, resistencia a la detección y escalabilidad. En primer lugar, nuestro entorno de pruebas debe ser capaz de observar y analizar tanto como sea posible de la ejecución de un programa. De lo contrario, podría pasar por alto actividad relevante, volviéndose imposible realizar deducciones sólidas acerca de la presencia o ausencia de comportamientos maliciosos.
En segundo lugar, debe realizar el monitoreo de modo que éste sea difícil de detectar por la propia muestra analizada, para evitar que altere su comportamiento.
El tercer objetivo refiere a la posibilidad de ejecutar de forma automatizada muchas muestras en un mismo entorno, de manera que la ejecución de una muestra no interfiera con pruebas posteriores.
¿Qué datos debemos analizar?
La gran mayoría del malware se ejecuta como procesos regulares de usuario, e incluso los rootkits suelen aprovechar estos componentes para instalar los controladores del kernel o para modificar el código del sistema operativo.
Al monitorear el comportamiento de un proceso en modo usuario, los entornos de prueba se centran en la interfaz de llamadas al sistema, funciones que el sistema operativo expone a los procesos de usuario para que éstos puedan interactuar con su contexto y lograr su cometido –como ser leer archivos, enviar paquetes de datos a través de la red, o leer registros del sistema.
El monitoreo de llamadas al sistema tiene absoluto sentido, pero es sólo una pieza del rompecabezas: un entorno de sandboxing que analice únicamente la invocación a éstas llamadas es ciego a todo aquello que acontezca entre las mismas. Es decir, puede ver que un programa malicioso lee datos de un archivo, pero no puede determinar cómo estos datos son procesados. Por ello, algunos entornos van un paso más allá y también monitorean las instrucciones que se ejecutan entre llamadas.
Virtualización o emulación: esa es la cuestión
Lo siguiente a preguntarnos es cómo podemos construir un entorno difícil de detectar para el malware. Las dos opciones principales son la virtualización y la emulación.
Un emulador es un programa que simula la funcionalidad de otro o un componente de hardware. Dado que implementa funcionalidad por software, proporciona una gran flexibilidad y la capacidad de recopilar información muy detallada acerca de la ejecución.
El programa incluso podría ser escrito para una arquitectura diferente a aquella sobre la cual el emulador se ejecuta –como ser ejecutar un programa de Android escrito para ARM, en un emulador sobre un host x86. El inconveniente de la emulación es que la capa de software incurre en una penalización en el rendimiento, que debe ser cuidadosamente administrada a fin de crear un sistema escalable.
Con la virtualización, el programa huésped se ejecuta realmente en el hardware subyacente. El software de virtualización (VMM, Virtual Machine Monitor) sólo media en los accesos de las diferentes máquinas virtuales al hardware real.
Así, éstas son independientes, y pueden ejecutar programas a velocidad casi nativa. Sin embargo, un programa en ejecución ocupa los recursos físicos reales, y como resultado, el VMM y el sistema de análisis no pueden ejecutarse simultáneamente, volviendo un desafío a la recolección detallada de datos. Además, es difícil lograr ocultar por completo el VMM de las rutinas de detección embebidas en las muestras de malware.
Hasta aquí, ¿qué hemos aprendido?
En este post hemos analizado los principales aspectos a evaluar al crear entornos de análisis: qué objetivos buscamos, qué debemos analizar en el proceso y cuáles son las técnicas actualmente más empleadas para su construcción.
Próximamente, ahondaremos sobre estas implementaciones, analizando las correspondientes ventajas y contrapartidas de estos enfoques.