viernes, 8 de enero de 2016

Analizando el archivo: "860C4231.doc"

Para enseñar a analizar un documento ofimático, me suministraron el siguiente documento:

Nombre:                860C4231.doc
MD5:                    E8BD65668D68410ADACEE9463EB1489E

Información sobre el archivo ofimático suministrado.

Al intentar realizar un análisis estático del mismo, me encontré que la herramienta basada en Python que habitualmente utilizo no reconocía el documento como "objeto OLE ", y por lo tanto no podía analizar el documento.

Reporte del fallo suministrado por la herramienta de análisis.

A consecuencia de eso, me plantee abrirlo sin ejecutar las macros para posteriormente volverlo a guardar.

Proceso de guardado tras la apertura sin activar la ejecución de las macros.

Y esta vez, sí pude analizar el documento.

Información suministrada por la herramienta de análisis.

A partir de aquí, personalmente prefiero analizar la lógica que contienen las macros, empezando por la función que se ejecuta nada más abrir este tipo de archivo.  Más concretamente el procedimiento: "AutoOpen", que suele encontrarse en el "stream" de nombre: "ThisDocument"

Procedimiento "AutoOpen" contenido en el stream: "ThisDocument".

NOTA: Es muy habitual encontrarse gran cantidad de código "de relleno", la intención ...  dificultar el análisis. Pero, lo "desarrolladores" de este tipo de documentos no se complican demasiado y tras dos/tres llamadas, podremos encontrar la función que inicia el proceso de "descarga" del verdadero malware.

Tras seguir el proceso de ejecución llegue al procedimiento: Aky1JsRD3md (al  segundo salto tras iniciar el proceso de ejecución), que se encuentra, para dicho documento, en el stream 18

Procedimiento: Aky1JsRD3md

Como en otros códigos ya analizados se pueden ver las funciones: Open, Send y ResponseBody, que nos indica que nos encontramos ante una petición de tipo HTTP, mediante la utilización de un objeto de tipo: XMLHTTP.

NOTA: La sintaxis de la función "Open" de dicho objeto es:

objeto.Open (Metodo, URL,  [Asincrono], [Usuario], [Contraseña]

[] : opcional

Más información: https://msdn.microsoft.com/es-es/library/ms757849(v=vs.85).aspx

Por lo que:

sxcsccccc.BHJKbkds7 = método (GET,POST)
sxcsccccc.BHJKbkds1 = <URL>
sxcsccccc.BHJKbkds4 = "XMLHTTP"

Por lo que tenemos que acudir a la macro: sxcsccccc, y buscar la función/ variable: BHJKbkds1.

Pero en dicha macro NO encuentre nada

Macro sxcsccccc.

Por lo que tuve que buscar en el resto de código vinculado a dicha macro, aunque pude intuir que estaba ante la presencia de un objeto embebido de tipo Frame.

Información sobre el objeto embebido.

Revisando los streams vinculados con dicho objeto, encontré la información que buscaba.


Información de uno de los stream vinculados con el objeto embebido.


Método:                 post
URL:                      179.60.144.21/jasmin/authentication.php

NOTA: Obtuve también información adicional,  que se corresponde con la ubicación donde se almacena el archivo descargado: %TMP%/tsx3.exe

Conclusiones

Estamos ante una nueva manera de ofuscar la información que contiene un lanzador de tipo ofimático.

Para ello utilizaremos un objeto embebido que contendrá la información necesaria para la descarga del verdadero malware.

Adicionalmente, aconsejo bloquear en vuestros sistemas:

Md5:                      E8BD65668D68410ADACEE9463EB1489E
URL:                      179.60.144.21/jasmin/authentication.php

Añadir que la URL NO se encuentra activa.


lunes, 21 de diciembre de 2015

Analizando el archivo: "435323.jpg"

Me debía esta entrada desde hace mucho tiempo.

En un blog sobre malware aparecen dos peticiones realizadas por un lanzador basado en un archivo Excel.

rmansys.ru/utils/inet_id_notify.php
s01.yapfiles.ru/files/1323961/435323.jpg


Siguiendo el primer enlace obtenemos:


Recurso no encontrado en la primera URL

Siguiendo el segundo enlace, obtenemos:

Recurso encontrado en la segunda URL

El recurso ésta vivo, pero no se puede descargar debido a que el navegador reinterpreta la extensión e intenta mostrar el contenido.

Por este motivo se utiliza la herramienta “wget” para obtener el recurso .jpg.

Petición “wget” realizada para obtener el recurso .jpg.

Tras la descarga se comprueba el tipo de archivo (magic number) mediante la visualización de los primeros bytes

Revisión del contenido inicial del archivo.

Nos encontramos ante un archivo PE para sistemas Windows.

Se procede a comprobar si dicho archivo es detectado por AVs, para ello se utiliza la web de VirusTotal.

AVs que detectan el archivo según VirusTotal.

La muestra encontrada es bastante conocida.

Se pasa a analizar el contenido de las distintas secciones del archivo PE, centrándose principalmente en la sección “rsrc”.

Comprobación del tamaño de la sección “.rsrc” del archivo PE.

La sección “.rsrc” de un fichero PE es habitualmente utilizada para embeber archivos que nada tienen que ver con el propio programa, y que a su vez, suelen ser ejecutables

En este caso la sección “.rsrc” ocupa: 2,29 MB ((2407424 (bytes) / 1024) /1024) de 2,34 MB, que es el tamaño total del archivo.

Se procede a comprobar de manera manual la existencia de más archivos ejecutables PE en esta sección. Para ello se utilizará como patrón la cadena: “MZ”, que se corresponde con el “magic number” de los ficheros PE.

Pero para buscar exclusivamente en la sección en la que nos estamos centrando, se debe comprobar  la dirección de inicio y fin de la sección.


En nuestro caso, la sección va desde la dirección: F0000, hasta la dirección: 25B000


Patrón de búsqueda encontrado en la sección “.rsrc”

Se encuentran gran cantidad de coincidencias del patrón de búsqueda como se muestra en la imagen anterior.

Pero quizás lo que más llama la atención es la información que rodea al patrón de búsqueda, ya que parece que nos encontramos con información cifrada o empaquetada.

NOTA: Podríamos estar ante un archivo embebido empaquetado o cifrado, para obstaculizar análisis, que fuera desempaquetado o descifrado por el programa camuflado como archivo “.jpg”

Se procede a seguir revisando el archivo “jpg” de manera estática, con la intención de confirmar nuestra hipótesis.

Se encuentran los siguientes datos:

Información sobre el fichero PE analizado

Es decir, nos hemos encontrado un archivo comprimido y autoextraíble, que anteriormente se llamaba “WExtract.exe”.

Todo lo revisado anteriormente cobrar sentido, aún más cuando le cambiamos la extensión por la de: .exe, y tenemos un fabuloso icono asociado a la extensión para el archivo.



Archivo a análisis con extensión .exe

lunes, 30 de noviembre de 2015

Análisis parcial de "najydfdp.exe"

Mientras se analiza la siguiente muestra de malware:

Nombre:                 najydfdp.exe
MD5:                     24DC349285FE3222630D9019E908F0D1

Nombre y MD5 de la muestra analizada

Se encuentra una funcionalidad muy llamativa de la misma.

Pero para llegar a ella, primero se pondrá en situación.

Cuándo lanzamos la muestra (análisis dinámico básico), se crea un proceso de nombre: “jjprnqwb.exe”, que a su vez, crea dos procesos de nombre: “svchost.exe”.

Árbol de procesos de jjprnqwb.exe

Información sobre el proceso de jjprnqwb.exe

Información sobre el proceso hijo: svchost.exe, con PID 3408


Información sobre el proceso hijo: svchost.exe, con PID 1840


NOTA: Los procesos padres, tanto el: najydfdp.exe, como el: jjprnqwb.exe son eliminados

Imagen final tras lanzar la muestra.

Aquí es donde empieza la funcionalidad comentada.

Lo interesante de estos dos procesos es que “deben” existir los dos a la vez, ya que si uno de los dos “muere”, el otro proceso recupera el proceso “muerto” para mantener la infección.

Para muestra un botón.

Los procesos originales tenían como PID los valores: 1840 y 3408.

Si eliminamos el proceso con PID: 1840, el proceso con PID: 3408, vuelve a lanzar el ejecutable que le ha lanzado a él mismo y que a su vez, volverá a lanzar el ejecutable: svchost.exe con otro PID distinto.


Secuencia tras eliminarse el proceso con PID: 1840

Lo mismo ocurriría si el otro proceso fuera eliminado (se elimina el proceso con PID: 3408).


Secuencia tras eliminarse el proceso con PID: 3408

Conclusiones

Nos encontramos con un control de la infección, es decir, un sistema que no permite que el proceso infeccioso pueda ser detenido de manera sencilla.

Anexo

En la segunda secuencia se puede ver la ejecución del archivo: anxmghqx.exe. Este archivo reside en la carpeta: Documents and Settings/<usuario>/Configuración local/Datos de programa/rkjavehh/

Tal información se obtiene gracias a que en el proceso de infección se ha modificado el registro de Windows para incluir en la secuencia de arranque la ejecución del archivo antes mencionado.

Ubicación del archivo: anxghqx.exe


Secuencia de arranque configurada en el Registro de Windows

Aunque no sólo nos encontramos esto, sino que otro archivo se ha configurado dentro de la secuencia de arranque, tal y como se puede apreciar en la foto anterior.

El nuevo archivo es: jjprnqwb.exe, y la ubicación en la reside: Documents and Settings/<usuario>/Configuración local/Temp

Ubicación del archivo: jjprnqwb.exe

NOTA ADICIONAL:

Comparando todos los archivos encontrados, incluso el archivo qswhllov.exe encontrado en la misma ubicación que el archivo “jjprnqwb.exe”.

TODOS SON EL MISMO.



Comparación de MD5s

jueves, 19 de noviembre de 2015

Una espina clavada con los documentos ofimáticos

Desde hace tiempo quería investigar un poco más sobre los documentos ofimáticas que no son utilizados como lanzadores.

Estos tipos no pueden considerarse como malware como tal, ya que  suelen realizar solicitudes de descarga de un ejecutable (malware), para luego, una vez descargado, ejecutarlo dentro del sistema.

DE entre los documentos ofimáticos encontrados que se podría catalogar como NO lanzadores, he seleccionado la siguiente macro como podía haber seleccionado otra. La diferencia no radical en el funcionamiento, sino en los nombres de variables, etc.

Macro del documento ofimático - Parte 1

Macro del documento ofimático - Parte 2

Entre las funciones que nos encontramos en la macro está la copia del documento ofimático origen por dos veces, en la ubicación: $TEMP\, con lo nombres: 322.rtf y 311.rtf.

Creación de los archivos 311.rtf y 322.rtf en la ubicación $TEMP\

Así como  la creación del archivo: $TEMP\pm2.exe, que con posterioridad se ejecuta.

Creación del archivo: $TEMP\pm2.exe y su posterior ejecución.

El contenido de este ejecutable, lo encontraremos dentro del propio documento ofimático.

Más concretamente en este caso, la encontramos en un objeto OLE Nativo de 181.467 bytes.

Estructura del documento ofimático, y en el recuadro rojo el objeto OLE embebido

Si revisamos el contenido del “stream”, nos encontramos con un archivo de tipo PE almacenado sin cifrar, ya que a simple vista se puede ver el “magic number” de estos tipos de archivos. O podemos ver la típica cadena de error que aparece cuando intentamos ejecutar el archivo en un entorno no propicio, o las distintas secciones en que se divide el archivo (text, rdata, data, rscr).

Archivo ejecutable embebido en el documento ofimático

Sin necesidad de ejecutarlo podemos extraer el contenido del ejecutable embebido.

Ejecutable extraído con el nombre: prueba.exe

Se obtiene el MD5 y un análisis estático del mismo, en donde lo que en primer lugar llama la atención es la gran cantidad motores que según VirusTotal detectan el archivo.

MD5 del archivo y los motores que lo detectan según VirusTotal.


Es decir, nos encontramos ante un gran conocido (informe de VirusTotal)

lunes, 16 de noviembre de 2015

El primer ransomware para Linux y su correspondiente herramienta de recuperación

El pasado 6 de noviembre, se hizo público, por parte de Dr. Web,  la existencia de un ransomware desarrollado para servidores Linux, denominado: Linux.Encoder.1 (Descripción técnica).

Hoy leo que Bitdefender ha sacado una herramienta para descifrar los archivos cifrados por este ransomware. Todo es debido a que:

“Linux.Encoder.1 cifra documentos, aplicaciones, código fuente y archivos multimedia utilizando el algoritmo de cifrado AES-128 con una clave que se genera localmente en el dispositivo de la víctima. La clave AES se cifra, a su vez, con una clave RSA para asegurar que los archivos no se pueden recuperar sin pagar el rescate.

Romper el cifrado RSA y AES es casi imposible, y la clave privada RSA necesaria para descifrar la clave AES solamente se almacena en la máquina del atacante. Sin embargo, los investigadores de Bitdefender descubrieron un defecto en la forma en que se genera la clave AES.

En lugar de generar claves aleatorias seguras y vectores de inicialización, la muestra derivaría dos piezas de información de la función rand () de libc generado con la fecha y hora actual del sistema en el momento de cifrado. Esta información puede ser fácilmente recuperada examinado marca de tiempo del archivo ", dijo Bitdefender.

Este es un gran defecto de diseño que permite la recuperación de la clave AES sin tener que descifrar con la clave pública RSA vendido por el operador (s) del troyano".

martes, 10 de noviembre de 2015

Bitdefender crea una "vacuna" contra Crytowall 4.0

He leído en el blog  HackPlayer.com que la firma de antivirus BitDefender a ha sacado una “vacuna” para la última versión de CryptoWall, la 4.0.


Parece que esta versión del Cryptowall, desarrollada en Rusia, no afecta a los usuarios de ese país, ya que dicha versión antes de empezar a realizar las tareas para las que está programado, comprueba si se encuentra activo el teclado en ruso. (Noticia desde BitDefender).

En este sentido, lo que parece hacer la  "vacuna" es: de manera preventiva activa el teclado en lenguaje ruso.

martes, 3 de noviembre de 2015

Análisis del "ticket_11022015-33788993.doc" y demás

Detectado a través de un correo electrónico el siguiente  archivo:

Nombre:                 ticket_11022015-33788993.doc
MD5:                     2F0222A86166A602B14E3DACD556C9D0
VT:                         18/54

Por la macro de dicho archivo, que ya es bastante conocida, al menos su funcionamiento. Se crea un archivo de:

Nombre:                 s1ks.pm2.exe
MD5:                     429eb39728f227ce94404499f8f0963d
VT:                         N/A

Procedimiento detectado en la macro.

Este último archivo, realiza comunicaciones hacía Internet.

Entre las peticiones DNS que se han detectado están los siguientes dominios:

EEXTENSIONS.CO
THETEDRENRE.RU
UNLACCOTHE.RU
WICYTERGO.RU
WWW.10203040.AT
WWW.ESHTARI.ME

Solicitudes de resolución DNS de los dominios detectados al ejecutar: s1ks.pm2.exe

Las URLs detectadas son:

wicytergo.ru/gate.php (peticion POST)
unlaccothe.ru/gate.php (peticion POST)
EEXTENSIONS.CO/gate.php (peticion POST)
THETEDRENRE.RU/gate.php (peticion POST)
WWW.10203040.AT/gate.php (peticion POST)
WWW.ESHTARI.ME/gate.php (peticion POST)

Petición detectada por nuestro servidor fantasma - 1

Petición detectada por nuestro servidor fantasma - 2

Conclusiones

Se debería detectar/bloquear en nuestros sistemas de seguridad los siguientes datos:

Nombre:             ticket_11022015-33788993.doc
MD5:                 2F0222A86166A602B14E3DACD556C9D0
Nombre:             s1ks.pm2.exe
MD5:                 429eb39728f227ce94404499f8f0963d
URLs:                wicytergo.ru/gate.php (peticion POST)
  unlaccothe.ru/gate.php (peticion POST)
  EEXTENSIONS.CO/gate.php (peticion POST)
  THETEDRENRE.RU/gate.php (peticion POST)
  WWW.10203040.AT/gate.php (peticion POST)
  WWW.ESHTARI.ME/gate.php (peticion POST)
Mutex:               local\mtxlog meinig nition.ig nitionmutex