Con el actual crecimiento exponencial de malware circulando por la red, las empresas de antivirus se ven obligadas a buscar nuevas formas para detectar y evadir estas amenazas. Además de usar las tradicionales bases de datos de firmas para buscar coincidencias con los ficheros, también hacen uso de complejas técnicas de heurística para detectar pro-activamente amenazas, basándose en el comportamiento de los ejecutables, accesos a memoria y analizando el código que se ejecuta en nuestro ordenador.
Si bien es cierto que estas técnicas funcionan bastante bien, los desarrolladores de malware siguen saliéndose con la suya y consiguen infectar miles de equipos a diario. Para evitar que sus programas maliciosos sean estudiados por los investigadores, una característica que los creadores de estos incluyen en su malware, es la detección de máquinas virtuales o de las herramientas de debugging, técnica que les permite detectar si su ejecutable está ejecutándose en una VM o dentro de una sandbox. De esta forma, si intentamos ejecutar una muestra de malware en una máquina virtual, esta probablemente no hará nada o actuará de forma benigna, intentando así pasar desapercibida en un entorno propicio para ser analizada.
Pero… ¿podríamos usar esta característica del malware a nuestro favor? Si los desarrolladores intentan evitar la ejecución de sus programas en máquinas virtuales, ¿por qué no replicar la configuración de una VM en un equipo físico y así evadir infecciones? El objetivo final sería conseguir aplicar una característica defensiva del malware para obtener un punto más de fortificación de sistemas Microsoft Windows contra precisamente malware.
A principio de octubre, Jordi Serra me propuso presentar un artículo en la ronda europea de Cyber Security for the Next Generation, una conferencia estudiantil organizada por Kaspersky Academy. Me decanté por hacer una herramienta que emulara máquinas virtuales para evadir infecciones de malware o, por lo menos, una parte de los programas maliciosos. La idea consistía principalmente en estudiar a fondo una VM, inicialmente Virtual Box, y tratar de replicar al máximo sus características en un equipo físico.
Dentro del registro de Windows hay numerosas llaves que delatan un entorno virtual. A diferencia de un equipo físico, donde el disco duro y lector de DVD puede ser de cualquier fabricante, en una VM estos dispositivos virtuales tienen un nombre genérico. En el caso de Virtual Box los nombres son tan llamativos como “VBOX HARDDISK” o “VBOX CD-ROM”, hallados en varios “values” del registro.
Otros valores llamativos dentro del registro son los que hacen referencia a la BIOS, concretamente en las claves SystemBiosVersion y VideoBiosVersion dentro de la ruta “HKLM\Hardware\DESCRIPTION\System”. De esta forma, haciendo un par de búsquedas en el registro con las cadenas de texto “vbox” y “Virtual Box” encontraremos decenas de resultados.
Además de las numerosas carpetas y keys que se crean por defecto en el registro de Windows al instalarlo bajo Virtual Box, existen también varios archivos y librerías propios de Virtual Box Guest Additions. Aunque basarse en éstos para detectar una máquina virtual no es lo más adecuado, hay malware que, además de comprobar el registro, busca estos archivos o intenta cargar alguna DLL específica.
Conociendo todas la keys del registro y archivos que se pueden usar para detectar un sistema virtualizado con Virtual Box, “solo” nos queda crear un script que replique esta configuración en un equipo físico y probar si realmente funciona. Para desarrollar el script usé Python, principalmente por ser un lenguaje muy amigable. El código no hace nada más que crear/modificar llaves y valores del registro, crear archivos y descargar algunas librerías de Internet para registrarlas en el sistema.
Aunque esto es solo una parte del código, el resto de líneas son principalmente más modificaciones en el registro y la creación del resto de archivos comentados anteriormente. Con el script ya creado, solo queda ejecutarlo, en este caso sobre una instalación limpia de Windows XP (sistema para el que está optimizado el código) y comprobar su funcionamiento. Para probarlo, además de una muestra real de malware, podemos usar herramientas como Pafish de Albert Ortega. Esta herramienta implementa 5 comprobaciones para detectar un sistema virtualizado con Virtual Box, 4 de ellas las realiza sobre el registro de Windows y la última buscando el driver VboxMouse.sys.
Los resultados antes y después de la ejecución del script nos muestran que éste funciona bien o, por lo menos, consigue engañar a Pafish. Para realizar una prueba con malware real, usé el gusano Net-Worm.Win32.Kolab.wwh, del que podéis ver un amplio análisis en el blog de Secure list. Esta versión concreta implementa un sistema anti-debugging bastante extenso, que comprueba desde el registro de Windows hasta la ruta en la que se encuentra en el momento de su ejecución, pasando por el nombre del equipo y los procesos que se están ejecutando. Cuando una de sus comprobaciones da positivo se elimina por completo, evitando así ser analizado.
Si probáis a ejecutarlo en una máquina virtual veréis que tras su ejecución, desaparece como por arte de magia. En nuestro caso, al iniciarlo en el equipo de pruebas antes de modificarlo con el script, el gusano se instala como está programado, pero si lo ejecutamos en un sistema modificado para parecer una máquina virtual, cree que se encuentra en una VM y se autodestruye.
Aunque sea un método poco ortodoxo para evadir infecciones de malware, lo cierto es que funciona. Basándonos en esta técnica, es posible que se puedan evitar infecciones de malware aún desconocido que implemente estas técnicas de ocultación. No obstante, como prueba de concepto es válida y tanto Jordi Serra como yo, estamos trabajando duro para publicar pronto una versión estable y más compleja de la herramienta. Por ahora, si os ha gustado, podéis ver las diapositivas de la presentación que que preparé para la International Student Conference de Kaspersky celebrada en Milán el pasado mes de Diciembre, donde tuve el honor de dar mi primera charla fuera de España y compartir unos días con el estupendo equipo de Kaspersky Academy.
By Jordi Vázquez (@jordisk)
Si bien es cierto que estas técnicas funcionan bastante bien, los desarrolladores de malware siguen saliéndose con la suya y consiguen infectar miles de equipos a diario. Para evitar que sus programas maliciosos sean estudiados por los investigadores, una característica que los creadores de estos incluyen en su malware, es la detección de máquinas virtuales o de las herramientas de debugging, técnica que les permite detectar si su ejecutable está ejecutándose en una VM o dentro de una sandbox. De esta forma, si intentamos ejecutar una muestra de malware en una máquina virtual, esta probablemente no hará nada o actuará de forma benigna, intentando así pasar desapercibida en un entorno propicio para ser analizada.
Figura 1: Software de protección como Themida detecta las VM |
Pero… ¿podríamos usar esta característica del malware a nuestro favor? Si los desarrolladores intentan evitar la ejecución de sus programas en máquinas virtuales, ¿por qué no replicar la configuración de una VM en un equipo físico y así evadir infecciones? El objetivo final sería conseguir aplicar una característica defensiva del malware para obtener un punto más de fortificación de sistemas Microsoft Windows contra precisamente malware.
A principio de octubre, Jordi Serra me propuso presentar un artículo en la ronda europea de Cyber Security for the Next Generation, una conferencia estudiantil organizada por Kaspersky Academy. Me decanté por hacer una herramienta que emulara máquinas virtuales para evadir infecciones de malware o, por lo menos, una parte de los programas maliciosos. La idea consistía principalmente en estudiar a fondo una VM, inicialmente Virtual Box, y tratar de replicar al máximo sus características en un equipo físico.
Dentro del registro de Windows hay numerosas llaves que delatan un entorno virtual. A diferencia de un equipo físico, donde el disco duro y lector de DVD puede ser de cualquier fabricante, en una VM estos dispositivos virtuales tienen un nombre genérico. En el caso de Virtual Box los nombres son tan llamativos como “VBOX HARDDISK” o “VBOX CD-ROM”, hallados en varios “values” del registro.
Otros valores llamativos dentro del registro son los que hacen referencia a la BIOS, concretamente en las claves SystemBiosVersion y VideoBiosVersion dentro de la ruta “HKLM\Hardware\DESCRIPTION\System”. De esta forma, haciendo un par de búsquedas en el registro con las cadenas de texto “vbox” y “Virtual Box” encontraremos decenas de resultados.
Figura 2: Carpetas y claves de registro específicos para Virtual Box |
Además de las numerosas carpetas y keys que se crean por defecto en el registro de Windows al instalarlo bajo Virtual Box, existen también varios archivos y librerías propios de Virtual Box Guest Additions. Aunque basarse en éstos para detectar una máquina virtual no es lo más adecuado, hay malware que, además de comprobar el registro, busca estos archivos o intenta cargar alguna DLL específica.
Figura 3: Archivos creados al instalar Virtual Box Guest Addition Tools |
Conociendo todas la keys del registro y archivos que se pueden usar para detectar un sistema virtualizado con Virtual Box, “solo” nos queda crear un script que replique esta configuración en un equipo físico y probar si realmente funciona. Para desarrollar el script usé Python, principalmente por ser un lenguaje muy amigable. El código no hace nada más que crear/modificar llaves y valores del registro, crear archivos y descargar algunas librerías de Internet para registrarlas en el sistema.
Figura 4: Parte del código utilizado |
Aunque esto es solo una parte del código, el resto de líneas son principalmente más modificaciones en el registro y la creación del resto de archivos comentados anteriormente. Con el script ya creado, solo queda ejecutarlo, en este caso sobre una instalación limpia de Windows XP (sistema para el que está optimizado el código) y comprobar su funcionamiento. Para probarlo, además de una muestra real de malware, podemos usar herramientas como Pafish de Albert Ortega. Esta herramienta implementa 5 comprobaciones para detectar un sistema virtualizado con Virtual Box, 4 de ellas las realiza sobre el registro de Windows y la última buscando el driver VboxMouse.sys.
Figura 5: Resultado con la herramienta Pafish |
Los resultados antes y después de la ejecución del script nos muestran que éste funciona bien o, por lo menos, consigue engañar a Pafish. Para realizar una prueba con malware real, usé el gusano Net-Worm.Win32.Kolab.wwh, del que podéis ver un amplio análisis en el blog de Secure list. Esta versión concreta implementa un sistema anti-debugging bastante extenso, que comprueba desde el registro de Windows hasta la ruta en la que se encuentra en el momento de su ejecución, pasando por el nombre del equipo y los procesos que se están ejecutando. Cuando una de sus comprobaciones da positivo se elimina por completo, evitando así ser analizado.
Figura 6: Análisis del guano Net-Worm.Win32.Kolab.wwh |
Si probáis a ejecutarlo en una máquina virtual veréis que tras su ejecución, desaparece como por arte de magia. En nuestro caso, al iniciarlo en el equipo de pruebas antes de modificarlo con el script, el gusano se instala como está programado, pero si lo ejecutamos en un sistema modificado para parecer una máquina virtual, cree que se encuentra en una VM y se autodestruye.
Aunque sea un método poco ortodoxo para evadir infecciones de malware, lo cierto es que funciona. Basándonos en esta técnica, es posible que se puedan evitar infecciones de malware aún desconocido que implemente estas técnicas de ocultación. No obstante, como prueba de concepto es válida y tanto Jordi Serra como yo, estamos trabajando duro para publicar pronto una versión estable y más compleja de la herramienta. Por ahora, si os ha gustado, podéis ver las diapositivas de la presentación que que preparé para la International Student Conference de Kaspersky celebrada en Milán el pasado mes de Diciembre, donde tuve el honor de dar mi primera charla fuera de España y compartir unos días con el estupendo equipo de Kaspersky Academy.
By Jordi Vázquez (@jordisk)
Alucino con el ingenio de algunos...
ResponderEliminarMuy bien, eso es usar lo que tenemos encima del cuello. Buena técnica . Felicidades
ResponderEliminarHay una cosa que no entiendo. Todas esas claves y ficheros, están en el sistema anfitrión, no en el emulado. Si tu instalas un windows pelado en un VirtualBox, dentro de ese windows no están esos ficheros y claves, están fuera. Como un virus desde dentro de un sistema emulado, puede detectar todo eso que está fuera?
ResponderEliminarY si el objetivo del malware es una maquina virtual?
ResponderEliminarMuchas empresas tienen sus sistemas virtualizados para ahorrar costes... lo que provocaría ponerle al malware en bandeja el sistema real... Bueno, eso creo.
Un saludo
@Orangután, algunas de las keys si que se encuentran también en el sistema anfitrión como por ejemplo las que comento en el artículo. En la Figura 2, las keys que están resaltadas a la derecha se encuentran tanto en un sistema anfitrión como en uno virtualizado, no obstante el valor de las mismas es diferente en un sistema u otro y eso es lo que cambia el script, el valor de las keys. Las carpetas del registro que están señaladas a la izquierda de la misma figura son específicas de un sistema virtualizado con Virtual Box, de ser un sistema operativo no virtualizado existirían carpetas en esa misma ruta pero con otro nombre.
ResponderEliminarTambién hay keys y carpetas específicas de las Virtual Box Guest Additions. Los ficheros y DLLs de los que hablo, se crean al instalar las herramientas de virtual box también, por lo que solo se encuentran en el sistema virtualizado y no en el anfitrión.
@Anónimo si el objetivo es una máquina virtual esta técnica no sirve para evitar infecciones. Este artículo se basa en evitar infecciones de malware que implementa técnicas anti-vm, si el malware no implementa esta característica o bien no posee protección para VM podrá infectar el sistema. De ahí que lo enfoquemos como un posible método de evasión de amenazas y no como una solución completa anti malware.
Lo que menciona anonimo#2 tiene sentido, al ser mas del 50% de los servidores hoy en día maquinas virtuales estos mecanismos de defensa de los virus dejan de tener sentido de a poco.
ResponderEliminarPor otro lado, si te estas ganando el pan vendiendo antivirus !Hazlo en maquinas físicas por al amor de Dios! acaso van a ir a la quiebra por ponerle un par de maquinitas para trastear a cada analista?
Muy interesante el articulo.
ResponderEliminarAparte de lo que comentas, me suena de haberlo leido por ahi, pero no lo tengo claro, que a nivel hardware se puede consultar algun flag del micro para saber si el proceso en ejecucion esta virtualizado o no. Os suena?
De todas maneras como comenta @anonimo#3 hay objetivos que no son los equipos fisicos, sino mas bien los virtualizados, que es donde pueden comprometerse, a dia de hoy, servicios gordos :)
@Anonimo3
ResponderEliminarEntiendo que los desarrollados de antivirus no usan VM para ahorrar costo, sino como herramienta de análisis y debug.
Lo he comentado por Twitter...Emular estar en una máquina virtual también tiene sus peligros.
ResponderEliminarMeses atrás analicé un malware (creo recordar que era un Zbot), que si detectaba que estaba corriendo sobre Vmware, VirtualBox, Bochs o Zen Hypervisor, wipeaba el MBR del disco.
Avisados estáis :)
Me parece, muy interesante. Encontre este articulo justamente buscando la definicion de maquina virtual para un trabajo de la facultad. Actaulmente en mi trabajo pruebo sistemas operativos en VirtualBox y me apasiona leer articulos como estos en donde la seguridad es un tema comun. Felicitaciones!
ResponderEliminarsi entro a la deep web en una maquina virtua,l mi maquina anfitrion se ve comprometida de alguna manera?
ResponderEliminarDiciembre de hace dos años tuve una mala experiencia con esto y no puedo hasta la fecha resolverlo no tengo computadora de escritorio solo celular he cambiado de celular en varias ocasiones pero todo el tiempo es lo mismo ya no se que hacer
ResponderEliminar