Mailextractor.py Alpha– Script para procesamiento de e-mails

Una de las tareas más repetitivas cuando se gestionan incidentes es el análisis de alertas relacionadas con correos electrónicos.

Cuando se recibe un correo, ya sea relacionado con un spear phishing o una alerta de IDS hay ciertas cosas que se deben mirar, ya sea para el análisis del incidente actual, como puede ser en el caso de las cabeceras o ficheros adjuntos, o para un posterior análisis, como determinar los receptores más habituales que aparecen en una campaña dirigida.

Para realizar todo este trabajo que es bastante tedioso, llevaba un tiempo queriendo escribir un script que hiciera la parte de extracción de datos de manera automática, de forma que pudiera tener todos los datos que necesitase poner un informe tan solo copiando y pegando, pudiendo así emplear más tiempo en el análisis de los adjuntos realmente interesantes. He podido sacar algo de tiempo y escribir una primera versión en modo quick and dirty y con pocas funcionalidades añadidas.

Funcionalidades

Como funcionalidad básica está la extracción de los datos de las cabeceras, es decir, remitente, receptores, asunto e identificador del mensaje. Además de estos datos por separado, también se extraen las cabeceras completas, ya que pueden ser necesarias para la investigación y nos permite en un vistazo saber los saltos que ha realizado ese correo para llegar a su destino.

Además de estos datos, es interesante conocer las direcciones IP implicadas en el correo, por lo que el script también las extrae y, por defecto, chequea el historial de dominios que resuelven a esa dirección y que tienen al menos una detección en Virustotal (VT).

Para la revisión de los correos con contenido malicioso se extraen los datos relativos a los archivos adjuntos del correo y los enlaces que se puedan encontrar en el cuerpo del mensaje. Además se comprueban los ficheros extraídos en VT.

En este último caso, únicamente se comprueba el hash del fichero, no se envía nunca el fichero a VT, ya que en ese caso podríamos estar exponiendo información confidencial en el caso de se tratase de un ataque dirigido.

Script

No hay mucho que comentar del script, es bastante simple, aunque empezaron siendo unas 40 líneas y ya va por más de 200 y me gustaría comentar algún detalle.

El primer detalle en el que me quiero parar es en el uso de Virustotal. En las partes del código en la que se llama a las rutinas de análisis de direcciones IP y de archivos adjuntos, se ha puesto un contador que se reinicia al llegar a 4. Esto es para que el script sea usable con la API pública de VT, la cual limita el número de peticiones a un máximo de 4 por minuto.

Por cierto, para que esto funcione necesitáis meter vuestra clave de la API en la variable global VT_API que se encuentra al comienzo del script.

Tened en cuenta que el script es usable pero está en alpha y es posible tanto que falle, como que cambie bastante en las próximas semanas, así que si os interesa permaneced atentos a las actualizaciones en github.

Con la opción -vt se saltan los chequeos en Virustotal.

Aquí os dejo el link del script.

Ejecución

Para lanzar el script basta con ejecutar:

$ python mailextractor.py -f mail.eml

En mi caso lo hago sobre un correo al que luego le he modificado una de las cabeceras para que contenga una IP con detecciones en VT, un fichero que previamente he escaneado en VT y otro que no.
El correo es el siguiente:

Al ejecutar el script nos da los datos del correo:

Las cabeceras, entre las que se incluye la cabecera falsa:

Análisis de las direcciones IP encontradas en las cabeceras:

Se puede ver que en la dirección falsa que he metido salen varios dominios que en algún momento resolvieron a esa dirección IP con algún positivo en Virustotal.

Y por último el análisis de los ficheros adjuntos:

Se ven ficheros: lotus.jpg y mlwre_logo.png. Ambos son imágenes. Subrayado se puede ver que el fichero lotus.jpg ha sido analizado anteriormente en Virustotal y que en el momento del análisis ningún antivirus lo detectó como positivo.

Todo

También os dejo algunas de las ideas que planeo realizar en el script y que no he podido terminar para este post:

  • Limpiar el código.
  • Análisis de todos los correos almacenados en un directorio.
  • Distintos formatos de salida (txt, html, etc).
  • Checkeo de URL y direcciones IP contra blacklist.
  • Opción para el envío de los ficheros a analizar a Virustotal.
  • Muchas ideas para incorporar otros servicios como malwr.com.

Cualquier idea o comentario para mejorarlo es bienvenida, también podéis enviar actualizaciones o errores a través de la página de github.

NOTA: La función para extraer el cuerpo del mensaje a veces falla, estoy trabajando en ella.

NOTA2: Si los análisis de VT fallan a menudo podéis solucionarlo subiendo el tiempo de espera, lo he dejado en 30 segundos para no eternizar la ejecución del script.

Análisis de ataque dirigido – Mirage

Entre los días 25 y 27 de noviembre de 2013, algunas instituciones públicas europeas fueron objetivo de una oleada de ataques dirigidos muy interesante: para los ataques se utilizaba una infraestructura que ya se había usado en el pasado en otras campañas de malware.

Infección
Como en la mayoría de estos ataques, el vector de infección fue una campaña de spearphising. Los correos tenían un documento de MS Word, el cual contenía un exploit embebido que aprovecha una vulnerabilidad conocida desde 2012, en concreto la vulnerabilidad CVE-2012-0158.

El dominio que aparecía en el campo “FROM” de los correos pertenecía a una de las más renombradas organizaciones humanitarias. Esto hace que los correos puedan parecer totalmente legítimos.

Los asuntos en los distintos correos hacían referencia a fechas cercanas a la fecha del ataque, excepto en uno de los correos, en el que se mencionaba el Top 10 de las ciudades con las mujeres más bellas… bastante tentador.

Fw: 2013-11-27
Fw: Top 10 Cities with the Most Beautiful Women
RV: Teheran 2013-11-25

En los nombres de los documentos adjuntos, aparecían las mismas referencias.

27-11-2013.doc
20131125.doc
Top 10 Cities with the Most Beautiful Women.doc

Gracias a las políticas de parcheo y actualización, el impacto del ataque fue nulo, ya que el documento de MS Word aprovecha una vulnerabilidad antigua que afecta a los controles de ActiveX y permite la ejecución de código remoto. Esta vulnerabilidad fue parcheada en abril de 2012.

Hashes
Al calcular los hashes de los ficheros, se comprobó que se trataba de sólo dos documentos diferentes.

1598f39b5d670eb0149141df7bbcc483
60fd6b6bcf73586284ab8c403c043c6e

Al comprobar estos MD5 en Virustotal, se vio que alguien ya los había subido con anterioridad, por lo que desde ese momento se trataron las muestras como información pública.

A continuación, paso a desglosar resumidamente el análisis. No se trata de un análisis completo de las muestras, sino solamente de la información útil que sacamos para dar la respuesta al incidente.

Las siguientes tablas muestran los ficheros descargados por cada uno de los dos documentos:

He marcado en rojo los ficheros que malwr.com considera maliciosos. Aunque estos ficheros compartan nombre, no comparten los hashes. Más adelante veremos por qué.

Aun así, al cruzar las tablas anteriores, sí que se encuentran varios ficheros idénticos:

La recepción de los distintos correos en una ventana de tiempo tan estrecha y la descarga de una serie de ficheros idénticos al abrir el documento indican que, probablemente, ambos ataques estén relacionados.

Si queréis mirar los análisis más en profundidad, los podéis encontrar en malwr.com en los siguientes enlaces:
1598f39b5d670eb0149141df7bbcc483 @ malwr.com
60fd6b6bcf73586284ab8c403c043c6e @ malwr.com

Dominios
Tras la ejecución de los documentos en cuckoo y la infección de una máquina virtual mediante la ejecución manual de los ficheros con nombre “kav.exe”, se vio que cada una de las muestras se conectaba a un dominio distinto:

yahoo.offlinewebpage.com
link.antivirusbar.org 

Esto explica que, aunque el resto del comportamiento sea igual en ambos ficheros, la firma MD5 sea distinta para cada uno de ellos.

Además, gracias a otra información recibida de fuentes externas, se añade también el siguiente dominio:

ks.pluginfacebook.com

Al realizar peticiones a estos dominios, siempre se recibe la misma respuesta:

HTTP/1.0 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/html
Date: Wed, 27 Dec 2013 15:23:45 GMT
Accept-Ranges: bytes
Content-Length: 362
X-Cache: MISS from ta-prx21
X-Cache-Lookup: MISS from ta-prx21:3128
Via: 1.0 ta-prx21 (squid/3.1.20)
Connection: keep-alive

<.h.t.m.l.>.
.
.<.b.o.d.y.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.1."
        .>.U.n.d.e.r. .C.o.n.s.t.r.u.c.t.i.o.n.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.2."
          .>.w.w.w...m.i.c.r.o.s.o.f.t...c.o.m.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<./.b.o.d.y.>.
.
.<./.h.t.m.l.>.
.
.

Al acceder al dominio desde un navegador desactualizado, no se observa ningún comportamiento extraño y la respuesta es la esperada:

Con estos datos, se reafirma la hipótesis de que todo se trata de un mismo ataque.

Atribución
Al hacer whois a los dominios, aparecieron las siguientes direcciones de correo como registradores de dominio:

qingwa20112011[at]163[dot]com
dnsjacks[at]yahoo[dot]com 
usa87654310[at]126[dot]com

Tanto los dominios como las direcciones de e-mail de los registradores de los dominios apuntan a China, como se puede ver en esta lista de e-mails relacionados con ataques dirigidos con origen en China.

Haciendo una búsqueda rápida en Google de los e-mails implicados, se puede ver que la direccióndnsjacks[at]yahoo[dot]com está relacionada con una campaña Mirage, también con origen en China.

Analizando las peticiones vistas en la campaña Mirage y comparándolas con las encontradas en el ataque, se pueden apreciar ciertas similitudes.

Imagen extraída de www.secureworks.com

Petición de una de nuestras muestras.

A simple vista, se ve que utilizan los mismos campos (“hl” y “meta”). Si además añadimos otra de las peticiones de la campaña analizada por Secureworks, también aparece el campo “q”:

Imagen extraída de www.secureworks.com

A continuación, se puede ver una imagen resumiendo los resultados de la investigación de la atribución.

Conclusión
Basándonos en los datos obtenidos durante la investigación, se puede concluir que el ataque venía desde China.

Además, si se analizan los receptores de los correos electrónicos, se ve que no solo iban dirigidos a una organización concreta, sino que se apuntaba a varias instituciones europeas.

Se estaba usando una infraestructura utilizada en campañas anteriores. Esto, unido al envío de correos con una gran cantidad de receptores y a la naturaleza del malware Mirage, hace que el ataque no sea silencioso, lo que hace pensar que trataba de robar algún tipo de información concreta de manera rápida (probablemente información financiera).

Este tipo de ataques es bastante común en instituciones públicas y casi siempre utilizan el spearphising como medio de infección. El uso de dominios de buena reputación, como en este caso el de una organización humanitaria muy conocida, legitima ese correo, por lo que hace muy difícil la detección.

Aun así, la prevención de estos ataques suele ser sencilla y venir de la mano de una rápida aplicación de actualizaciones y parches de seguridad, ya que en la mayoría de estos ataques no se utilizan 0days, sino vulnerabilidades conocidas y ya parcheadas. Por ejemplo, en este caso se utilizó una vulnerabilidad con más de un año de antigüedad.

Para detectar si vuestra organización se ha visto afectada por esta oleada, basta con buscar en los logs de navegación si aparece alguno de los dominios mencionados anteriormente.

Espero que os haya sido de utilidad o por lo menos una lectura interesante.

Comprobación de la reputación Web para gestión de incidentes

A veces cuando nos enfrentamos a un incidente, alrededor de él hay demasiados dominios que comprobar como para hacerlo manualmente. Para poder manejarlos y hacer una discriminación en primera instancia, he desarrollado un pequeño script que comprueba la reputación de cada dominio utilizando la API de Web of Trust.

Web of Trust es un servicio que se usa para marcar páginas web dependiendo de su reputación. La reputación se basa en distintos factores. Uno de ellos depende de la presencia de malware, pero hay otros, como una puntuación basada en los votos de los usuarios.

Una de las cosas que más me gusta de la API de WoT es que devuelve diferentes códigos dependiendo de la razón por la que no tiene una buena reputación. Por ejemplo, si la razón por la que tiene mala reputación es debida a que el sitio contiene material para adultos, devolverá el código 401, mientras que si contiene malware, devolverá 101. Esto viene bien para gestionar algunos incidentes, ya que, en la mayoría de los casos, si un dominio tiene una mala reputación porque es una página para adultos, y sólo por eso, en una primera investigación, se podría dejar como un dominio legítimo.

Para usar el script, sólo necesitáis registraros en WoT, conseguir una clave de la API e introducir la clave en la línea:

WOT_API_KEY = "YOUR_OWN_API_KEY!!!"

Puedes encontrar el script en mi repositorio de Github.

Por último, vamos a probar el script. Para ello, necesitaremos un fichero con la lista de dominios que queremos comprobar. En el ejemplo utilizaremos un fichero que he llamado domains.txt y que contiene los siguientes dominios:

4chan.org
silurian.cn
securityartwork.es
mtgmadness.com

Para lanzar el script solo hay que pasarle el fichero con la lista de dominios a comprobar:

xgusix@ender:~$ python repcrawler.py domains.txt 
[*] mtgmadness.com
	Target: mtgmadness.com
[*] 4chan.org
	Target: 4chan.org
	Trustworthiness: Excellent [59]
	Child safety: Very Poor [53]
	[*] Categories:
		[403] Questionable Gruesome or shocking [14]
		[401] Negative Adult content [73]
		[501] Positive Good site [59]
[*] securityartwork.es
	Trustworthiness: Good [7]
	Target: securityartwork.es
	[*] Categories:
		[501] Positive Good site [7]
[*] silurian.cn
	Target: silurian.cn
	Trustworthiness: Very Poor [12]
	[*] Categories:
		[101] Negative Malware or viruses [30]

Como podéis ver, al comienzo de la investigación, podemos descartar 4chan.org y securityartwork.es, ya que están marcadas como “Good site” y su confianza (Trustworthiness) es por lo menos Good. Mtgmadness.com no está marcado, por lo que tendríamos que continuar con la investigación de estos dominios. En el último caso, silurian.cn, ya está marcada como dominio malintencionado, “Malware or viruses”, por lo que sería un buen punto de partida para la investigación.

Ahora mismo, el script muestra todos los resultados, pero con una modificación muy simple se le puede añadir algo de lógica y automatizar un poco más el proceso. Tengo planeado añadir más motores de reputación al script. Con más fuentes la discriminación será más efectiva y ahorrará tiempo en el proceso de la gestión del incidente.

Los comentarios y valoraciones son bienvenidos.

#badBIOS

Hace dos días, recibí un correo que contenía este enlace. Tras leerlo, estaba un poco asustado, parecía algo serio, especialmente viniendo del creador del concurso pwn2own Dragos Ruiu (@dragosr), ya que él no necesita algo así para hacerse famoso o tener un nombre.

Como no hay demasiada información o un informe “oficial”, aquí os dejo algunos hechos sobre lo que Dragos ha encontrado y su investigación:

  • Encuentra un malware que infecta el hardware.
  • Lo encuentra instalado en portátiles con sistemas Windows instalados, pero se ve que de alguna manera es independiente de la plataforma, puede infectar sistemas BSD y OSx tampoco es inmune.
  • Reescribe la BIOS del sistema y es persistente, incluso tras “flashear” la BIOS con un firmware legítimo, sigue infectando el sistema. Esto obliga al investigador a usar una nueva máquina para cada prueba.
  • Se comunica mediante SDR (Software Defined Radio) para unir air gaps (equipos sin conexión a ninguna red). Funciona incluso si las tarjetas de red inalámbricas y de Bluetooth son extraídas.


    (https://plus.google.com/103470457057356043365/posts/exuXRz5C3L3)
  • Carga un Hypervisor.
  • Cuando se infecta la BIOS, no permite el arranque desde dispositivos externos sin importar la configuración elegida, la mayoría de las veces arranca desde el disco interno.


    (https://twitter.com/dragosr/status/388632113496350721)
  • Reescribe la memoria flash de todos los dispositivos de memoria USB que se conectan a un sistema infectado, incluyendo lectores de CD que se conectan mediante USB. No afecta a los ficheros del dispositivo USB, va directamente al firmware.
  • Insertar un pendrive infectado en un sistema limpio es suficiente para infectarlo… ¡sin siquiera tener que montarlo!

    “I didn’t even mount the volume and it was infected.”

    (https://twitter.com/dragosr/status/393021493149302785)

  • A veces “brickea” las memorias USB al extraerlas de manera no segura, pero vuelven a la vida cuando se introducen en un sistema infectado.


    https://twitter.com/dragosr/status/393026712197279746)
  • En los sistemas Windows infectados aparecen algunos ficheros .ttf y .fon extra. Tres de ellos (meiryo, meiryob, and malgunnb) tienen un tamaño mayor del esperado.
  • Cuando se intentan extraer estos ficheros, desaparecen del CD en el que se han copiado.

  • (https://twitter.com/dragosr/status/393633641370112000)

  • Se apunta a Rusia como origen del malware, ya que son los únicos desarrolladores de software malicioso que modifica los controladores flash. Además, el malware bloquea los dominios rusos que modifican las memorias flash.


    (https://twitter.com/dragosr/status/393023050750234624)
  • Los primeros síntomas se encontraron en un Macbook hace tres años.


    (https://twitter.com/dragosr/status/394223528813146112)
  • Han subido una lista con los md5 de los ficheros a este enlace.

En estos momentos, no sé si se trata de un trolleo épico. Personalmente no creo que Dragos se juegue su reputación así, o si estamos delante de un nuevo tipo de amenaza ante la que tenemos que estar preparados. Lo peor es que, a día de hoy, nadie tiene ni idea del propósito del malware.

Trataré de manteneros al día y os recomiendo que sigáis en Twitter a @dragosr y el hashtag #badBIOS si queréis estar al día sobre el tema.

[NOTA] Si os interesa una muestra, tened un ojo en malware.lu. @xylit0l publicó esto en kernelmode.info:

Re: New Bios Malware
 by Xylitol » Sun Oct 13, 2013 9:23 pm
Talked to r00tbsd over irc, he have an image of the infected bios but got no time 
for the moment to add it on malware.lu.

Fuentes:

[1] https://plus.google.com/103470457057356043365/posts/9fyh5R9v2Ga
[2] https://plus.google.com/103470457057356043365/posts
[3] https://www.wilderssecurity.com/showthread.php?t=354463
[4] https://www.security.nl/posting/366329/Onderzoeker+ontdekt+mysterieuze+BIOS-malware
[5] https://kabelmast.wordpress.com/2013/10/23/badbios-and-lotsa-paranoia-plus-fireworks/
[6] https://twitter.com/dragosr
[7] https://twitter.com/rich_addr
[8] http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2998&p=21195&hilit=BIOS+malware#p21195

YARA 101

¿Qué es YARA?

Cuando se habla de detección de malware existen principalmente tres maneras de determinar si un fichero es dañino o no: firmas, heurística y string signatures.

La más extendida en los sistemas de detección antivirus es la detección en base a firmas, es decir, en base al resultado de calcular el HASH de un fichero, pasarlo por una base de datos de firmas y comprobar si este fichero ha sido detectado anteriormente como malware. Este tipo de firma es inútil para la detección de malware no conocido y para evadirlo basta con recompilar el código en un sistema diferente o cambiarle un solo bit.

Para tratar de parar estos métodos de evasión se utiliza el método heurístico. Este método se basa en el comportamiento del ejecutable y, de acuerdo a las acciones que realiza dentro del sistema, se decide si el fichero es malicioso o no. El principal problema de este método es que puede generar una gran cantidad de falsos positivos ya que muchos programas realizan acciones lícitas que pueden hacer saltar las alertas.

Por último, queda el método que atañe a este artículo, string signatures. Este método se basa en otro tipo de firmas diferente al comentado anteriormente. En lugar de usar firmas tipo HASH, utiliza cadenas de texto o binarias que identifican inequívocamente a un malware. De esta forma aunque se modifique el fichero, si este sigue conteniendo esas cadenas que conforman una firma, los analistas seguirán siendo capaces de detectar y clasificar ese malware.

[Read more…]