Anteriormente analizamos cuáles eran los principios básicos a tener en cuenta en un entorno de análisis automatizado. Esta vez, presentaremos las técnicas de emulación y virtualización como enfoques de implementación de sandboxes, estudiando los pros y contras de utilizar estas tecnologías en el análisis de códigos maliciosos.

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 de software que simula la funcionalidad de otro programa 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.

Aprovechando la emulación y virtualización para el análisis de malware

Como se mencionó anteriormente, la tarea de un emulador es proporcionar un entorno simulado en tiempo de ejecución en el que un programa malicioso pueda ejecutarse. Hay dos opciones principales para esto. En primer lugar, se puede emular el sistema operativo. Un programa se ejecuta en modo de usuario y necesita hacer llamadas al sistema para interactuar con su entorno.

Así que, ¿por qué no simplemente emular estas invocaciones? Mientras que el malware se está ejecutando, se puede obtener un vistazo de cerca a su actividad –se puede ver cada instrucción. Cuando el malware trata de hacer una llamada al sistema, esta información se puede grabar fácilmente. En este punto, el emulador simplemente pretende que la llamada al sistema se ha ejecutado correctamente y devuelve el resultado esperado al programa.

Esto suena bastante simple en teoría, pero no es tan fácil en la práctica. Supongamos el caso de Windows: la interfaz nativa de llamadas al sistema no está documentada, y Microsoft se reserva el derecho de cambiarla a voluntad. Por lo tanto, un emulador típico apuntará a la API de Windows, un conjunto de librerías de funciones de más alto nivel.

Por desgracia, existen miles de estas funciones en la API de Windows. Aún más, Windows es una enorme pieza de software, y simular fielmente su arquitectura requiere un emulador de complejidad semejante. Como esto no es práctico, los emuladores suelen centrarse en un subconjunto de funcionalidades mayormente utilizadas. Por supuesto, los autores de malware están al tanto de esto, y simplemente invocan las funciones de uso menos frecuente para comprobar si el sistema se comporta como se espera –es decir, como un sistema operativo Windows genuino.

Los emuladores fallan en este punto, y dichos entornos de sandboxing resultan fáciles de identificar y evadir, por lo tanto es necesario complementar con otras técnicas de detección. Como segunda opción para un emulador, se puede simular el hardware –en particular, la CPU y la memoria física. Esto se llama emulación de sistema, y posee varias ventajas. En primer lugar, se puede instalar y ejecutar un sistema operativo real sobre el emulador. Por lo tanto, el malware se ejecuta dentro de un SO real, haciendo que el entorno de análisis sea mucho más difícil de detectar.

La segunda ventaja es que la interfaz ofrecida por un procesador es mucho más simple que la interfaz proporcionada por el SO. Sí, incluye cientos de instrucciones, pero están muy bien documentadas, y casi nunca cambian. Por último, un emulador de sistema tiene una gran visibilidad. Un sandbox basado en la emulación del sistema ve cada instrucción que un programa malicioso ejecuta sobre el procesador emulado, y puede monitorear cada acceso a la memoria emulada.

Las plataformas de virtualización proporcionan significativamente menos opciones para la recopilación de información detallada. La forma más fácil es registrar las llamadas al sistema que los programas realizan. Éstas son operaciones privilegiadas, por lo tanto, cuando un programa en una VM realiza tal operación, el VMM es notificado.

En este punto, el control pasa de nuevo al sandbox, que puede recopilar los datos deseados. El gran desafío es que es muy difícil grabar de manera eficiente las instrucciones individuales que un proceso ejecuta sin que éste detecte la intrusión. Después de todo, se devuelve el control al proceso entre llamadas al sistema. Ésta es una limitación fundamental para cualquier entorno que utilice virtualización.

En retrospectiva…

Hemos aprendido los conceptos necesarios para sostener una buena toma de decisiones al momento de construir un entorno de análisis eficaz. Nos encontramos en condiciones para efectuar conjeturas globales sobre el tema, pero para ello esperaremos a la próxima publicación