Últimamente se están identificando numerosas campañas de correos maliciosos con ficheros adjuntos; en especial, con variantes de Cryptolocker o CTB-Locker y demás tipo de ransomware.
En la mayoría de casos se trataba de un archivo ejecutable, con extensión .EXE, directamente incluido en un archivo comprimido ZIP sin contraseña. Entre tanto ejecutable, hace unos días llegó un correo diferente que no contenía un ejecutable sino un archivo VBS. En realidad, se trataba de un archivo con doble extensión (algo muy habitual para engañar al usuario y hacerse pasar por un archivo XLS, en este caso).
El correo venía con el asunto “This is your Remittance Advice [ID:92251]” y un archivo adjunto con el nombre VW3840QVDZ.zip, que contenía un supuesto archivo de hoja de cálculo:
5104afe7f36cd6ba8d0ad13848d1b38c963fbb42ea51532c3b01e21805971c72 VW3840QVDZ.zip f19315d0757362859022e40d7d64a46d5a50227e35d1e10f3c1c7731821ec8ac 8323241AZ#632463.xls.vbs
Evidentemente, este último archivo no se trata de un archivo de Excel, sino un script en Visual Basic con el siguiente contenido:
Se trata de código ofuscado utilizando la función chrw, que convierte números enteros en caracteres, para no mostrar el código original. Además, el entero lo representa como suma de dos números. Al final del código vemos una función que ejecuta el anterior código almacenado en la variable nt:
Desde el punto de vista de un Blue Team, debemos identificar qué realiza este código para tratar de contener el posible incidente de seguridad sin ejecutar el código. Al tratarse de código VisualBasic script, podemos modificar el código para llamar a una función que muestre el contenido de la variable nt, como imprimirla por pantalla o en un archivo, en lugar de ejecutarla. Para esto, vamos a sustituir la última línea por otro código que escriba el valor de nt en un archivo de texto de la siguiente manera:
De esa forma mostramos el código ejecutado por el código en el archivo script.txt, donde vemos que se trata de un dropper de otro archivo sospechoso descargado desde un servidor ubicado en Rusia:
Vemos que el código se trata de una llamada a powershell.exe, para descargarse el recurso casma.gif, descomprimirlo y ejecutarlo. Aquí tenemos el primer elemento de contención: bloquear la dirección IP del servidor desde el que nos descargamos este archivo sospechoso.
Tras conseguir el archivo desde un origen diferente al atacado, podemos analizar el ejecutable.
El archivo parece comunicarse con el servidor 188.120.225.17, también ubicado en Rusia, al que posiblemente le envíe información a través de peticiones POST y otros servidores repartidos por varios países, por lo que tenemos un gran número de direcciones IP a bloquear y contener el posible incidente antes de que se materialice.
Conclusiones
Entre las medidas que tomamos para la contención, hay que bloquear la dirección IP desde la que el dropper descarga el malware para evitar que los usuarios puedan verse comprometidos.
También hay que bloquear la dirección IP <188.120.225.17> para evitar que el malware se comunique con el que es supuestamente el servidor de control o donde se envía la información capturada.
Por último, entre las lecciones aprendidas para evitar que ocurra un incidente similar se encuentra la formación y concienciación al usuario final para no abrir correos sospechosos ni sus adjuntos. No obstante, a nivel técnico tiene una solución bastante sencilla, como bloquear los correos que contengan adjuntos en formato ejecutable (EXE, BAT, VBS, SCR y demás archivos ejecutables).
Precisamente por este tipo de engaños, de la doble extensión, yo suelo recomendar que además de bloquear los ejecutables en el correo, los usuarios quiten la opción de “ocultar extensiones de archivos conocidos”, para que sean conscientes en todo momento del nombre de los archivos que manejan.
¿Qué os parece?
Muy bueno el post, Nelo. Enhorabuena!