Analizando el gusano BUNDPIL – Parte II


En la entrada pasada estuvimos viendo las primeras impresiones sobre este gusano, vimos el método sutil que usa para engañar al usuario además de sus primeras acciones al caer en la trampa y ejecutar el acceso directo. En esta entrada seguiremos analizando el recorrido de este gusano, veremos como se instala en el Host y las primeras acciones maliciosas que realiza una vez ha garantizado su estancia en la PC infestada, continuemos

Sacando la artillería

Lo último que habíamos visto era que el gusano nos había dejado un regalito en “C:\Temp”, un ejecutable que había sido producto del descifrado del fichero que también residía en la memoria USB “Thumbs.db” y que se disponía a ejecutar

Captura

El fichero “TrustedInstaller.exe” se encuentra cifrado y con basura de relleno, lo que hace difícil obtener algún tipo de información de sus posibles acciones de forma estática sin limpiarlo antes.

Captura2

Vemos como utiliza algo de código con el fin de mantener sus secretos bien escondidos, aun así, luego de quitar la capa de protección que posee podemos analizarlo mucho mejor. El ejecutable esta creado en VC++ y pesa 168 Kb. Veamos la pinta de la función WinMain

Captura3

Vemos una función al inicio que lo que hace es verificar los privilegios en los cuales se está ejecutando el gusano (GetTokenInformation/CheckTokenMembership) y de esta forma poder realizar las acciones correspondientes más delante de acuerdo a su nivel de permisos. El ejecutable continua inicializando sus variables, luego se oculta a si mismo con una llamada a SetFileAttributes y el parámetro FileAttributes = HIDDEN|SYSTEM para terminar durmiendo por 10 segundos. (Sleep)

Más abajo hay algo interesante y que quisiera apuntar, es algo que vendría siendo como un método antidebuggin, digo yo :P, veamos a lo que me refiero.

Captura4

Toma las coordenadas del puntero del mouse justo antes de entrar al Sleep(10000) y después de despertar para luego comparar los puntos X y Y de cada llamada, o sea, en otras palabras, verificar si el mouse no se ha movido de lugar en esos 10 segundos (muy probable si solo estamos pegados con las teclas de depuración).

En fin, al pasar esta comprobación entra en otro tipo de funciones, y lo siguiente es intentar abrir un objeto Mutex nombrado “TLS” para comprobar si ya se encuentra alguna otra instancia del gusano abierta, en cuyo caso saldría de la rutina

Captura5

Al estar seguro que es el único en control, continua y lo hace con una rutina que buscará entre los procesos que se encuentran en ejecución por uno en particular

Captura6

Haciendo uso de las funciones Process32First/Process32Next compara el nombre de cada proceso ejecutándose con la cadena “avp.exe” (proceso de kaspersky).

Captura7

En este punto el gusano se encuentra en un cruce de caminos, pues dependiendo del resultado de la búsqueda, o sea, de que se encuentre o no el kaspersky como antivirus en la pc, el malware tomara acciones diferentes.

Hay alguien en casa?

Veremos primero el caso que se daría cuando no se encuentre el KAV o ningún AV at all instalado XD. El gusano seguiría y lo primero que haría luego de la verificación anterior es conseguir la ruta de los ficheros temporales del usuario actual (GetTempPath) para crearse una carpeta (CreateDirectory) llamada “#MSI”, luego en esa carpeta se dispone a crear, o mejor dicho, a droppear un ejecutable que anteriormente tenia cifrado en su interior. Crea el fichero con nombre “msiexec.exe” y escribe en él el contenido del buffer descifrado.

Captura8

Una vez ha terminado de extraer el fichero entra en una función que trabaja con algunas claves del registro.

Captura9

Utiliza la misma función que ya vimos antes para verificar los privilegios que posee y de acuerdo al nivel que tenga abrirá una rama u otra en el registro “HKEY_LOCAL_MACHINE/HKEY_CURRENT_USER\SOFTWARE\Microsoft”. Luego se dispone a establecer el contenido del valor “0022FF03“, que si vemos en la imagen le pasa en el buffer un binario con cabezera .ZIP

Captura10

Este binario también se encontraba cifrado al principio y es el segundo que droppea la aplicación. A continuación el gusano vuelve a abrir otra llave del registro en este caso será “HKEY_CURRENT_USER\SOFTWARE”, una vez tiene el acceso, el ejecutable se copia a si mismo (CopyFile) a la carpeta de temporales del usuario actual con un nombre escogido al azar (GetTempFileName) con el prefijo “0”, una vez copiado se obtiene un manejador al nuevo fichero (CreateFile) con Access = GENERIC_READ, pasa todo el contenido a memoria y le realiza una especie de cifrado, básicamente se basa en SUB 0x41 + XOR 0x65, finalmente intenta guardar el buffer cifrado en un valor llamado “ImageBase” dentro de la llave abierta

Captura12

Por lo que al final tendríamos una copia cifrada del ejecutable “TrustedInstaller.exe” en el registro en la clave “HKEY_CURRENT_USER\SOFTWARE\ImageBase”. Muy bien, al terminar libera la memoria usada y los handles de la llave de registro y del fichero, elimina el fichero temporal que usó como base para cifrar (DeleteFile) y sale de la rutina. Antes de culminar su ejecución el proceso intenta no hacerlo sin antes dejarnos con otro invitado

Captura13

Como última acción se dispone a ejecutar el ejecutable que extrajo al principio y que se encuentra en “%Temp%\#MSI\msiexec.exe“. Una vez ha hecho esta llamada el proceso termina su ejecución.

Con el KAV de guardia

El otro comportamiento que seguiría el malware al encontrar un proceso llamado “avp.exe” corriendo en la PC huésped sería muy parecido al anterior, solo con algunas variantes. Una vez que ha pasado la comprobación del proceso y lo ha encontrado, verifica a través de una bandera si se está corriendo con privilegios elevados la aplicación, en caso afirmativo se obtiene la ruta (ExpandEnvironmentStrings) “%ALLUSERSPROFILE%” y se crean los subdirectorios “%ALLUSERSPROFILE%\Local Settings\Temp”; en caso contrario se obtiene la ruta “%USERPROFILE%\Temp”.

Luego se pasa a una rutina que crea un nombre aleatorio de fichero, al cual le añade la extensión “.exe” y lo añade a su vez a la ruta anteriormente confeccionada. Como ya lo vemos venir, este será un ejecutable que estará creando con atributos Attributes = HIDDEN|SYSTEM y al que escribirá los mismos bytes descifrados que el fichero “msiexec.exe” que recién vimos unas líneas antes, por lo que en otras palabras, este fichero seria el mismo “msiexec.exe” en otra ruta y con otro nombre.

A partir de ahora el código se comporta de la misma forma que vimos anteriormente, usa la misma función que analizamos antes para crear los valores “HKEY_LOCAL_MACHINE/HKEY_CURRENT_USER\SOFTWARE\Microsoft22FF03” con el mismo binario con cabezera de fichero .ZIP y el valor “HKEY_LOCAL_MACHINE/HKEY_CURRENT_USER\SOFTWARE\ImageBase” con los datos cifrados del ejecutable “TrustedInstaller.exe”.

Como la vez anterior el ejecutable quiere terminar pero no sin antes ejecutar el fichero recién extraido

Captura14

Una vez lo ha ejecutado, la aplicación espera por una confirmación del proceso con WaitForSingleObject y el parámetro INFINITE, una vez el handle del proceso se haya en estado “signaled” el gusano crea un notificador de modificaciones de estados con las API FindFirstChangeNotification y FindNextChangeNotification.

Captura15

Pasando como parámetro la constante FILE_NOTIFY_CHANGE_FILE_NAME se establecen notificaciones sobre los cambios en los ficheros de un directorio o subdirectorio, ya sean intentos de renombrar, borrado o creación de archivos. Al verificar por 2 minutos que no ha sufrido cambios el fichero monitoreado, se verifica que todavía exista como lo había extraido (mismo nombre) con la API GetFileAttributes. Si el fichero se encuentra intacto y no ha sido eliminado entonces le crea un acceso directo con nombre “(empty).lnk” en “%ALLUSERSPROFILE%\Start menu\ProGrams\StaRtup” o “%USERPROFILE%\Start menu\ProGrams\StaRtup” dependiendo del nivel de permisos que tenga. En este caso esta función falla para sistemas XP en español, pues la ruta no estaría correcta (idioma) y el acceso directo nunca se crearía.

Como ya hemos visto, al final de cualquiera de los caminos que tome, el dropper “TrustedInstaller.exe” creara el mismo fichero ya sea con nombre “msiexec.exe” o “%rand%.exe”, será el mismo ejecutable, por lo que ahora estudiaremos el primero para ver que otras sorpresas nos trae.

Dentro del engendro

El ejecutable “msiexec.exe” se encuentra cifrado al igual que su padre “TrustedInstaller.exe” y como él sus primeras acciones son buscarse las direcciones de algunas API’s que necesitará, utilizando una rutina que usa la dirección base de la librería deseada y un hash del nombre de la función que desea. La rutina busca las direcciones correctas cifrando el nombre de cada API en la IT y comparando con el hash pasado por parámetro

Captura19

Al coincidir ambos valores esto quiere decir que se ha encontrado y se guarda la dirección de la función para su posterior uso. Luego que culminan estas labores su segundo movimiento es verificar que no existe otra instancia en ejecución

Captura16

Para esto intenta abrir un Mutex con nombre “lol”, si la acción es exitosa sale de la función y el proceso es terminado, si no existe el Mutex, quiere decir que no hay interferencia y puede continuar. Lo próximo que hace el malware es pasar una lista negra sobre los procesos que se encuentran en ejecución en la PC (CreateToolhelp32Snapshot/Process32First/Process32Next). Para hacer la comparación de nombres no utiliza el texto en plano, sino que se vale de la misma función resumen que vimos hace unas líneas y que utiliza para buscar API’s, y luego compara con hashes hardcoded.

Si no se encuentra ningún proceso de la lista negra, continua con otra comprobación y es la de intentar cargar el modulo “sbiedll.dll” (libreria de la aplicacion sandboxie), en caso de que no lo encuentre continua su ejecución buscando las direcciones de otras funciones que necesitara, de la librería “ADVAPI32.dll” con el mismo método que ya vimos.

Lo que sigue ahora es un método anti-VM/DBG que usa el gusano para cambiar su comportamiento dependiendo de si está ejecutándose virtualizado/depurado o no. El método que utiliza es algo interesante y por eso vamos a verlo de cerca. Lo primero que hace es abrir la llave del registro “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\diskenum

Captura17

Y tomar el contenido del valor “0”, que vendría siendo la cadena en texto plano de la ruta de acceso al primer dispositivo de almacenamiento de la PC, o sea, al disco duro 0. En un SO sin virtualizar, una posible cadena de ejemplo de este valor podría ser:

IDEDiskST380011AS______________________________3.00____5&2aa92c33&0&1.0.0

En cambio, esta otra sería la de un SO corriendo en una VM:

IDEDiskVMware_Virtual_IDE_Hard_Drive___________000000013030303030303030303030303030303030303130

Se nota la diferencia?. Luego pasa la cadena obtenida a minúsculas y selecciona los 4 caracteres pasados los primeros 8 para compararlos con algunos valores

Captura18

Como vemos en la imagen comprueba que no se esté ejecutando el gusano en ninguna de esas VM, más abajo utiliza también un conocido método anti-DBG haciendo uso de dos instrucciones RDTSC y verificando que el lapso de tiempo entre ambas no fue mayor de 0x200.

Ahora, si el gusano detectó hasta este punto algo que no le gusto, ya sea un proceso de la lista negra en ejecución, el modulo “sbiedll.dll” en memoria o si está siendo virtualizado/depurado entonces modificara su comportamiento, y realizara lo que sigue.

Gusano paranoico

El malware vuelve a descifrar otra parte de su código, utiliza ZwAllocateMemory para ello y luego intenta ejecutar el código descifrado (CALL NEAR EAX). El nuevo código obtiene la ruta para el fichero “%ALLUSERSPROFILE%\svchost.exe” (ExpandEnvironmentStrings), luego se copia a sí mismo como dicho ejecutable (CopyFile), y le pone atributos FileAttributes = HIDDEN|SYSTEM. Más adelante abre la llave “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” o “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run” en caso de fallar la primera y garantiza su inicio automático con el SO añadiendo el valor “SunJavaUpdateSched

Captura20

Una vez ha garantizado este aspecto, el gusano hace algún trabajo con sockets, usando las funciones winsock: WSAStartup, ntohs, WSASocketA, bind, listen y accept; con esto crea una infraestructura de escucha y ejecución de instrucciones, veamos

Captura21

Como se puede ver en la imagen se crea un bucle infinito donde el malware se convierte en una puerta trasera en el host, con un socket escuchando y creando una consola oculta con su manejador de entrada, salida y error, re-direccionado por el recibido por accept().

El trabajo lo hace estableciendo el valor dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW de la estructura STARTUPINFO pasada a la función CreateProcess, luego establece los valores HANDLE hStdInput;  HANDLE hStdOutput;  HANDLE hStdError; al manejador devuelto por el socket y se asegura que no sea mostrada la ventana de la consola poniendo el valor WORD wShowWindow = 0; dándole al atacante lo que vendría siendo una perfecta Shell Remota en el puerto 8000.

This is real life

En caso que no se esté ejecutando de forma virtualizada o depurando, el gusano descifra otra parte de su código y se dispone a ejecutarle al igual que lo que acabamos de ver. Primero la aplicación obtiene un manejador del fichero “…WINDOWS\system32\wuauclt.exe” o “…WINDOWS\syswow64\svchost.exe” en caso de estar en x64 (GetWindowsDirectory). Una vez obtiene el acceso, mapea el archivo en memoria (ZwCreateSection/ZwMapViewOfSection), obtiene los valores de su SizeOfImage y su AddressOfEntryPoint y los almacena para usarlos posteriormente, una vez concluido esto lanza el proceso (CreateProcess) en modo CreationFlags = CREATE_SUSPENDED, vuelve a mapear el fichero, se ubica en su EP y modifica las dos primeras líneas por las instrucciones:

PUSH offset
RET

Donde “offset” es una dirección en memoria dinámica en el proceso suspendido donde el gusano ha copiado otra parte de su código. Al terminar pone en marcha el proceso modificado

Captura22

De esta forma el gusano ha creado una versión modificada en memoria del proceso en cuestión.

Hasta aquí hemos visto como se ha comportado el malware una vez se ha ejecutado en la PC host, hemos visto como las acciones que realiza el ejecutable “TrustedInstaller.exe” lo convierten en lo que viene siendo básicamente un “dropper”, por su parte hemos visto también el fichero extraído “msiexec.exe”, como tiene un doble comportamiento dependiendo de algunas comprobaciones que realiza, incluyendo un interesante método anti-VM y otro anti-DBG, pudiendo actuar como “backdoor” en algunos casos (dándole una shell remota a cualquier atacante) y como algún tipo de lo que conocemos como “RunPE” en otros. En la siguiente y ultima entrada de esta serie estaremos analizando el proceso modificado “wuauclt.exe” o “svchost.exe” según sea el caso, y veremos las acciones maliciosas que realizara el código inyectado y/o modificado por este gusano en el proceso, incluyendo la rutina de propagación a dispositivos extraíbles que como hemos visto no está nada mal…bueno, pues eso…

Nos vemos en la próxima y última parte

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s