Análisis técnico de las fases de Cobalt, la pesadilla para la red interna de un banco

Hace algunos días, un actor relevante del grupo de atacantes conocido como Cobalt/Carbanak (o incluso FIN7 para algunos) fue detenido en Alicante. Este grupo ha estado relacionado con distintas campañas contra instituciones bancarias que han provocado unas pérdidas sustanciosas mediante transferencias y retiradas fraudulentas de efectivo en cajeros automáticos. Vamos a ver algunos detalles técnicos del modus operandi de la última oleada, cómo funciona y algunas ideas sobre cómo mitigar el impacto dado el caso.

El objetivo del grupo es el acceso a la infraestructura de la entidad financiera para conseguir el compromiso de los cajeros automáticos y retirar fraudulentamente de efectivo. Aunque parezca ciencia ficción, se hacen con el control de la red de cajeros hasta el punto de que pueden hacer que a una hora concreta, comience a soltar todo el efectivo que contiene. Basta con que el «mulero» se encuentre en ese momento frente al cajero para que el golpe se haga realidad. Más que en el análisis de la muestra, nos detendremos en los aspectos más interesantes de las fases del ataque.

Este grupo emplea la técnica de «spear-phishing» o phishing dirigido. Se trata fundamentalmente de ingeniería social (requiere la interacción de un empleado) para lograr el compromiso de la red corporativa de la organización financiera. Las víctimas (probablemente seleccionados en una fase previa de inteligencia, en las que recolectan nombres y apellidos de trabajadores y los unen con una estructura conocida al dominio del banco) reciben correos electrónicos con adjuntos maliciosos que suplantan a compañías legítimas y autoridades regulatorias. Puede tratarse de correos muy elaborados, con informes de supuestas actualizaciones, alertas, etc. No son enviados de forma masiva en ningún caso, solo a un selecto conjunto de emails pertenecientes normalmente a un mismo dominio. En esta fase, pretenden pasar especialmente bajo el radar. El correo contiene normalmente un enlace web a un documento, esto es, un archivo con extensión .doc (que en realidad habitualmente es un RTF renombrado) alojado en un dominio comprado para la ocasión.

Se sabe qué correos en anteriores campañas (e incluso las más recientes) están siendo enviados en esta oleada por un sencillo «mailer» creado en PHP. Habitualmente reconocible porque en su cabecera se añadirá el siguiente mensaje:

X-PHP-Originating-Script: 0:alexusMailer_v2.0.php

El consejo: mejorar la barrera perimetral típica anti-spam y anti-malware, realizar un sandboxing inteligente del correo, controlar los buzones de personas con privilegios, conocer qué información se filtra afuera, o incluso incluir la revisión controlada de ciertas cuentas para garantizar una mayor protección.

Si la víctima ejecuta el fichero con Office vulnerable, comienza la infección. El fichero RTF aprovecha varias vulnerabilidades en Office (especialmente CVE-2017-8570, CVE-2017- 8570…. todas muy recientes) y en su ejecución, extrae a su vez varios tipos de ficheros. EXE, DLL, DOC, BAT y SCT (Visual Basic Script). Cada uno tiene una función: inyección en memoria, descarga de otro payload (SCT), borrado de pruebas (BAT) y el DOC es un documento inocuo con información que solo sirve para «distraer» al usuario. De hecho, se llama «decoy.doc». De lo más curioso son las llamadas SCT, que en realidad esconden una llamada asíncrona para descarga y ejecución del ejecutable que de verdad desencadenará la infección (en los casos en los que no los lleven incrustados los propios documentos).

Parte del código de uno de los BAT descargados por el RTF

Otro asunto muy curioso es el hecho de utilizar ficheros .BAT para el «control de flujo» de ejecución. El código es bastante autoexplicativo: la intención es que el fichero block.txt haga de «mutex» para que el usuario no lance dos veces el RTF mientras se descargan los payloads, y así no se comporte de forma errática. El caso es que gracias a esto, es posible crear una especie de vacuna sencilla para esta y quizás otras oleadas. Por ejemplo con este código:

copy /y nul «%TMP%block.txt»
icacls %TMP%block.txt /deny *S-1-1-0:W /T
copy /y nul «%TEMP%block.txt»
icacls %TEMP%block.txt /deny *S-1-1-0:W /T

Es muy simple e inocuo crea un fichero block.txt sin permiso de borrado para nadie. No es lo más elegante e incluso puede ser eludido por el malware, pero como decimos, resulta bastante inocuo.
Los RTF son creados con herramientas que se venden en el mercado negro, en las que se define la vulnerabilidad y los ficheros incrustados, y realizan todo el trabajo de composición. Como dato interesante, no crean un RTF que sea consistente con las especificaciones. Los RTF creados que vienen en el correo tienen esta cabecera.

«{rt «, «{rt » o «{rt1»

Cuando la cabecera debería ser «rtf1». Esto es a causa de esa herramienta de creación de exploits o de inclusión de payloads en RTF. En ella también se usa a veces el dominio test1.ru para estadísticas, pero no tiene función relevante.

El consejo: En esta fase, obviamente lo más interesante es disponer de un sistema completamente actualizado (en especial el Office) y unos usuarios correctamente entrenados. Medidas adicionales de seguridad en profundidad (bastionado de Windows específico, detector de malware, EDR, etc.) también son de ayuda. Filtrado web y una buena política de consumo de IOCs para también usar de forma inteligente los datos que ya se puedan llegar a conocer.

Código ejemplo real de los SCT que puede a llegar a extraer el RTF. En él se observa la descarga de un ejecutable

Los «implantes» se inyectan en el sistema para poder ser controlados de forma remota a través de una llamada a casa. En estos casos, los dominios y comandos utilizados corresponden a herramientas tipo RAT. Los IDS, filtros de proxies, etc. deberían realizar su trabajo.

En estos casos concretos, una vez tienen el control de un sistema cualquiera en la red bancaria interna, los atacantes se adaptan en lo que pueden a su entorno, y su actuación depende de las facilidades que les brinden. Se realiza un (obvio) movimiento lateral por la red buscando algún servidor de control de cajeros automáticos. Para conseguirlo se usarán movimientos laterales estándar (mimikatz, pass the hash, elevación de privilegios en directorio activo…) buscando conexiones hacia estos servidores (por ejemplo, Terminal Server) que les interesan. También, es posible que creen usuarios en varias máquinas para elevar privilegios o pasar desapercibidos de forma más cómoda. Esta fase puede durar semanas.

Una vez localizado el servidor que puede llegar a permitir el control de cajeros, se implantará el «beacon«, en forma de servicio, para poder ser controlado por el atacante. Se trata de una especie de meterpreter para control remoto, que de nuevo, permite el acceso del atacante y realizará, por tanto, conexiones con el exterior que deberían ser detectadas a través de logs, dominios, etc. En realidad, está basado en CobaltStrike, una herramienta comercial para crear este tipo de herramientas de ataque y control remoto. De hecho, hace poco ha aparecido una nueva versión.

El consejo: Una red bien vigilada y segmentada. Correlación adecuada de eventos de seguridad y sobre todo, control de privilegios.

Métodos tradicionales mezclados con sistemas más modernos para conseguir control de alguna máquina interna, y de ahí, a manejar un cajero automático. No es ciencia ficción. Como tampoco lo es la posibilidad de protegerse adecuadamente. Como hemos visto (si no en un punto podría ser en otro) existen numerosos métodos con los que combatir este tipo de amenazas, por muy sofisticadas que parezcan, siempre y cuando se entiende la amenaza y se maneja la información adecuada en cada fase del ataque. Nada extraordinariamente nuevo, realmente, pero sí un grave problema a tener en cuenta.