Análisis de los ficheros XLS usados por TA505

Ya vimos que se extraía del fichero Excel , aunque la manera en la que lo hace la programación de las macros es lo interesante.

Quise que vieseis que era posible detectar y extraer esas DLL directamente sin necesidad de abrir Microsoft Office.

Podemos utilizar esta sencilla regla yara para detectar ficheros ejecutables (exe o dll, por ejemplo) y extraerlos de la manera que habíamos visto en el post anterior.

rule Executable_Inside_Excel
{
meta:
Author = "by Rafa"
URL = "https://ciberseguridad.blog/documentos-xls-utilizados-por-ta505/"
Description = "Detect executable files inside Excel files"
strings:
$magic = { D0 CF 11 E0 A1 B1 1A E1 00 00 00 }
$MZ = { 4D 5A }
$This = "!This program cannot be run in DOS mode."
condition:
$magic and $MZ and $This
}

Vamos al lío… :D

Una vez abrimos el documento de Excel nos sale el mensaje de “Habilitar contenido”:

De momento estamos a salvo, pero como se pulse en el botón o tengas configurado la seguridad de las macros como confiables, es decir, se activan directamente sin la intervención del usuario, entonces poco puedes hacer ya, salvo llamar a los bomberos. Es la última opción que se ve en la siguiente captura.

Generalmente esta opción no debería estar marcada y Microsoft lo deja claro: “no recomendado”, hay que hacerle caso.

Si abrimos el editor de Macros, vemos la composición del documento:

Tiene una serie de módulos en donde se encuentra el grueso de la programación de las macros y un par de formularios de diálogo.

En el primer formulario que se ve “Dialog4”, se encuentran datos que utilizará las macros a la hora de extraer un objeto OLE, lo veremos después.

En el segundo (WelcomeDialog), vemos la ventana que nos muestra el documento mientras realiza las acciones que veremos a continuación, para que no se sospeche que algo malo está ocurriendo en el equipo. Te hacen pensar que están configurando un componente de Microsoft Office, la realidad es otra muy distinta.

Utilizamos las ventanas de Inmediato y Locales para ver qué está ocurriendo con la programación de las macros, veremos como las variables van cambiando y en caso de querer ver el contenido de una concreta nos ayudarán a ello.

Ponemos “breakpoints” en cada punto sospechoso, al final de las funciones y en las variable e iremos viendo su valor paso a paso.

Trataré de centrarme en los puntos relevantes, en los que se vean datos de variables como rutas o nombres de ficheros que aporten una visión de lo que hace la programación de las macros.

Con F8 iremos recorriendo “paso a paso” cada línea.

Vemos cómo va a cargar la función “WuzzyBud” dentro del módulo 0 y le pasa como argumento el valor 800.

Si entramos en ese módulo veremos cómo las variables cambian y le podemos poner valores:

No voy a ir tan “paso a paso”, simplemente quiero que veais cómo se ve en las ventanas que os he mostrado antes.

Ese valor 800 es el que se le asigna a la variable “dImmer”. Lo vemos en la ventana de Locales. Lo interesante de esta ventana es que aparecen las variables contenidas en la función y sus valores actuales. A medida que pulsemos F8 irán cambiando.

Es posible saber lo que va a contener la variable de forma visual en algunos puntos, podemos utilizar la venta de Inmediato para ello: “Major health problems”.

Después de estas breves explicaciones sobre las ventanas que vamos a utilizar nos metemos de lleno con la programación de las macros.

Nos encontramos con valores dentro de los formularios que van a ser utilizados.

El directorio temporal jugará un papel importante en todo esto.

Justo después cambia a su valor en el equipo, la ruta completa, ya no de la variable temporal:

Y cambia al directorio, si vemos el contenido antes de pulsar F8, vemos otra ruta, por esto está bien utilizar la ventana de Inmediato:

Hasta el momento tenemos el directorio temporal y este otro, que en breves momentos veremos lo que se guardará ahí.

Seguimos y vamos a la función “principal” de toda la programación: “DerTip”

Entramos dentro y nos detenemos aquí:

Las 3 últimas variables son las que van a realizar la magia del fichero Excel, tenemos un fichero “xlsx”, el mismo terminado en “zip” y un fichero “oleObject*.bin”. Arriba el directorio temporal y otro en que que aparece un directorio “Templates\libConfig”, posiblemente la cadena no haya sido completada (luego lo veremos).

Esta función se encarga de guardar el libro actual y guardarlo como un fichero.

¿Donde?

En el directorio temporal como “mannual.xlsx”.

Acto seguido, lo copia como fichero “.zip”.

Y se prepara para extraer el siguiente fichero.

Esto es debido a que como sabéis, los fichero xlsx, son zip con una estructura. De esta forma, es más fácil acceder al interior del fichero Excel y extraer ese “oleObject1.bin” en el directorio temporal.

Una vez que ya tiene el fichero en su sitio, se dispone a extraer los ficheros o dll que habíamos visto en el artículo anterior.

Primero comienza con la DLL “libConfig2.dll” y después “libConfig1.dll”. Como os decía arriba, la cadena aún no estaba completa, ahora ya sí, con una de las dll.

Aquí tenemos la dll guardada en el array “HurricanMoes()” que pisará disco finalmente como “libConfig2.dll”, llamándola una vez que la tiene preparada:

Vemos como la función devuelve: “Error 2015”:

Después repetirá lo mismo para la segunda dll incluída en el fichero “oleObject1.bin”.

Guardará el contenido de la variable en el fichero “libConfig1.dll”.

Y la llamará como la anterior:

Como resultado a la llamada tenemos que varRes1 es igual a 0 y saldrá de la función, por lo que esta ha tenido éxito.

Por lo tanto esta segunda dll es la que ha tenido éxito, que como veíamos en el post anterior correspondía con la versión de 32 bits.

$ file libConfig*.dll
libConfig1.dll: PE32 executable (DLL) (console) Intel 80386, for MS Windows
libConfig2.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows
`

¿Pero porqué se ha utilizado una y no la otra? Las 2 podrían haber funcionado en la máquina de análisis de 64 bits...

La culpa la tiene la versión de “Excel.exe” de Microsoft Office.

Por lo tanto es la DLL la que comprueba su arquitectura y dependiendo de ella se inyecta o no. En caso de tener éxito, devolverá 0 como vimos en lugar de “Error 2015”.

Si te vas a inyectar en un proceso es mejor que sea de la misma arquitectura, para evitar sorpresas. Si el proceso es de 64 bits podrás inyectar binarios de 64 y 32 bits. Pero si el proceso es de 32 y tratas de inyectar un binario de 64, pues tendrás problemas :D

Y mientras tanto el usuario ve el siguiente mensaje:

¿Qué estará pasando con este fichero Excel que no funciona? Pues eso, que pasas a formar parte de un entramado en el que tu pc está comprometido y puede que como colofón te dejen algún ransomware como regalo. Esperemos que no.

Espero que os haya gustado!
Hasta otra!