Finalmente hemos llegado a la última entrega en esta serie de posts sobre entornos automatizados para análisis de malware. Ya hemos discutido los principales aspectos a considerar al crear un entorno de análisis: qué objetivos buscamos y qué debemos evaluar en el proceso. También analizamos las técnicas empleadas para su implementación, con sus ventajas y desventajas. Es tiempo de efectuar un análisis integrador al respecto.
¿Cómo construir un entorno de pruebas eficiente?
Claro está que mientras más visibilidad obtengamos, mejor. Podemos construir un entorno personalizado basado en virtualización, de modo que cuando un programa compruebe si hay archivos específicos o procesos que un VMM conocido introduce, estas comprobaciones fallen y el sandbox logre observar la actividad maliciosa.
Sin embargo, la virtualización, por definición, significa que el código malicioso se ejecuta directamente en el hardware subyacente, y mientras que éste se está ejecutando, el sandbox está en pausa; sólo se reanuda en puntos específicos, como las llamadas al sistema.
Entonces, ¿por qué no utilizar directamente emulación de sistemas? La razón es que se deben superar dos desafíos técnicos para hacer que un emulador funcione. Uno de ellos se denomina brecha semántica, y el otro es el rendimiento.
La brecha semántica está relacionada con el problema de que un emulador de sistema ve instrucciones ejecutadas en la CPU, así como también la memoria física que utiliza el sistema operativo huésped, sin resultar claro cómo conectar las instrucciones de la CPU y los bytes en la memoria con los objetos que tienen sentido en el contexto del sistema operativo.
Después de todo, verdaderamente queremos saber acerca de los archivos que crea un proceso, o los registros que lee. Para cerrar la brecha semántica, se necesita una comprensión profunda del funcionamiento interno del sistema operativo en cuestión. Al hacer esto, podemos mapear la vista detallada de bajo nivel de nuestro sistema a la información de alto nivel sobre archivos, procesos y tráfico de red.
En segundo plano, debemos preguntarnos sobre el rendimiento. ¿No es la emulación demasiado lenta? La respuesta es sí, si se aplica erróneamente. Si emulamos todas las instrucciones en el software, el sistema ciertamente no escalará muy bien. Sin embargo, existen enfoques inteligentes que permiten acelerar la emulación a tal nivel que resulta casi tan rápida como la ejecución nativa.
Por ejemplo, no es necesario emular todo el código; podemos confiar en el kernel la mayor parte del tiempo –por supuesto, puede verse comprometido por rootkits. Sólo el programa malicioso –y el código con el que este programa interactúa- necesita ser analizado en detalle. Además, se puede realizar la traducción dinámica, con la cual cada instrucción se examina en el software una vez y luego se traduce a una forma más eficiente que se puede ejecutar directamente.
En resumen…
No todos los entornos de análisis son iguales. La mayoría de los sistemas de sandboxing aprovechan la virtualización y confían en llamadas al sistema, lo que es insuficiente, especialmente considerando que nos enfrentamos a malware cada vez más consciente de técnicas de sandboxing.
Para la mejor recolección de datos, debemos combinar la visibilidad de un emulador con la resistencia a la detección –y evasión- que se obtiene al ejecutar el software malicioso en el interior del sistema operativo real, y de esta forma, sabremos cómo construir un entorno de pruebas eficiente
