Ejemplo práctico y errores cometidos: malware de macro en 2015

El caso presentado no está destinado a describir nada fuera de lo común ni nuevo (no lo es) sino a destripar paso a paso un tipo de ataque que, en teoría y como tantos otros, no debería tener éxito en 2015. Más allá de lo sencillo o no que pueda ser el ataque, veamos uno a uno la cadena de errores, omisiones o aciertos que derivan en que esto sea posible (y rentable para los atacantes) hoy por hoy.

El correo

Correo a la izquierda y página oficial a la derecha

Todo comienza con un correo que a todas luces suena sospechoso para alguien del mundo de la seguridad. Pero para una persona ajena, que se comunique en inglés, puede que no tenga nada de raro. La empresa existe (aunque el correo no, de hecho mirando las cabeceras no hay rastro de su servidor MX). La dirección física de la empresa es la correcta, y adjunta una factura… Probablemente un error, pensará el que lo recibe. ¿Qué daño puede hacer un documento? No oculta extensiones «peligrosas», es un .doc. Teniendo en cuenta el éxito que ha tenido la campaña de Cryptolocker que envía ejecutables directamente, abrir un .doc no tendría por qué «ofrecer demasiada resistencia».

Errores hasta aquí:

• La empresa suplantada no toma ninguna precaución contra la posibilidad de que falsifiquen su dominio. No utiliza registros DKIM o SPF en su dominio. Si lo hiciera, quizás no hubieran podido suplantar su dominio o muy probablemente caería en la bandeja de correo basura.

Extracto de la cabecera del correo donde se ve el SPF y el MTA que envía

• El filtro antispam del servidor que recibe no ha estado muy acertado (aunque lo está habitualmente, en este caso ha fallado llamativamente). Si la empresa hubiera usado DKIM o SPF, quizás hubiera puntuado más alto y nunca hubiera llegado a la bandeja de entrada, aunque la responsabilidad sigue siendo del filtro antispam y de la habilidad del atacante. El filtro tampoco ha detectado el servidor que envía realmente (219.92.57.145) es un MTA malicioso (no parece comprometido).
• Los antivirus no detectan demasiado el documento por firma. Obviamente los resultados de VirusTotal pueden variar en el escritorio, pero quizás no tanto. Además, la tecnología de «macro» ya es algo muy conocido por los motores de las principales soluciones antimalware.

Detección del .doc en VirusTotal en el momento en que fue recibido

El documento

En este caso, un documento Office puede ser peligroso por dos razones.

• Porque aproveche una vulnerabilidad en Office y al abrirla consiga ejecutar código, o…
• …porque contenga macros (como en los 90). Simples scripts que convierten el documento en un ejecutable, a efectos prácticos. Veamos si contiene macros.

Extraer la macro de un documento

Por los fragmentos que vamos viendo y sin entrar en mayor análisis, es una macro (programada con una ofuscación infernal) que no puede hacer nada bueno.

Extracto en el que parece ofuscar y construir una cadena

Parece que descarga un fichero de una URL a local

Extracto de código de la macro en el que se observa código ofuscado

En este punto parece que ejecuta algo

Guiados por las funciones usadas, y de forma muy general, se observa la descarga y ejecución de un fichero (técnica básica). La codificación de las URL es sencilla:

Por tanto, no cuesta deducir que intenta descargar el binario en el temporal del usuario y ejecutarlo.

Errores hasta aquí:

• El binario descargado es solo detectado en VirusTotal (con las mismas salvedades de antes) por Rising, el antivirus chino por excelencia. Además lo hace de forma genérica, por su empaquetamiento más que por lo que pueda o no hacer.
• Afortunadamente, las macros están deshabilitadas por defecto… ¿o no? En Word es muy probable que sí, en Excel no tanto. Debido a que no está popularizado el hecho de firmarlas digitalmente, esto sigue siendo un problema tantos años después de que las macros fueran un grave quebradero de cabeza de seguridad generalizado.
• ¿Por qué se deben ejecutar ficheros en la carpeta temporal? Deshabilitar el permiso de ejecución con NTFS en esa carpeta no es complejo, y puede ahorrar más de un dolor de cabeza.

El binario

El binario descargado finalmente instala un Cridex (o Dridex, según la versión… este es un Dridex) en el sistema y esto es muy peligroso. Es un troyano bancario, conocido. Se conecta al C&C en 74.208.11.204 a través del puerto 8080 y a partir de aquí, al infectado que realice operaciones bancarias desde el Windows con el malware, puede que le roben el dinero físicamente de su cuenta. Además de poder controlar el sistema a voluntad del atacante, por supuesto.

Detección del binario en VirusTotal

Errores hasta aquí:

• Al margen de los errores más «típicos» (antivirus, IDS, cortafuegos, etc), existen páginas que recopilan información sobre los C&C conocidos. Este C&C está «documentado» como tal desde el 8 de diciembre de 2014 en sitios especializados. Y toda la subred en sitios no tan especializados, como por ejemplo Spamhaus. ¿No debería ya estar bloqueado por los administradores?  No es sencillo, pero la labor que hacen los investigadores documentando estos servidores no es trivial, por lo que habría que aprovecharla correctamente. Además de poner en marcha herramientas de prevención, los administradores podrían bloquear automáticamente y añadir en los sistemas de seguridad de las redes, las IPs documentadas de forma temprana.

Descarga del archivo de configuración del Dridex. Curiosamente desde un IIS 8.5

• ¿Por qué no lo han cerrado los operadores de red? ¿Se puede mantener impunemente en un hosting un C&C y un binario durante tantas semanas? Sí, ocurre. Y no necesariamente en las redes «especializadas» o «bulletproof» rusas. Este es solo un ejemplo, pero es bastante común que los C&C no se cierren en semanas.

En resumen, un esquema de ataque típico, de finales de los 90 (no el troyano, que es avanzado, pero sí el vector de infección), observado en 2015 y con los errores más o menos de siempre, exceptuando que las macro están deshabilitadas por defecto en Office. La cadena de errores y mejoras planteadas (aunque incompleta) no hace más que evidenciar en cierta forma cuántos actores son necesarios para mejorar la seguridad global, porque no es posible hacerlo aisladamente, con un solo producto, método, proceso o política. Todos están implicados, desde los administradores de servidores hasta los de red, pasando por los responsables de segmentos de red hasta (por supuesto) los usuarios. El esfuerzo se multiplica cuando tantos deben «ponerse de acuerdo», y los resultados no se aprecian como deberían en un tiempo razonable, aunque ya exista una experiencia acumulada y soluciones concretas en muchos de los campos que abarcan este ataque.

Así que aunque convenga recordarlo, no es sorprendente que este tipo de ataques tenga éxito. Y si estos modelos (relativamente sencillos) siguen funcionando entre una buena proporción de los usuarios y empresas… ¿Qué no se puede llegar a hacer con un mecanismo y planteamiento innovadores y mayores recursos? ¿Cuántos actores deben ponerse de acuerdo cuando el objetivo abarca a más perfiles, si cabe?