El siguiente post es una traducción de la publicación “Olmasco bootkit: next circle of TDL4 evolution (or not?) escrita por nuestro colega Aleksandr Matrosov.

Olmasco (también conocido como SST y MaxSS) es una modificación de la familia de bootkit TDL4 de la cual tenemos conocimiento desde el verano de 2011, sin embargo, a partir de 2012 hemos comenzado a observar la propagación de un troyano dropper destinado a instalar este código malicioso en el sistema infectado. Esta familia de bootkit fue la segunda en utilizar la infección del VBR (Volume Boot Record) para evadir la política de firma de código en modo privilegiado. La primera en utilizar esta técnica fue Rovnix. Después de completar el análisis de Olmasco, no encontramos ningún cambio en la parte principal de esta amenaza como para mencionarlo. La mayoría de los componentes maliciosos del sistema de archivos fueron compilados a principio de julio de 2012.

El cambio más radical y por lo tanto el más interesante, es el dropper de Olmasco: el código encargado de instalar esta amenaza fue desarrollado desde cero para una nueva campaña de distribución. El nuevo dropper de Olmasco posee varias técnicas para evadir análisis en sandbox, e incluye una protección dump anti memoria. Una vez que esta amenaza es ejecutada, en el momento que es desempaquetada, el dropper limpia información de la cabecera PE como parte del proceso. Posteriormente, cuando recibe el control en OEP (Original Entry Point), las cabeceras PE del código desempaquetado aparecen como limpias. En la siguiente imagen se puede apreciar dicho cambio. En la de la izquierda aparece la cabecera PE limpia y en la segunda, restaurada:

Esta técnica dificulta el volcado de memoria durante el proceso de depuración (debugging) o en aquellos análisis que desempaquetan los ejecutables de forma automática. Para detectar si ha sido ejecutado en un ambiente virtual, el dropper de Olmasco obtiene información del sistema infectado a través de la interfaz WMI (Windows Management Instrumentation).

El dropper realiza estas solicitudes a WMI (SELECT * FROM %s WHERE $s LIKE “%%%s%%”) para determinar la existencia de ambientes virtuales y emuladores como Bochs o QUEMU. Si el código malicioso detecta este tipo de situación, procede a terminar su ejecución y elimina el archivo infectado del sistema. Todos los componentes relacionados al bootkit y al sistema de archivos ocultos son guardados en la sección de recursos cifrados del dropper. Esta sección se ve de la siguiente forma:

El proceso de descifrado utiliza el algoritmo RC4 tal como puede observarse en la siguiente imagen:

Después del desempaquetado y la preparación de sus componentes provenientes de la sección de recursos, el dropper de Olmasco posee tres métodos para lograr infectar un sistema:

1) Infección del VBR para sistemas de 64 bit.

2) Infección del VBR para sistemas de 32 bit.

3) Infección del MBR en caso de que los métodos anteriores fallen.

Antes de esta versión, Olmasco solo infectaba una computadora a través de la modificación del VBR, sin embargo, ahora también es capaz de hacerlo a través del MBR. En todos estos casos, las funcionalidades son iguales, no obstante, la rutina de infección cambia.

El código encargado de la rutina de infección de VBR ha sido modificado sutilmente con respecto a la versión anterior con el objetivo de evadir la detección estática de los antivirus. Algunas instrucciones lucen iguales en mnemonics, pero con valores de ceros en la estructura opcode (técnica que recuerda el uso de NOPs aleatorios como una forma primitiva de evadir la detección de antivirus que utilizan firmas). En las siguientes capturas se presentan las diferencias entre el código VBR antiguo y el nuevo (primera y segunda imagen respectivamente):

Existe otra diferencia pequeña con respecto al lugar en dónde almacena la contraseña de cifrado RC4 para poder extraer los componentes maliciosos del sistema de archivos oculto.

La estructura del sistema de archivos oculto ha sido modificada y luce así:

El procedimiento principal para parsear el sistema de archivos ocultos es idéntico al de la versión anterior, por lo tanto, queda confirmada nuestra suposición al respecto. Por otro lado, esta versión del bootkit Olmasco posee un nuevo driver tdi32/tdi64 en el sistema de archivos ocultos. Nuestro análisis confirmó que los mismos funcionan mediante TDI (Transport Driver Interface). El driver es inicializado a partir de drv32/drv64 luego de que el bootkit ha sido cargado correctamente. Para la instalación del driver utiliza un método sin comentar en IoCreateDriver(). Una vez finalizado, el driver es ejecutado con la siguiente llamada de función: IoCreateDriver(L”\Driver\usbprt”, tdi32EntryPoint).

El driver TDI malicioso interfiere en los siguientes dispositivos de red:

-DeviceTcp

-DeviceUdp

-DeviceIp

-DeviceRawIp

En la siguiente imagen se puede observar el código encargado de interferir en los dispositivos red mencionados anteriormente:

La función principal de este driver es monitorear las solicitudes TDI_CONNECT para las conexiones de redes. Si una solicitud es interceptada para la dirección IP 1.1.1.1, el driver cambiará la dirección a 69.175.67.172 y el número de puerto a 0x5000. El driver TDI malicioso también crea un objeto de dispositivo con el nombre DeviceInspect. Sin embargo, durante este análisis dicho dispositivo no fue creado en la máquina infectada ni tampoco pudimos encontrarlo en otros componentes de Olmasco.

HiddenFsReader (ESET Hidden File System Reader), herramienta gratuita que permite examinar el sistema de archivos oculto instalado por Olmasco, será actualizada pronto para funcionar con esta nueva variante. Asimismo, se agregarán nuevas funcionalidades relacionadas a la usabilidad de la aplicación. Además, los productos de ESET detectan este código malicioso como Win32/Olmasco.