Análisis de los niveles de ofuscación de un malware

Queremos compartir en esta entrada los resultados de una breve investigación que realizamos mi colega y excelente especialista de seguridad informática, el ingeniero Dennis Barrera Perez y yo sobre un malware de la familia Js.Trojan.Rass. Consideramos que el aporte más significativo de este artículo consiste en el análisis y descripción de los niveles de ofuscación de código fuente de los que puede valerse un malware para disimular su verdadero objetivo en el sistema de cómputo víctima. No encontrarás acá un método especializado para analizar desde cero el comportamiento de un malware pero estoy seguro que te sorprenderás y aprenderás, sobre todo si te gusta escribir código elegante basado en buenas prácticas y patrones, a los niveles de “bajezas” que puede llegar un malware para disimular su codificación. Comencemos entonces:

Fase 0. Recibiendo un ataque por correo electrónico.

El viernes pasado recibimos un mensaje como este:

De: Jan Hawkins [mailto:Hawkins.04449@mcim.fr]
Enviado el: viernes, 17 de septiembre de 2016 3:35
Para: ————-
Asunto: request
 
Dear henryraul, as you inquired, here is the invoice from September 2016.
 
Let me know whether it is the correct invoice number you needed or not.

El mensaje traía un archivo adjunto denominado 37ddaf5f4533.zip. Debido a que nuestras relaciones con Francia se limitan solamente a los informativos de la TV y los portales de noticias, no era lógico que tuviéramos una factura emitida a mí nombre o el de Dennis en ese país y mucho menos conocemos a un señor de nombre Jan Hawkins. Por tanto, era evidente el propósito de este mensaje de correo electrónico.

Fase 1. Montando un entorno artesanal para “diseccionar” el malware.

Para minimizar los riesgos de infección, creamos una máquina virtual basada en Debian y nos dispusimos a descompactar el archivo .zip para estudiar el código fuente. La máquina virtual nos permitiría contener y eliminar la infección del malware si este se auto-ejecutaba. Como la mayoría de malware tienen como objetivo el SO MS Windows, era casi seguro que este se comportaría igual y por tanto no iba a encontrar los procesos, registros, bibliotecas y shell que necesitaba para lograr la infección. Si era un malware que atacaba al SO GNU/Linux, pues estaría atacando a una computadora “virtual”.

En este entorno, conectamos un puerto de red virtual, descargamos el archivo adjunto, desconectamos la red y descompactamos el  archivo, obteniendo el código inicial del malware.

Fase 2. Análisis del primer nivel de ofuscación.

El primer nivel de ofuscación estaba compuesto por un archivo con extensión js, con 12 líneas de código, las cuales se muestran en la figura 1. Las líneas 4 y 12 estaban compuestas por directivas de compilación condicionales /*@cc_on y @*/ a las que incluimos un comentario para que Sublime Text  resaltara las líneas intermedias con propósito de documentar esta entrada. Este código fuente lo nombramos “script0”.

1

Figura 1. Código inicial del malware. Nombre del código “script0”.

Para analizar a script0, lo mejor es comenzar desde el final.

  • La última orden en ejecutarse es la función eval() y como parámetro utiliza la variable Tjx (línea 11). El paso siguiente es analizar el contenido de Tjx.
  • Tjx se construye (línea 9) mediante la concatenación de caracteres con el operador +=, tomando siempre el elemento de la posición 1 del arreglo asociado a la propiedad P del objeto WZf y referenciada por el arreglo Gw. El algoritmo es el siguiente:
    1. Recorremos cada elemento (línea 5)  de la variable Gw convertida en un arreglo gracias a la instrucción [“split”](‘-‘); que se encuentra al final de la línea 2 (figura 3).
    2. Cada elemento de Gw se coloca en la variable temporal Ub (línea 8).
    3. Para cada valor de Ub, se busca la propiedad de igual nombre del objeto WZf (Figura 2), utilizando una notación de arreglo [].
    4. Todas las propiedades del objeto WZf tienen asignado un arreglo de dos elementos. El primer elemento siempre es 3 (un farol), el segundo elemento es una función auto-ejecutable de la forma ( function f(){return “\x6b”; })(), la cual tiene como misión devolver solamente ¡un carácter! que se encuentra codificado en hexadecimal en la función f y es la piedra angular de todo el proceso (figura 2).
2

Figura 2. Pasos para la reconstrucción del código fuente. Los cuadrados verdes indican las referencias a propiedades y en azul la referencia al valor final del carácter codificado en hexadecimal.

  • Nótese como la responsabilidad de la variable Gw es contener la información de cómo debe construirse el código salida de script0, mediante un proceso de decodificación implosionada pues el índice de la información es mayor que la información misma.

La figura 3 muestra otra vista de script0, puede apreciarse lo extensa que son las  línea 2 y 7 (ver la columna derecha gris). En colores iguales se detallan algunos índices con sus respectivas funciones descodificadoras. Por ejemplo el índice “ZLu”(naranja), se transforma en el retorno de carro (CR = ASCII 13 =  \x0d) y el índice “Ci”(rojo) se convierte en x (x = ASCII 120 = \x78).

3

Figura 3. Vista global de script0, señalando los índices y las funciones contenidas en arreglos como valores de las propiedades de igual nombre.

Luego de concluida todas las operaciones, la variable Tjx llega a la línea 11 portando un nuevo código fuente, que llamaremos script1, listo para ser ejecutado por la función eval. Sin embargo, este código también está ofuscado en otro nivel:

Fase 3. Análisis del segundo nivel de ofuscación.

El segundo nivel de ofuscación usa y abusa hasta el cansancio de la notación [] de javascript para evaluar y construir el código final que va a ser ejecutado por el intérprete. La notación se utiliza para acceder a las propiedades de un objeto. En javascript, object[“property”] es semejante a representar object.property. La ventaja es que [] recibe una cadena, lo que facilita las operaciones de construcción del código fuente. Para ejemplificarlo tomemos como ejemplo esta línea de código ofuscada de script1:

IVi2.push(String[Sa + Hx + BEs + NSy + DGz](IBx3));

Si analizamos a script1, podemos obtener los valores de las variables Sa, Hx, Bes, NSy y DGz:

  • var Sa = “fro”;
  • var Hx = “mCh”;
  • var BEs = “ar”;
  • var NSy = “Co”;
  • var DGz = “de” + “”;

Sustituimos los valores ->IVi2.push(String[fro + mCh + ar + Co + de](IBx3));

Realizamos la operación de concatenación de las cadenas alfanuméricas obtenemos-> IVi2.push(String[fromCharCode](IBx3));

4

Figura 4. Sección del código fuente generado por script0. Nombre del código “script1”.

Un parseador dinámico simple no encontraría, ni en el código de script0 ni en script1 un indicación de cuál será la operación que finalmente se ejecutaría.

Quizás pensabas que todo quedaba ahí pero no es así. Visualizando el código fuente con Malzilla, podemos detectar otras ofuscaciones sutiles basadas en operaciones matemáticas directas para disimular el parseo y la detección de una regularidad en el código fuente (figura 5):

5

Figura 5. Acciones de ofuscación adicionales visualizadas con Malzilla.

Al concluir el análisis detectamos que el malware trataba de conectarse a dos URL: “bulkreasy.com/7e5a7” y “maggycocoa.net/zi6mrx”. Mediante la plataforma sitecheck.sucuri.net de Sucuri (figuras 6 y 7), pudimos confirmar que los sitios se encontraban en sendas listas negras. El malware usaba estas URL para tratar de bajar la carga útil de ataque (payload).

6

Figura 6. Analizando la URL bulkreasy.com/7e5a7 con Sucuri.

7

Figura 7. Analizando la URL maggycocoa.net/zi6mrx con Sucuri.

A modo de confirmación de esta investigación, transferimos el malware al servicio de análisis en Internet www.reverse.it y nos devolvió un largo reporte que nos confirmó la información que habíamos obtenido y que además nos indicó que este malware pertenece a la familia de los Js.Trojan.Rass (Ransomware-as-a-service), cosa que nos alegró porque el estudio realizado tiene mucha vigencia pues este tipo de ransomware es bastante nuevo. Solo busquen en Google y verán.

La novedad del ransomware provocó que en el mejor de los casos, fuera detectado por un 49% de los antivirus probados por www.reverse.it. Esto nos decía que no era tan simple y común esta combinación de mecanismos de ofuscación y que además, habían riesgos importante de infección a pesar de disponer de un antivirus. Por suerte Kaspersky enseguida lo detectaba cuando analizaba el archivo adjunto del correo electrónico.

Espero que te haya gustado la entrada y te pueda ayudar a fortalecer la seguridad en tu entorno digital. Esta primera colaboración con Dennis augura otros trabajos similares. Tengo la suerte de trabajar con gente muy talentosa y dedicada que están haciendo investigaciones muy interesantes y que poco a poco irán apareciendo en este espacio.

S4lud0s y h4st4 el próx1m0 p0st!!!

Anuncios

3 comentarios en “Análisis de los niveles de ofuscación de un malware

  1. Pingback: Apuntes sobre el Referer spoofing, el Referer spam y otros problemas de seguridad relacionados | Behique Digital

  2. Pingback: Problemas del “pentesting real” según Marek Zmysłowski (III)- Mi Nessus es mejor que el tuyo | Behique Digital

  3. Pingback: ¿Puede enseñarnos algo el ransomware WannaCry? | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s