Campaña “Carbanak” por Gustavo Wajsman

Campaña “Carbanak” por Gustavo Wajsman[1]

En el presente trabajo vamos a dar cuenta en que consistió Carbanak o también llamada “campaña Carbak”, una APT, que atacó principalmente entidades bancarias y financieras. Son un grupo de cibercrimales organizados dado que persiguieron como fin no robar ni alterar datos ni denegar servicios ni otro tipo de ciberdelito mas que encontrar la forma de robarles enormes suma de dineros a entidades de Estados Unidos( aunque oficialment lo niegan) , China, Alemania y Ucrania. Esta campaña no solo tuvo como blanco al sistema financiero sino a particulares tambien.

A finales de 2013 varios bancos, financieras y personas físicas y jurídicas de distintos rubros fueron atacados por un grupo cibercriminal hasta entonces desconocido. Todos estos ataques usaron las mismas tecnicas para lograr alcanzar su fin criminal. Hasta el momento este grupo logro hacerse de un botin de mas de 1 billon de dolares y se cree que parte de el aun sigue operativo.

DESARROLLO

Si bien en principio se lo definio como APT, los expertos coincides en que la unica caracteristica que de le puede endilgar es la persistencia.

Su nombre en principio proviene de puerta trasera Carbanak ya que está basada en Carberp y el nombre del archivo de configuración es «anak.cfg.

Los ciberdelincuentes se infiltaban en las redes de las victimas para lograr accedeer a sus cuentas y robarles millones d edolares y luego los abandonaban. Tambien hacian salir en diferentes cajeros dinero espontaneamente que algun complice retiraba.

Los ciberdelincuentes usaron tecnicas de spear phishing enviándoles emails a sus víctimas que simulaban páginas oficiales.

Lo que hacían los exploits era aprovechar vulnerabilidades del paquete Office 2003, 2007 y 2010.

Lo novedoso de Carbanak fue el cambio de público blanco dado que usualmente se atacaba a personas particulares y esta campaña fue directamente contra los bancos y entidades financieras.

Si bien el primer caso detectado fue en diciembre de 2013, el pico fue a mediados de 2014. Se estima que cada ataque o robo propiamente dicho tomo entre dos a cuatro meses por entidad bancaria o financiera. Esta campaña sigue activa en la actualidad.

El comienzo de Carbanak tuvo lugar en un banco de Ucrania. Ellos se dieron cuenta de que les estaban robando dinero de los cajeros automáticos. En principio se penso que se trataba del malware Tyubkyn. Luego esta hipotesis fue descartada al investigar el disco rigido del cajero automático que si bien no se hallo nada de lo esperado se pudo observar una configuración VPN bastante extraña (la máscara de red estaba configurada en 172.0.0.0).

Al principio los investigadore spensaron que era un malware mas. Pero luego de unos meses un CISO de un banco ruso detecto que se estaban enviando datos desde su controlador de dominio a la República Popular China.

Se encontro el malware y se escribio un script por lotes para eliminar el mismo de la pc infectada y luego se ejecuto el mismo script en todas las computadoras de ese banco ruso. Ese fue el trauma del primer encuentro con el malware carbanak.

Una vez realizada las pericias forenses se determino que todo empezo con un correo electronico de spear phishing que llevaba adjunto un archivo CPL. Este una vez ejecutado el codigo Shell, instala una puerta trasera basada en Carbep. Y a esta puerta trasera es la que hoy llamamos Carbanak.en realidad este diseño fue originalmente concebido para realizar realizado operaciones de espionaje y control remoto. Una vez dentro de la red, los ciberdelincuentes saltan a traves de ella hasta encontrar lo que les interesa: robar dinero de sus victimas.

Las investigaciones demuestran que luego de Ucrania, se traslado a Moscu y las victimas en su mayoria fueron de Europa del Este. Sin embargo luego la empresa que investigo este Malware y las agencias de la ley pudieron determinar que tambien afecto a EEEUU, Alemania y China y que actualmente la banda de cibercriminales se expanden hacia Malasia, Nepal, Kuwait y varias regiones de África, entre otros.

Desde el punto de vista tecnico CARBANAK se trata de una puerta trasera con funciones y capacidades para robar datos y una arquitectura de complemento. Algunas de estas capacidades son: registro de claves, captura de video de escritorio, VNC, captura de formularios HTTP, administración de sistemas de archivos, transferencia de archivos, túnel TCP, proxy HTTP, destrucción de sistema operativo, robo de datos de POS y Outlook y shell inverso.

Veamos en detalle algunas de sus caracteristicas:

Monitoreo de hilos

Opcionalmente, la puerta trasera puede iniciar uno o más subprocesos que realizan un monitoreo continuo para diversos fines, como se describe en la Tabla 1.

Nombre del hiloDescripción
Registrador de clavesRegistra las pulsaciones de teclas para los procesos configurados y las envía al servidor de comando y control (C2).
capturador de formulariosSupervisa el tráfico HTTP en busca de datos del formulario y los envía al servidor C2
monitor de punto de ventaSupervisa los cambios en los registros almacenados en C:\NSB\Coalition\Logs y nsb.pos.client.log y envía datos analizados al servidor C2
monitor PSTBusca recursivamente archivos de tabla de almacenamiento personal (PST) de Outlook recién creados dentro de los directorios de usuarios y los envía al servidor C2.
Monitor de proxy HTTPSupervisa el tráfico HTTP para solicitudes enviadas a servidores proxy HTTP, guarda la dirección del proxy y las credenciales para uso futuro.
Tabla 1: Monitoreo de subprocesos

Comandos

Además de sus capacidades de administración de archivos, esta puerta trasera de robo de datos admite 34 comandos que se pueden recibir desde el servidor C2. Después del descifrado, estos 34 comandos son texto sin formato con parámetros delimitados por espacios, de manera muy similar a una línea de comando. Los nombres de los comandos y parámetros se codifican antes de ser comparados por el binario, lo que dificulta la recuperación de los nombres originales de los comandos y parámetros. La Tabla 2 enumera estos comandos.

Hash de comandoNombre del comandoDescripción
0x0AA37987cargarconfigEjecuta cada comando especificado en el archivo de configuración (consulte la sección Configuración).
0x007AA8A5estadoActualiza el valor del estado (consulte la sección Configuración).
0x007CFABFvideoGrabación de vídeo de escritorio
0x06E533C4descargarDescarga el ejecutable y lo inyecta en un nuevo proceso.
0x00684509ammyHerramienta de administración Ammyy
0x07C6A8A5actualizarActualizaciones propias
0x0B22A5A7 Agregar/actualizar klgconfig (análisis incompleto)
0x0B77F949httpproxyInicia el proxy HTTP
0x07203363KillosHace que la computadora no pueda arrancar limpiando el MBR
0x078B9664reiniciarReinicia el sistema operativo
0x07BC54BCtúnelCrea un túnel de red.
0x07B40571administradorAgrega un nuevo servidor C2 o dirección proxy para el protocolo pseudo-HTTP
0x079C9CC2servidorAgrega un nuevo servidor C2 para protocolo binario personalizado
0x0007C9C2usuarioCrea o elimina una cuenta de usuario de Windows
0x000078B0rdpHabilita RDP concurrente (análisis incompleto)
0x079BAC85seguroAgrega paquete de notificaciones (análisis incompleto)
0x00006ABCdelElimina archivo o servicio
0x0A89AF94iniciocmdAgrega un comando al archivo de configuración (consulte la sección Configuración)
0x079C53BDejecutarmeDescarga el ejecutable y lo inyecta directamente en un nuevo proceso.
0x0F4C3903contraseñas de inicio de sesiónEnviar detalles de cuentas de Windows al servidor C2
0x0BC205E4captura de pantallaToma una captura de pantalla del escritorio y la envía al servidor C2
0x007A2BC0dormirLa puerta trasera duerme hasta la fecha especificada
0x0006BC6CdobleDesconocido
0x04ACAFC3 Subir archivos al servidor C2
0x00007D43vncEjecuta el complemento VNC
0x09C4D055archivo de ejecuciónEjecuta el archivo ejecutable especificado
0x02032914robot asesinoDesinstala la puerta trasera
0x08069613proceso de listaDevuelve la lista de procesos en ejecución al servidor C2
0x073BE023complementosCambiar el protocolo C2 utilizado por los complementos
0x0B0603B4 Descargue y ejecute shellcode desde la dirección especificada
0x0B079F93proceso de matanzaTermina el primer proceso encontrado especificado por nombre
0x00006A34cmdInicia un shell inverso al servidor C2
0x09C573C7enchufe de ejecuciónControl de complementos
0x08CB69DEejecución automáticaPuerta trasera de actualizaciones
Tabla 2: Comandos admitidos

Configuración

Un archivo de configuración reside en un archivo bajo el directorio de instalación de la puerta trasera con la extensión .bin. Contiene comandos en la misma forma que los enumerados en la Tabla 2 que la puerta trasera ejecuta automáticamente cuando se inicia. Estos comandos también se ejecutan cuando se emite el comando loadconfig. Este archivo se puede comparar con un script de inicio para la puerta trasera. El comando de estado establece una variable global que contiene una serie de valores booleanos representados como valores ASCII ‘0’ o ‘1’ y también se agrega al archivo de configuración. Algunos de estos valores indican qué protocolo C2 usar, si se ha instalado la puerta trasera y si el subproceso de monitoreo PST se está ejecutando o no. Aparte del comando de estado, todos los comandos en el archivo de configuración se identifican por el valor decimal de su hash en lugar de su nombre en texto plano. Ciertos comandos, cuando se ejecutan, se agregan a la configuración para que persistan (o formen parte de) los reinicios. Los comandos loadconfig y state se ejecutan durante la inicialización, creando efectivamente el archivo de configuración si no existe y escribiendo el comando state en él.

La Figura 1 y la Figura 2 ilustran algunos archivos de configuración decodificados de muestra que hemos encontrado en nuestras investigaciones.

Figura 1: Archivo de configuración que agrega un nuevo servidor C2 y fuerza a la puerta trasera de robo de datos a usarlo
Figura 2: Archivo de configuración que agrega túneles TCP y graba video de escritorio

Comando y control

CARBANAK se comunica con sus servidores C2 mediante pseudo-HTTP o un protocolo binario personalizado.

Protocolo pseudo-HTTP

Los mensajes para el protocolo pseudo-HTTP están delimitados con el ‘|’ personaje. Un mensaje comienza con una ID de host compuesta mediante la concatenación de un valor hash generado a partir del nombre de host y la dirección MAC de la computadora con una cadena probablemente utilizada como código de campaña. Una vez que se ha formateado el mensaje, se intercala entre dos campos adicionales de cadenas generadas aleatoriamente de caracteres alfabéticos en mayúsculas y minúsculas. En la Figura 3 y la Figura 4, respectivamente, se proporciona un ejemplo de un mensaje de sondeo de comando y una respuesta al comando listprocess.

Figura 3: Ejemplo de mensaje de sondeo de comando
Figura 4: Ejemplo de mensaje de respuesta de comando

Los mensajes se cifran utilizando la implementación RC2 de Microsoft en modo CBC con relleno PKCS#5. Luego, el mensaje cifrado se codifica en Base64, reemplazando todos los caracteres ‘/’ y ‘+’ por ‘.’ y ‘-‘ caracteres, respectivamente. El vector de inicialización (IV) de ocho bytes es una cadena generada aleatoriamente que consta de caracteres alfabéticos en mayúsculas y minúsculas. Se antepone al mensaje cifrado y codificado.

Luego, la carga útil codificada se hace para que parezca un URI al insertar un número aleatorio de caracteres ‘/’ en ubicaciones aleatorias dentro de la carga útil codificada. Luego, el malware agrega una extensión de script (php, bml o cgi) con un número aleatorio de parámetros aleatorios o una extensión de archivo de la siguiente lista sin parámetros: gif, jpg, png, htm, html, php.

Este URI se utiliza luego en una solicitud GET o POST. El cuerpo de la solicitud POST puede contener archivos en formato archivador. En la Figura 5 se muestra un ejemplo de solicitud GET.

Figura 5: Ejemplo de baliza pseudo-HTTP

El protocolo pseudo-HTTP utiliza cualquier proxy descubierto por el hilo de monitoreo del proxy HTTP o agregado por el comando adminka. La puerta trasera también busca configuraciones de proxy para usar en el registro en HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings y para cada perfil en el archivo de configuración de Mozilla Firefox en %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js.

Protocolo binario personalizado

La Figura 6 describe la estructura del protocolo binario personalizado del malware. Si un mensaje tiene más de 150 bytes, se comprime con un algoritmo no identificado. Si un mensaje tiene más de 4096 bytes, se divide en fragmentos comprimidos. Este protocolo ha sufrido varios cambios a lo largo de los años, y cada versión se basa de alguna manera en la versión anterior. Es probable que estos cambios se introdujeran para hacer que las firmas de red existentes fueran ineficaces y dificultar la creación de firmas.

Figura 6: Formato de mensaje de protocolo binario

Versión 1

En la primera versión del protocolo binario, descubrimos que los cuerpos de los mensajes que se almacenan en el campo <chunkData> simplemente se realizan mediante operación XOR con el ID del host. El mensaje inicial no está cifrado y contiene el ID del host.

Versión 2

En lugar de utilizar el ID del host como clave, esta versión utiliza una clave XOR aleatoria de entre 32 y 64 bytes de longitud que se genera para cada sesión. Esta clave se envía en el mensaje inicial.

Versión 3

La versión 3 agrega cifrado a los encabezados. Los primeros 19 bytes de los encabezados de los mensajes (hasta el campo <hdrXORKey2>) se someten a operación XOR con una clave de cinco bytes que se genera aleatoriamente por mensaje y se almacena en el campo <hdrXORKey2>. Si el campo <flag> del encabezado del mensaje es mayor que uno, la clave XOR utilizada para cifrar los cuerpos de los mensajes se repite a la inversa al cifrar y descifrar mensajes.

Versión 4

Esta versión agrega un poco más de complejidad al esquema de cifrado del encabezado. Los encabezados están cifrados XOR con <hdrXORKey1> y <hdrXORKey2> combinados e invertidos.

Versión 5

La versión 5 es el más sofisticado de los protocolos binarios que hemos visto. Se genera una clave de sesión AES de 256 bits y se utiliza para cifrar los encabezados y cuerpos de los mensajes por separado. Inicialmente, la clave se envía al servidor C2 con el mensaje completo y los encabezados cifrados con el algoritmo de intercambio de claves RSA. Todos los mensajes posteriores se cifran con AES en modo CBC. El uso de criptografía de clave pública hace que el descifrado de la clave de sesión no sea factible sin la clave

Evolución

El protocolo binario de CARBANAK ha sufrido varios cambios importantes a lo largo de los años. La Figura 7 ilustra una línea de tiempo aproximada. Puede que no sea del todo exacta pero nos da una idea general de cuándo ocurrieron los cambios. Se ha observado que algunas versiones de esta puerta trasera de robo de datos utilizan versiones obsoletas del protocolo. Esto puede sugerir que varios grupos de operadores estén compilando sus propias versiones de esta puerta trasera de robo de datos de forma independiente.

Figura 7: Cronología de las versiones del protocolo binario

 Apreciacion de situacion

Casi toda la informcion disponible sobre el malware CARBANAK dan cuenta de que el «Grupo Carbanak» estaria detrás de la actividad maliciosa asociada con esta puerta trasera de robo de datos. FireEye iSIGHT Intelligence ha rastreado varias campañas generales independientes que emplean la herramienta CARBANAK y otras puertas traseras asociadas, como DRIFTPIN (también conocido como Toshliph). Con los datos disponibles en este momento, no está claro qué tan interconectadas están estas campañas: si todas están orquestadas directamente por el mismo grupo criminal, o si estas campañas fueron perpetradas por actores poco afiliados que comparten malware y técnicas.

FIN7

En todas las investigaciones de Mandiant hasta la fecha en las que se descubrió la puerta trasera CARBANAK, la actividad se atribuyó al grupo de amenazas FIN7. FIN7 ha estado extremadamente activo contra las industrias hotelera y de restauración de EE. UU. desde mediados de 2015.

FIN7 utiliza CARBANAK como herramienta posterior a la explotación en fases posteriores de una intrusión para consolidar su presencia en una red y mantener el acceso, utilizando con frecuencia el comando de video para monitorear a los usuarios y conocer la red víctima, así como el comando de túnel para conexiones proxy. En porciones aisladas del entorno de la víctima. FIN7 ha utilizado constantemente certificados de firma de código adquiridos legalmente para firmar sus cargas útiles CARBANAK. Finalmente, FIN7 ha aprovechado varias técnicas nuevas que no hemos observado en otras actividades relacionadas con CARBANAK.

Proofpoint informó inicialmente sobre una campaña generalizada dirigida a bancos y organizaciones financieras en todo Estados Unidos y Medio Oriente a principios de 2016. Identificamos varias organizaciones adicionales en estas regiones, así como en el sudeste asiático y el suroeste de Asia, que estaban siendo atacadas por los mismos atacantes.

Este grupo de actividad persistió desde finales de 2014 hasta principios de 2016. En particular, la infraestructura utilizada en esta campaña se superpuso con LAZIOK, NETWIRE y otro malware dirigido a entidades financieras similares en estas regiones.

DRIFTPIN (también conocido como Spy.Agent.ORM y Toshliph) se ha asociado anteriormente con CARBANAK en varias campañas. Lo hemos visto implementado en el phishing inicial por parte de FIN7 en la primera mitad de 2016. Además, a finales de 2015, ESET informó sobre ataques asociados a CARBANAK , detallando una campaña de phishing dirigido a bancos rusos y de Europa del Este que utilizaban DRIFTPIN como carga útil maliciosa. Cyphort Labs también reveló que se habían implementado variantes de DRIFTPIN asociadas con este grupo de actividad a través del kit de explotación RIG colocado en los sitios web de dos bancos ucranianos comprometidos.

FireEye iSIGHT Intelligence observó esta ola de phishing dirigido a una gran variedad de objetivos, incluidas instituciones financieras estadounidenses y empresas asociadas con el comercio y las actividades mineras de Bitcoin. Este grupo de actividad continúa activo hasta el día de hoy, dirigido a entidades similares. Detalles adicionales sobre esta última actividad están disponibles en el Portal MySIGHT de FireEye iSIGHT Intelligence.

Conclusión

Realmente es complejo determinar si existe una sola organización de Carbanak o realemnte como cree el suscripto esta es parte de la Criminalidad Organizada Transnacional y en consecuencia es utilizada por distintas organzaciones criminales y cada una de esta le agrega su propio condimento. Por lo visto al menos algunos de los ciberdelincuentes tienen acceso al codigo fuente dado que este esta encriptado y pueden modificarlo.

Tambien es muy posible que algunos de ellos estén compilando sus propias versiones de la puerta trasera de forma independiente.

El futuro de la cibercriminalidad organizada nos permitira ver con el correr de los tiempos mas campañas de este tipo cada vez mas sofisticadas y con otros modus operandi. Carbanak es solo la punta del iceberg que utilizaran estas organizaciones guiadas solo por el ánimo de lucro o de ganancias materiales. Su caracteristica principal es que son grupos criminales con permanencia en el tiempo, que persiguen fines economicos y que actuam en forma transnacional y anonima con lo cual se les dificultara a las agencias de la ley evitar estas acciones criminales asi como su individualizacion y enjuiciamiento de todos sus miembros.

BIBLIOGRAFÍA:

[1] Maestrando en Relaciones Internacionales (USAL) y candidato al Doctorado de Estudios Internacionales (Universidad Di Tella); egresado de la EDENA y Diplomado en Seguridad Internacional y Defensa (Universidad de Belgrano); Maestrando en Derecho, LLM (Universidad de Londres); experto en Cibercrimen y Ciberseguridad (Universidad Siglo XXI) y Diplomado Universitario en Gestión de la Ciberdefensa (Escuela Superior de las Fuerzas Armadas).