Introducción

Hace unos meses, John Hammond comenzó a subir vídeos sobre análisis de malware en su canal de YouTube en los que realiza un análisis del código de distintos tipos de malware en distintos lenguajes. En un principio, esto me pareció poco interesante, pero tras darle una oportunidad y ver un par de sus vídeos respecto al tema, mi punto de vista cambió por completo.

Aún así, no encontraba tiempo ni ganas de estudiar un campo tan enrevesado y con tantas cosas en contra, pero después de que un amigo casi se infectara (gracias, Windows Defender) con un espécimen de malware, decidí que sería el momento de intentar analizarlo.

Niveles de análisis de malware

Dentro del campo del análisis de malware existe una gran variedad de metodologías para identificar las capacidades y el comportamiento del espécimen y, dependiendo de a qué nivel queramos investigar, vamos a necesitar unos conocimientos más avanzados.

• 

En la imagen de arriba podemos ver un diagrama representando la dificultad de cada nivel de análisis.

1. Para el análisis automático no es necesario un gran conocimiento. Basta con subirlo a alguna web que ofrezca ese tipo de servicios como VirusTotal.
2. Para el análisis estático de las propiedades, vamos a requerir un conocimiento medio de la composición de los ejecutables. Por ejemplo, algunas funciones de la API de Win32 o las secciones de los programas.
3. En el análisis del comportamiento vamos a necesitar conocimientos avanzados del SO objetivo del malware. En este caso, Windows 7, vamos a necesitar conocimientos sobre el funcionamiento del registro, de distintas carpetas y, sobre todo, leer mucha documentación de Microsoft.
4. El reversing es mucho más complejo, aunque su dificultad puede variar enormemente. En algunos casos podemos encontrar malware interpretado, como droppers de PowerShell, o podemos encontrarnos con compilados de C++, ofuscado y con instrucciones inválidas por todos lados.

En esta primera parte, vamos a pasar por todos estos niveles -excepto por el reversing- como una introducción al análisis de malware.

Contexto

Antes de empezar con el análisis de este espécimen, es importante detallar cómo, cuándo y por qué de la infección original.

Por razones de estudios, mi amigo se vio en la necesidad de portar unos documentos en su USB. Al ser enchufado en el huésped, éste fue infectado. Por suerte, al enchufar el USB de nuevo, mi amigo fue notificado por Windows Defender de que el dispositivo estaba infectado, y lo desenchufó inmediatamente. Así, Windows Defender no realizó ninguna acción y el malware se mantuvo intacto. Se puso en contacto conmigo por si lo quería revisar y acepté sin pensármelo dos veces.

Empezamos

Vamos a ver de qué se trata antes de empezar cualquier tipo de análisis. Yo he enchufado el USB en mi máquina Ubuntu para evitar cualquier infección. Antes de montarla, nos convendría guardar una copia del USB, no de los archivos. Quizá hayáis escuchado eso de que “todo en Linux es un archivo”, y éste es un ejemplo. Como aún no hemos montado el sistema de ficheros, significa que el dispositivo entero se puede acceder como un archivo a través de la carpeta /dev. Aquí se guardan -entre otras cosas- sistemas de ficheros montados y por montar. El equivalente en Linux al disco C: de Windows sería el dispositivo /dev/sda, que representa el disco principal. Las particiones se representan añadiendo números al disco una vez ha sido montado.

• 

En la imagen anterior se encuentran los archivos sda, sda1, sda2 y sda5, siendo sda el disco y el resto sus respectivas particiones.

Esto significa a grandes rasgos que podemos crear una copia del USB si copiamos su filesystem a otra carpeta, y eso es lo que vamos a hacer con el comando cp /dev/<disco_a_copiar> /nuestra/carpeta/Raw_USB. Una vez tengamos copiado el USB, podremos desenchufarlo y limpiarlo libremente y con precaución. Ahora, veremos qué tipo de archivo es con el comando file:

• 

Ahora ya podemos montar la imagen de disco en nuestro SO para poder inspeccionar qué hay dentro:

• 

Podemos ver dos carpetas: FractalSoundExplorer y System Volume Information que, si nos fijamos en los archivos que tienen su mismo nombre, nos puede dar una pista del tipo de malware con el que nos encontramos. El autorun (archivo que se ejecuta sólo al montarse) presenta unos contenidos esperables:

• 

Dentro de él, se ven distintos métodos para llamar o ejecutar el archivo Thumbs.com. ¡Bien! Ya sabemos cuál es el detonate. Pero, ¿qué es exactamente? Una mirada rápida con el comando file nos lo debería indicar:

• 

Ahora, vamos a ver si guarda alguna cadena de texto que nos ayude a identificar el malware:

reshi@reshi-virtual-machine:~/Desktop/Analysis$ strings Thumbs.com 
[...]
Thumbs   .db
[...]
C:\Program Files\Microsoft Visual Studio\VB98\VB6.OLB
[...]
shell32.dll
ShellExecuteA
RegCreateKeyA
kernel32
FindFirstFileA
hP @
FindNextFileA
FindClose
advapi32.dll
RegOpenKeyExA
h8!@
RegCloseKey
h|!@
RegCreateKeyExA
RegDeleteKeyA
h@"@
RegDeleteValueA
RegQueryValueExA
RegSetValueExA
VBA6.DLL
[...]
Thumbs   .db
MethCallEngine
EVENT_SINK_AddRef
DllFunctionCall
EVENT_SINK_Release
EVENT_SINK_QueryInterface
__vbaExceptHandler
ProcCallEngine
[...]
reshi@reshi-virtual-machine:~/Desktop/Analysis$ 

He puesto en negrita los elementos más importantes y omitido aquellos irrelevantes por el momento. Podemos ver que el archivo Thumbs .db es mencionado 2 veces. Además, podemos ver varias menciones de cosas propias de Visual Basic 6, lo cuál será de utilidad más adelante. Ahora vamos a repetir el proceso con ese otro archivo sospechoso:

[...]
_^][Y
f9D$
SVWu
u^h0
fUVWuQ3
_^][
SVWh@
f^_]
^_[]
fh/!
u PPP
E495
_^[]
ftsh8
ftbh0
ftQh$
ft@h
ft/h
^(_S
fPShg
_^[]
4SVWh
t$Vj2
fVVVVPP
fUVWt
_^][
wxt_
A@f%
VPVj0
[...]

Hay muchísimo output, pero no podemos ver nada interesante a primera vista, así que vamos a dejarlo para el análisis estático.

Análisis automático

Esta es una fase de análisis que requiere muy poco esfuerzo, pero que es muy recomendable para entender mejor con qué tipo de malware estamos tratando. Hay muchos servicios de análisis automático online, pero en éste caso voy a usar VirusTotal.

Subiendo el archivo Thumbs.com a VirusTotal podremos ver que efectivamente estamos ante una pieza de malware:

• 

Muchos de los antivirus implementados lo califican como un troyano, pero también hay algunos que lo identifican como un gusano o worm. Como ya sabemos que crea nuevos archivos con la intención de propagarse, podemos tomar como válido que es un gusano.

Si nos vamos a donde pone “Details” podremos ver, como su nombre indica, muchos detalles sobre el programa:

• 

En el apartado “Header” podemos ver el tipo de arquitectura que tiene. Los Intel 386 eran una familia de procesadores basados en, valga la redundancia, arquitectura x86 o de 32-bits. También vemos que se compiló en 2007 y que presenta 3 secciones:

• 

¿Recordáis los archivos que acababan en “.scr” de antes? Vamos a subirlos a ver qué nos cuenta VirusTotal:

• 

En efecto, son réplicas de sí mismo. Así, hemos verificado que estamos ante un gusano hecho y derecho. Ahora podemos indagar un poco más en su comportamiento yendo a la sección “Behavior”

• 

Tampoco nos dice gran cosa, pero podremos ver a qué claves de registro está accediendo. Por mi experiencia, no recomiendo fiarse al 100% de algunas herramientas de análisis automático, más adelante veremos que algunas partes que se indican ahí son erróneas para este espécimen concreto. Cabe detallar que VirusTotal no escanea como tal el malware a no ser que se le especifique lo contrario, sino que calcula su hash para identificarlo y estimarte cual es. Esto puede dar fallos con algunos especímenes concretos, así que recomiendo usar una sandbox más avanzada que VirusTotal para un análisis automático en condiciones.

Si nos vamos a la sección “Relations” podemos ver un diagrama de relaciones con otros elementos que estén en la BBDD de VirusTotal:

• 

En esta pestaña nos dice con un pequeño diagrama las llamadas a webs u otros archivos. Podemos ver que llama a otro dominio, pero que no llama a ningún archivo pese a que ya vimos que sí que llamaba en algún momento al archivo “Thumbs .db“. Si hacemos clic encima, nos muestra más detalladamente el diagrama, pero hace falta registrarse primero:

• 

Abrimos y expandimos un poco el diagrama. Para ello basta con hacer doble clic en el sitio que sea y buscará más nodos hermanos/siblings. Podemos ver que de varios siblings que tiene el dominio de VT, hay uno que está rodeado de rojo. Esto significa que varias entidades han identificado ese sitio como malicioso. Aún así, seguimos sin ver ningún archivo, así que con algo de contexto ya, vamos a repetir el proceso con el otro archivo:

• 

• 

Podemos ver que el segundo archivo malicioso está hecho con Visual C++, que es de 32-bits y que presenta 5 secciones, siendo ENGINE una de ellas. Los ejecutables presentan secciones que dividen el contenido. Para crear un ejecutable válido necesitas -al menos- la sección .text, que es donde se ubican las instrucciones. Desconozco si además también deben tener una sección .data por norma, pero es lo más normal. En esta sección se encuentran los datos -no las instrucciones- que va a usar el programa. Aquí se encuentran cadenas de texto, valores o punteros, por poner ejemplos. La sección .rsrc no es necesaria, pero es donde se guardan los recursos como los iconos y otras cosas. En algunos ejecutables también se encuentra la sección .reloc que, en resumen, mueve el proceso a un lugar de la memoria con suficiente espacio en caso de necesidad, aunque realmente rara vez se utiliza. Estas son unas secciones comunes que no presentan nada sospechoso en sí, pero la sección ENGINE destaca entra las demás. Lo miraremos más adelante.

Y así concluye el análisis automático -aunque hayamos tirado un poco de la VM- del malware. No ha sido para tanto, ¿verdad?

Análisis estático

En este punto, ya tenemos algo de conocimiento del programa, pero podemos saber más, así que vamos a ver que podemos sacar de los ejecutables.

Para ello vamos a necesitar un par de herramientas:

• PEStudio
• Binwalk
• 7-Zip u otro programa que pueda extraer PE. (Yo voy a usar el explorador de archivos de Ubuntu)

Primero convendría mirarlo con Binwalk para ver si encuentra alguna cosa inesperada, para después extraer los PE (Portable Executable, es decir, un .exe) y repetir el proceso hasta que no quede nada que extraer, aunque esa es mi metodología.

• 

reshi@reshi-virtual-machine:~/Desktop/Analysis/Test1$ ls -lA
total 28
-rw-rw-r-- 1 reshi reshi     0 ene 28  2007 .data
drwx------ 4 reshi reshi  4096 dic 21 18:18 .rsrc
-rw-rw-r-- 1 reshi reshi 24576 ene 28  2007 .text
reshi@reshi-virtual-machine:~/Desktop/Analysis/Test1$ binwalk .*

Scan Time:     2021-12-21 18:30:57
Target File:   /home/reshi/Desktop/Analysis/Test1/.data
MD5 Checksum:  d41d8cd98f00b204e9800998ecf8427e
Signatures:    391

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------


Scan Time:     2021-12-21 18:30:57
Target File:   /home/reshi/Desktop/Analysis/Test1/.text
MD5 Checksum:  8629c4b289f860744a407eb9df917b90
Signatures:    391

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

reshi@reshi-virtual-machine:~/Desktop/Analysis/Test1$ 

Nótese que a la hora de englobar todos los archivos usando el wildcard he escrito un punto justo delante. Esto es porque los nombres de las secciones empiezan por un punto se tratan como archivos ocultos en Unix y derivados. Usando el punto especificamos a binwalk que coja los archivos ocultos.

Vemos que no encuentra nada especial. Sin embargo, yendo a la carpeta .rscr podemos encontrar un set de iconos de lo más curioso:

• 

Tiene sentido si nos acordamos de que suplanta las carpetas. Parecen ser iconos de Windows XP, si creo recordar. Esto es un indicio de que el sistema objetivo de esta pieza de malware era Windows XP.

Repetimos el mismo proceso con el otro archivo:

reshi@reshi-virtual-machine:~/Desktop/Analysis/Test2$ ll
total 1164
drwxrwxr-x  3 reshi reshi    4096 dic 21 19:45 ./
drwxrwxr-x  6 reshi reshi    4096 dic 21 19:45 ../
-rw-rw-r--  1 reshi reshi   28672 may 11  1999 .data
-rw-rw-r--  1 reshi reshi   53248 may 11  1999 ENGINE
-rw-rw-r--  1 reshi reshi   65536 may 11  1999 .reloc
drwx------ 11 reshi reshi    4096 dic 21 19:45 .rsrc/
-rw-rw-r--  1 reshi reshi 1032192 may 11  1999 .text
reshi@reshi-virtual-machine:~/Desktop/Analysis/Test2$ 

En este caso vemos que además presenta secciones que no habíamos visto, como ENGINE. En VirusTotal sí que aparece, así que merece ser visto en profundidad cuando nos pongamos con el reversing. Vamos a mirar qué hay en la carpeta .rsrc:

• 

reshi@reshi-virtual-machine:~/Desktop/Analysis/Test2/.rsrc$ file * */*
ACCELERATOR:        directory
BITMAP:             directory
CURSOR:             directory
DIALOG:             directory
GROUP_CURSOR:       directory
GROUP_ICON:         directory
ICON:               directory
MESSAGETABLE:       directory
string.txt:         data
TYPELIB:            directory
ACCELERATOR/1000:   data
BITMAP/26567.bmp:   PC bitmap, Windows 3.x format, 80 x 48 x 4, image size 1920, cbSize 2038, bits offset 118
BITMAP/6800.bmp:    PC bitmap, Windows 3.x format, 44 x 11 x 4, image size 264, cbSize 382, bits offset 118
BITMAP/7000.bmp:    PC bitmap, Windows 3.x format, 128 x 13 x 4, image size 832, cbSize 950, bits offset 118
BITMAP/7001.bmp:    PC bitmap, Windows 3.x format, 128 x 13 x 1, image size 208, cbSize 270, bits offset 62
BITMAP/8100.bmp:    PC bitmap, Windows 3.x format, 11 x 13 x 1, image size 52, cbSize 114, bits offset 62
BITMAP/8101.bmp:    PC bitmap, Windows 3.x format, 8 x 13 x 1, image size 52, cbSize 114, bits offset 62
BITMAP/8102.bmp:    PC bitmap, Windows 3.x format, 8 x 13 x 1, image size 52, cbSize 114, bits offset 62
BITMAP/8103.bmp:    PC bitmap, Windows 3.x format, 11 x 13 x 1, image size 52, cbSize 114, bits offset 62
CURSOR/12:          AmigaOS bitmap font
DIALOG/4018:        data
DIALOG/4019:        data
DIALOG/4031:        data
DIALOG/DUMMYPARENT: data
GROUP_CURSOR/1101:  Lotus unknown worksheet or configuration, revision 0x1
GROUP_ICON/1201:    data
ICON/1.ico:         MS Windows icon resource - 1 icon, 48x48
ICON/2.ico:         MS Windows icon resource - 1 icon, 32x32
ICON/3.ico:         MS Windows icon resource - 1 icon, 24x24
ICON/6.ico:         MS Windows icon resource - 1 icon, 16x16
MESSAGETABLE/1:     data
TYPELIB/1:          data
TYPELIB/3:          data

Podemos acelerar el proceso de ir archivo por archivo manualmente usando wildcards. De esta forma, con * miramos todos los archivos presentes y con */* profundizamos otro directorio más. Vemos muchas cosas, pero en realidad nada de eso capta nuestra atención, salvo las carpetas BITMAP y ICON:

• 

• 

Las imágenes del directorio ICONS ya sabemos que son las carpetas de WinXP, pero las otras no las reconozco. A simple vista pueden sugerir un Windows 95, pero fijándonos más arriba podemos ver que tienen formato de Windows 3:

• 

• 

Es extraño que un malware supuestamente del 2007 tenga dependencias de otro archivo potencialmente diseñado para trabajar con versiones anteriores de Windows, pero por ahora no podemos tirar mucho más del hilo.

Como última etapa del análisis estático manual que estamos haciendo, siempre recomiendo hacer un hexdump con binwalk utilizando como mapa un análisis de entropía. La entropía es, según Google, una “magnitud termodinámica que indica el grado de desorden molecular de un sistema“. Dicho en español, una medida del desorden.

Binwalk trae consigo una característica para generar gráficos de entropía, y vamos a utilizarlo con los comandos siguientes:

binwalk -W Thumbs.com # hace hexdump del archivo
binwalk -E Thumbs.com # genera una grafica con el nivel de entropia

• 

Con esta gráfica podemos guiarnos un poco mejor por un hexdump. Unos valores por encima de 0.8 pueden indicar compresión o encriptación, mientras que valores más bajos como el 0.6 (en este caso) representan casi el nivel del texto escrito humanamente legible.

Hay bastante variación en la gráfica, pero si nos fijamos en las zonas de offset 15000 hasta casi el 25000 vemos unos niveles bastante estables justo después de una pequeña bajada. Vamos a mirarlo en el hexdump:

• 

• 

Podemos ver que -como esperábamos- hay claves del registro a las que accede. Además, vemos un texto un tanto peculiar que está separado por bytes nulos (00) que se utilizan, por ejemplo en C, para indicar el final de una cadena de texto. Esto puede evitar que herramientas como strings o incluso expresiones regulares no detecten el texto, por eso antes no apareció. Una manera de evitar esto es usar cat en vez de strings. Puede ser algo más confuso de ver en algunos tramos, pero ayuda enormemente muchas veces:

• 

Podemos ver varias líneas del texto que ya hemos visto, pero que empiezan por “Echo“. Al ser un comando del terminal comunmente utilizado en scripts, es probable que tenga ese script embebido y que lo extraiga durante la ejecución.

• 

Un poco más arriba, vemos un nombre de un archivo Autoexec.bat junto a la instrucción para scripts @Echo Off. Autoexec.bat es un nombre de archivo que, al ser colocado en la raíz del sistema, ejecuta sus contenidos con el arranque del sistema. La instrucción @Echo Off simplemente evita que se impriman por consola los comandos ejecutados, pero sí se muestra el output. Ya conocemos que -probablemente- vaya a escribir algunos archivos como el Autoexec.bat. Más tarde lo veremos con más detalle.

Además, podemos ver que dice algo de “Surabaya in my birthday […]“, así que podemos buscarlo en internet para más información:

• 

Ahora podemos repetir el proceso con el otro archivo:

• 

• 

• 

Con este archivo es más complicado encontrar coincidencias con internet. He realizado varias búsquedas, pero ninguna parecía corresponder exactamente a este archivo.

Ahora -por fin- vamos a continuar con un análisis algo más visual usando la herramienta PEStudio, que ya mencioné antes. PEStudio analiza propiedades estáticas como las cadenas de texto, las funciones y más elementos y nos lo muestra, además, indicando si es una función o propiedad peligrosa.

Abrimos PEStudio desde nuestra VM e importamos el archivo Thumbs.com:

• 

Podemos ver una gran variedad de pestañas dentro de PEStudio. PS (PEStudio, no PowerShell en este caso) nos ayuda a valorar si una aplicación es maliciosa o no. Aquello que hace pensar a PS que un archivo es malicioso se indica en la pestaña “indicators”, pero puedes encontrar más en el resto de pestañas. Aquellos valores que están naranja significan que PS piensa que podrían ser indicios, y los que son rojos son indicios claros.

• 

Podemos ver bastantes de sus propiedades, como que hace referencia a strings que están en la lista negra de PS, también llamada blacklist. También se encarga de subirlo a VT para su evaluación y de examinar otros valores que no tienen por qué ser maliciosos. También nos indica que puede auto-modificarse en sus secciones ejecutables, así que es algo a tener en cuenta para el reversing.

• 

En la pestaña sections podemos ver que la sección .data está completamente vacía. Además, podemos ver el entry point del programa. Podemos ver que la sección .rsrc es ejecutable y escribible.

Con un vistazo rápido a la izda. podemos ver que no tiene ninguna función y que 5 recursos, vamos a verlos

• 

Los recursos que tiene son lo que esperábamos, todo correcto. Pero ahora vamos a echar un vistazo a las strings que tanto preocupan a PS:

• 

Aquí se puede apreciar mucho mejor el script que va embebido, y podemos extraerlo con son seguridad:

:: Dentro de: Thumbs.com
:: Archivo: Autoexec.bat

:: Evita que se vean los comandos ejecutados
@Echo Off

:: Imprime el texto raro
Echo 81u3f4nt45y - 24.01.2007
Echo Don't kill me, i'm just send message from your computer
Echo Terima kasih telah menemaniku walaupun hanya sesaat, tapi bagiku sangat berarti
Echo Maafkan jika kebahagiaan yang kuminta adalah teman sepanjang hidupku
Echo Seharusnya aku mengerti bahwa keberadaanku bukanlah disisimu, hanyalah lamunan dalam sesal
Echo Untuk kekasih yang tak kan pernah kumiliki 3r1k1m0

:: Para el programa sin cerrar la ventana
pause

He puesto los comentarios en negrita. Hasta ahora ya hemos podido extraer un archivo con relativa facilidad. Por sí solo no es un ejecutable malicioso, ya que solo imprime cosas por consola.

Más abajo podemos ver que hace referencia a varios nombres de archivos:

unicode   12,0x00002454   file   Thumbs   .db
unicode   11,0x00002670   file   Autorun.inf
unicode   12,0x00002C34   file   Autoexec.bat

• 

Si bajamos un poco más veremos algunos elementos que pertenecen a la blacklist del programa. Esto es útil para ver qué capacidades tiene el programa. Podemos ordenar de manera descendente usando esa propiedad para ver qué cosas puede hacer:

• 

Ahora, ya podemos intuir qué cosas hace el programa. Si no se sabe lo que hace una función, recomiendo buscarla en la documentación de Microsoft. ProcCallEngine aparece indexado por Google en la documentación de Microsoft, pero al entrar nos daremos cuenta de que no está. Investigando un poco nos daremos cuenta de que es el motor que se encarga de interpretar el P-Code, que es un IL del lenguaje VB. La string “Startup” puede indicar que ejecuta algo al iniciar el dispositivo. Ahora tenemos algunos detalles más sobre este módulo del malware:

• Ejecuta comandos de consola
• Modifica el registro
• Busca archivos
• Reacciona al arrancar el dispositivo

Ahora miramos el otro archivo en busca de más información:

• 

• 

• 

• 

De este archivo sabemos que es más avanzado. Ha sido detectado por menos antivirus, lo que puede indicar algunos métodos de evasión de AV. Vemos que también accede a la librería de criptografía, por lo que puede presentar algunos datos encriptados. También vemos que las stamps están marcadas en amarillo, lo cuál quiere decir que PS lo reconoce como datos sospechosos. Notamos que -según PS- el programa tiene algunos comportamientos y capacidades característicos de ransomware. Vemos la sección ENGINE, que es bastante sospechosa. Después de mirar en internet, no he conseguido identificar de manera concluyente ese recurso, y lo dejaré para el reversing. El DLL está escrito y compilado en Visual C++. Es un DLL para arquitectura x86/32-bits y, leyendo sus funciones, localizamos las siguientes capacidades y comportamientos (Nota: Control total = Máximo control con los permisos del usuario actual):

• Lockear y unlockear archivos
• Control total de los archivos
• Control total de la hora y las franjas horarias
• Control total sobre los hilos y procesos
• Control total sobre el registro
• Control total sobre las variables de entorno
• Control total sobre el portapapeles
• …

En resumen, tiene comportamiento tanto de spyware, de backdoor e incluso de ransomware. Tiende a registrar las acciones del usuario, pero no sabemos que hace exactamente con esa información. En las strings no encontramos ninguna que se parezca a una dirección IPv4 ni IPv6. Como es una gran cantidad de texto y de valores, podemos mirar online en busca de expresiones regulares para buscar direcciones IP en los dos archivos. Yo voy a usar las siguientes regex -cortesía de StackOverflow– que buscan direcciones IPv4 e IPv6:

# Regex IPv4
^((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)(\.(?!$)|$)){4}$

# Regex IPv6
(([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:)|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}|::(ffff(:0{1,4}){0,1}:){0,1}((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9]))

Estas regex son algo complejas, pero funcionarán de maravilla para comprobar lo que queremos. Para usar las regex, podemos ir a regex101:

• 

• 

• 

Podemos ver que en el PE no hay mucho que ver, pero la regex ha encontrado algo en el DLL. Veamos qué es:

• 

Vemos que no son resultados concluyentes, sino falsos positivos. Aún así, todavía nos queda buscar dominios en los dos ejecutables. Buscamos alguna regex en internet y la ponemos en la web. Yo voy a usar la siguiente:

(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z0-9][a-z0-9-]{0,61}[a-z0-9]

• 

• 

Podemos ver que, a pesar de que hay una buena cantidad de coincidencias, todas son falsos positivos.

También podemos simplemente filtrarlo por el tipo de valor, aunque en ocasiones puede cometer errores:

• 

No aparece ninguna dirección IP ni ningún dominio. En ocasiones, pueden estar ocultas o encriptadas en alguna parte del programa, así que lo dejaremos para más adelante.

Ya hemos hecho un análisis estático con mayor profundidad y hemos podido determinar qué hace este programa, pero aún hay muchas dudas que resolver. Ahora, sabemos lo siguiente sobre los archivos:

Thumbs.com:

• Ejecuta comandos de consola
• Modifica el registro
• Busca archivos
• Reacciona al arrancar el dispositivo
• Carga Thumbs .db como un DLL

Thumbs .db:

• Lockear y unlockear archivos
• Trabaja con archivos
• Accede a la hora y las franjas horarias
• Requeire acceso sobre los hilos y procesos
• Accede al registro
• Necesita acceso a las variables de entorno
• Controla el portapapeles del usuario
• Probablemente instala un keylogger
• Trata de evadir AV

Pero aún ignoramos cuál es el propósito de un programa tan complejo si no se comunica con ningún C2.

Análisis dinámico

Ahora, vamos a continuar con el análisis dinámico. Esto consiste en registrar las acciones de los ejecutables y exportarlos para su posterior análisis. La tarea se puede realizar fácilmente haciendo uso de ciertas herramientas:

• Process Monitor (Procmon)
• ProcDOT
• Graphviz (dependencia de ProcDOT)

Procmon se encarga de registrar todos los eventos del sistema como accesos al registro o a archivos. También está atento de nuevos procesos, hilos, conexiones a internet… ProcDOT se encarga de sintetizar un diagrama de gran utilidad usando Graphviz, y así poder ver con más detalle sus acciones y el orden en que se realizan.

Para que ProcDOT funcione correctamente, es necesario configurar algunas cosas a la hora de exportar el contenido desde Procmon.

En esta etapa vamos a estar ejecutando el malware y desahaciendo esos cambios, así que recomiendo un software de virtualización con la capacidad de realizar snapshots. Para este propósito, recomiendo VMWare, ya que es más flexible a la hora de configurar el entorno.

Una vez configurada nuestra máquina de Windows 7 y preparados los archivos, podemos abrir la carpeta en la que tengamos el malware:

• 

Vemos que en efecto las anteriores carpetas han sido suplantadas. Yo tengo las extensiones habilitadas, pero por defecto no se mostrarían. Si habilitamos la vista de archivos ocultos, podremos ver los archivos originales:

• 

Antes de tocar nada más, vamos a la carpeta de ProcDOT para ver cómo hay que configurar Procmon:

Important steps to follow
=========================

You need to adjust Procmon's configuration (actually for each Procmon installation you want to be compatible to ProcDOT) to match ProcDOT's needs.
Therefore, in Procmon ...
* disable (uncheck) "Show Resolved Network Addresses" (Options)
* disable (uncheck) "Enable Advanced Output" (Filter)
* adjust the displayed columns (Options > Select Columns ...)
  * to not show the "Sequence" column
  * to show the "Thread ID" column

Furthermore ProcDOT needs to know where its third party tools are located.
Hence, in ProcDOT ...
* choose your Windump/Tcpdump (windump.exe/tcpdump)) executable as fully qualified path (ProcDOT options)
* choose your Dot executable (dot.exe) as fully qualified path (ProcDOT options)

Es importante configurar bien Procmon antes de exportarlo porque puede ser incompatible con ProcDOT. Abrimos Procmon y paramos el registro de las acciones dándole al rectángulo:

Y después hacemos clic en la papelera para eliminar todo el registro previo.

• 

Ahora, volveremos a activarlo y detonaremos el malware haciendo doble clic sobre una de esas carpetas falsas:

• 

Vemos que se ha creado el archivo Autoexec.bat que vimos antes, ahora podemos ir a verificar si lo extrajimos correctamente. Además, abre la carpeta que correspondía. Después de dejar el malware corriendo por unos segundos, podemos parar Procmon. Una vez parado, podemos entrar a los filtros para intentar eliminar la mayor cantidad de output innecesario que ha registrado Procmon.

Sabemos, que todas las piezas del malware son de 32-bits, así que podemos filtrar a sólo procesos de 32-bits

• 

Filtramos algunos procesos más como Explorer.EXE u otros procesos y comprobamos que todo esté como queremos de filtrado. Entonces, podemos exportar los resultados como un archivo de Procmon, por si cometemos algún error poderlo volver a abrir:

• 

Ahora, podemos configurarlo para exportarlo al formato que admite ProcDOT siguiendo las instrucciones de más arriba, y lo exportamos como CSV:

• 

Ahora, lo que hay que hacer, es repetir el proceso pero con el arranque del equipo. Es bastante sencillo de hacer con Procmon. Lo volvemos a arrancar y vamos a Options>Enable Boot Logging

• 

Ahora, reiniciamos el sistema

• 

• 

Después de reiniciar el sistema, arrancamos Procmon y nos muestra una ventana diciendo si queremos guardar el bootlog, aceptamos y exportamos los logs a la carpeta de Procmon. Una vez exportado, nos muestra el bootlog y podremos exportarlo como un CSV después de configurarlo apropiadamente. Nótese que aún puede guardar la configuración anterior, así que debemos deshacer los filtros que nostros añadimos. Esto es porque no conzco en profundidad el proceso de arranque de Windows y esos filtros pueden hacer que perdamos resultados. Después, sí que podemos seleccionar manualmente qué procesos filtrar. Una vez acabado, exportamos y cerramos Procmon. Ahora, podemos sacar los resultados de la VM con cuidado o simplemente usar ProcDOT dentro de la VM.

ProcDOT necesita, además de esa configuración a la hora de exportar, un motor para renderizar el diagrama. Ese motor se llama Graphviz. Es una dependencia que debe ser instalada y configurada dentro de ProcDOT para poder funcionar correctamente.

Yo voy a extraer los archivos de la VM con precaución y ponerlos en una carpeta controlada. Además, voy a descargar ProcDOT y Graphviz en mi sistema principal. Una vez esté todo descargado, instalaremos Graphviz si es necesario y abriremos ProcDOT.

• 

• 

• 

Mientras carga, podemos fijarnos en por qué le cuesta tanto, y es algo normal:

• 

Al registrar tantas acciones, habitualmente los archivos se llenan mucho y hacen que su tamaño aumente considerablemente.

Una vez termina de analizar los logs de Procmon, nos salta la siguiente ventana:

Aquí podemos ver 3 cosas relevantes. El fichero falso que ejecutamos y dos procesos que no deberían estar ahí. Debemos seleccionar el primer proceso relevante que conozcamos, siendo en este caso System Volume Information .scr. Hacemos doble clic para seleccionarlo, y le damos al botón “Refresh” para renderizarlo.

Al terminar de renderizar, se nos muestra por fin un bastante poco visible diagrama:

• 

Podemos seleccionar varias cosas para verlo mejor. Abajo a la izquierda, nos permite ver paso a paso cada evento registrado por el proceso. Abajo a la derecha tenemos un botón para alternar qué se muestra. Podemos seleccionar que se muestren los eventos una sola vez, así evitamos mostrar todo el ruido que producen rutinas del programa. También podemos seleccionar la opción compressed para “comprimir” los accesos al registro. Una vez lo tengamos como queremos, bastará con darle al mismo botón que antes para renderizarlo todo de nuevo.

• 

• 

• 

• 

Ha creado los archivos Adobe Online.com y Adobe update.com, que son los que vimos antes. Por suerte, sus acciones no fueron filtradas y podemos observarlo con detenimiento también.

Además, crea otro archivo Thumbs .db.

• 

Después, crea el proceso Adobe update.com y carga su archivo correspondiente en él.

• 

Este hilo no parece tener un padre asignado por ProcDOT, pero eso es imposible. Vamos a salirnos de la vista de frames, ya que en ocasiones puede causar este tipo de problemas.

• 

Vemos que el hilo pertenece al proceso Adobe update.com. Volvemos a la vista general de lo que hace el proceso principal.

Ya sabemos que primero crea los archivos C:\Users\IEUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Adobe Online.com y C:\Users\IEUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Adobe update.com., pero más adelante también copia los archivos Thumbs .db y Thumbs.com a C:\

• 

Vamos a ir realizando un diagrama nosotros para simplificar el proceso:

• 

Lo he dividido en 3 categorías y no he tenido en cuenta el registro a la hora de hacerlo. Se explica por sí solo, pero voy a detallarlo un poco ahora. La parte de la izquierda habla de comportamientos más concretos que no entran dentro de las otras dos categorías. El apartado del medio es una vista reamificada de los procesos que se crean al detonar el malware, así como otros subprocesos creados por él y los archivos que cargan. En la parte de la derecha he especificado los archivos que se crean dividiéndolo en directorios.

Nótese que este diagrama no tiene en cuenta los procesos a la hora de arrancar el programa ni el registro de Windows. Ahora, veremos con más detalles qué es lo que hace en el registro. Para verlo mejor que con un diagrama, podemos abrir el archivo de Procmon y filtrar los resultados. Después, abrimos el CSV con ProcDOT y buscamos claves de registro relevantes:

• 

Vemos que existen varias claves en HKCR\scrfile. Estas claves son las que indican a Windows como abrir archivos del tipo especificado, es decir, scrfile. Dentro de la misma raíz del registro, podemos encontrar la clave “.scr” con el valor “scrfile”. Esto es lo que le dice a Windows que los archivos “.scr” son del tipo “scrfile”, por lo que mira en la clave “scrfile” para saber como tratarlos. Así, puede alterar el registro para que los archivos con extensión “scr” sean ejecutados por consola, como se ve especificado en el registro de la máquina infectada:

• 

Leyendo los valores con detenimiento, nos llama la atención el valor NeverShowExt. Si buscamos en la documentación de Microsoft, nos lleva a la siguiente página. Ésta documentación es de Windows 2000, y si bajamos un poco podemos ver algunas capturas de pantalla de lo más interesantes:

• 

Aquí, podemos ver que los iconos de las carpetas coinciden con los iconos que vienen en el DLL:

• 

Esto significa que el malware -por lo menos el DLL- está diseñado por lo menos para Windows 2000.

Volviendo al tema y según la documentación de Microsoft, la clave “NeverShowExt” impide que el archivo se muestre en el Start Menu de Windows, pero requiere reiniciar el sistema para que los cambios se hagan efectivos.

Las claves FriendlyTypeName y (Default) cambian la descripción de los archivos “.scr” para que que sea “File Folder” en vez de un salvapantallas, aunque contradictoriamente la clave “(Default)” deja de ser funcional a partir de Windows 2000. Si miramos el valor de la clave “FriendlyTypeName” y lo buscamos en el registro, acabaremos en “HKEY_USERS.DEFAULT\Software\Classes\Local Settings\MuiCache\2D\52C64B7E“:

• 

Y podemos ver que tiene el valor “Screen saver”, que es el que aparece en la descripción del explorador de Windows:

• 

Volviendo a mirar el registro del programa, nos topamos con TileInfo, cuya función es mostrar una descripción debajo del archivo en la vista de mosaico del explorador de archivos:

• 

En general, estas subclaves son solo requerimientos decorativos, pero hay más que eso en las claves children a esta. Sin embargo, después de comprobar las claves en ProcDOT no podremos encontrar algo de importancia. Ahora, ya sabemos que el malware edita el registro para tratar los archivos “.scr” como ejecutables de consola.

Ahora que ya sabemos su comportamiento tras la detonación, es hora de comprobar qué hace tras el reinicio del sistema. Para ello abriremos con ProcDOT el archivo que recogimos antes con Procmon y seleccionamos primero el proceso “Adobe Online.com” de la lista de procesos que aparece.

• 

Vemos que simplemente modifica el registro con las claves de antes, con la única diferencia de que crea el archivo “C:\Windows\SysWOW64\Autoexec.bat“. Lo abrimos para ver su contenido:

• 

No es algo que no hayamos visto, y podemos plantearnos más tarde el por qué se escribió ese archivo a la hora de arrancar.

Si comprobamos qué hace el archivo “Adobe update.com”, nos daremos cuenta de que no hace nada que no hayamos visto:

• 

El PID de los procesos no está en rojo en el diagrama de ProcDOT, lo que quiere decir que los procesos no se han detenido mientras Procmon estaba registrando las acciones y, por lo tanto, el proceso sigue ejecutándose normalmente en el sistema operativo.

Conclusión

Habiendo pasado por todas las fases del análisis de malware –excepto el reversing, que será para otro post– ya tenemos el conocimiento suficiente para determinar si una aplicación es maliciosa o simplemente es detectada por el AV. Gracias a toda la información que hemos ido recogiendo sobre el programa, podemos terminar el diagrama de este espécimen de malware:

• 

El análisis de malware es una habilidad vital para aquellos encargados de defender los sistemas y para los que trabajen con programas potencialmente maliciosos. Aprender de análisis de malware es un proceso intenso, demandante mentalmente y psicológicamente recompensante, además de ayudar a comprender cómo funcionan muchas piezas básicas del sistema Windows y a leer con atención y paciencia la documentación necesaria.

Beltrán Rivera Arias