Campaña de infección masiva con correos con malware

La semana pasada hubo una infección masiva de malware que se distribuía mediante enlaces en correos electrónicos.

Los enlaces cuando accedías descargaban un ZIP que contenía malware.

El malware en cuestión era HERMES una evolución de Tatanga.

 

Es una práctica habitual el mandar enlaces que contengan malware, así que siempre es una buena práctica no abrir enlaces sospechosos que además provengan de direcciones que no son de confianza.

Información sobre el malware.

Una vez hemos descomprimido el ZIP vemos que hay un ejecutable dentro:

remnux@remnux: ~ $ ll

total 492

-rw-rw-r-- 1 remnux remnux 284160 2012-09-25 18:53 Facturas.Pdf_______________________________________________________________.exe

-rwxrwxr-x 1 remnux remnux 213694 2012-09-28 18:23 Facturas.zip

El archivo tiene extensión .exe pero para que el usuario se sienta confiado de clicar añaden un factor de ingeniería social de añadirle .pdf y _______ para que el usuario no se fije en la última y verdadera extensión.

Analizamos la muestra por ejemplo con peframe para que nos arroje información sobre el sample:

remnux@remnux: ~ $ python peframe/peframe.py --auto Facturas.Pdf_______________________________________________________________.exe 

File Name:    Facturas.Pdf_______________________________________________________________.exe

File Size:       284160 byte

Compile Time:          2012-09-25 10:29:04

DLL:               False

Sections:       12

MD5   hash:  03b9b29ee50218a55259a12647aea070

SHA-1 hash: 634ed95519d4fa38246b71824bd1e249d0a8aad0

None

Anti Debug:  None

File and URL:

FILE:              KERNEL32.dll

FILE:              kernel32.dll

FILE:              ntdll.dll

FILE:              ole32.dll

FILE:              ws2_32.dll

FILE:              KERNEL32.dll

FILE:              msvcrt.dll

URL:               None

Suspicious API Functions:

Func. Name: CreateFileA

Func. Name: GetModuleHandleA

Suspicious API Anti-Debug:

Suspicious Sections:

Sect. Name:   .bss

MD5   hash:  d41d8cd98f00b204e9800998ecf8427e

SHA-1 hash: da39a3ee5e6b4b0d3255bfef95601890afd80709

Sect. Name:   mwsbtdb

MD5   hash:  6e2422ba065f5912a3645f00f463e037

SHA-1 hash: 2960b8dbe2acc3a8f7f1fc247e3c580fbe93da93

LegalCopyright: 

InternalName: 

FileVersion: 

CompanyName: 

LegalTrademarks: 

ProductName: 

ProductVersion: 

FileDescription: 

OriginalFilename: 

Translation: 0x041c 0x04e4

Peframe nos informa de que no contiene funciones anti-DEBUG

El binario es detectado por 28 de los 42 motores de antivirus de Virus Total

Análisis dinámico de la muestra

Para el análisis de la muestra lo haremos en un entorno controlado, es por eso que ejecutaremos la muestra en un entorno virtual y monitorizaremos las conexiones.

Antes de dejar a la muestra salir hacia fuera veremos que peticiones realiza:

root@remnux: ~ # fakedns 

Using default IP address in responses. To over-write, use a command line option

pyminifakeDNS:: dom.query. 60 IN A 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.com.ar. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta:{XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.com.ar. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.com.ar. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.com. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Respuesta: {XXXX}.de. -> 192.168.1.1

Ya vemos que hace peticiones hacia distintos dominios, una vez que ya capturemos todos los dominios con los que el malware intenta conectar ejecutamos la muestra interceptando las peticiones con un proxy para capturar hacia donde exactamente la muestra se quiere conectar. Vemos que al cabo de unos minutos se realiza un POST a un servidor remoto.

Es una práctica habitual en los ciber criminales tanto en la distribución de malware como en la recogida de datos robados el usar sistemas legítimos.

Es decir, vulnerar un servidor y desde ahí hacer la recogida de datos y la distribución de las muestras.

Mirando el servidor donde la muestra se comunicaba con el panel de control, me encontré con toda una sorpresa...

Me encontré el en servidor una shell subida.

En la imagen se ven 3 archivos importantes

• El g.php es a donde el binario se comunicaba con el panel de control
• El sys.php es la shell que han conseguido subir
• El 33.zip era un panel de ZEUS, imagino que para lanzar otra campaña.

Como actúa el malware

Una vez el usuario ha sido infectado, el malware monitoriza hacia que webs navega el usuario. En el caso de que encuentre una de las webs que él tiene marcadas en su configuración inyectará lo siguiente en la web.

Para entender esto, imaginad que el troyano está monitorizando el dominio http://s21sec.com. Cuando navegue hacia allí en la web inyectará 

Para conseguir ver lo que ha inyectado hay que ir hacia esa dirección, es decir:

Es un truco usado por el malware, cuando navegamos hacia esas webs el navegador nos mostrará el código de esos JS inyectados. Naturalmente se encuentran ofuscados.

Aunque el archivo verdaderamente importante era el que hacía la petición AJAX, ya que este es el que servía la inyección en vivo para el robo del usuario y password. En cambio cuando se realizó la petición para servir la inyección en vivo:

La inyección en vivo en este caso no funcionaba :\

Si miramos los otros archivos JS podemos extraer funciones para comprobar versiones de navegador, por ejemplo:

Aunque no pude obtener la inyección en vivo esto es mas o menos lo que se hubiera recibido:

Por último si recordáis el malware enviaba los datos a un archivo PHP en un servidor. Si miramos el archivo para ver lo que contiene:

Como veis el archivo se encuentra ofuscado, después de quitar la ofuscación encontramos una parte importante:

Parece que los datos los envía a un segundo panel.

Una estructura que todos conocemos sería la del troyano que envía los datos a un panel de control y de ahí el malo los recoge.

Esta sería la estructura, pero existe otra que sería la de un troyano envía los datos a un panel y este los envía a un panel de control final. Es imposible para el analista saber que el destino final no es el primer panel de control.

Esta táctica es usada para poder ocultar el destino final de los datos. El fichero g.php que es donde enviaba el troyano los datos se encontraba muy ofuscado. Sus esfuerzos en ofuscar no solo los JS si no además el destino final donde el malware envía los datos. Hace que la labor de analizar la muestra sea mucho mas complicada.