Hace poco aparecieron noticias sobre ataques a bancos polacos en el sitio de seguridad de Polonia ZaufanaTrzeciaStrona.pl (traducido al inglés aquí). El impacto de los ataques se describió con dramatismo, calificándolo como “el más serio”, y los reportes iniciales fueron confirmados por dos artículos de Symantec y BAE Systems. Las instituciones afectadas son de diversas nacionalidades en todo el mundo y se extienden hasta Latinoamérica, incluyendo a México y Uruguay, con objetivos de alto perfil en el visor de los atacantes.
Hay muchos aspectos interesantes de estos ataques, empezando por sus blancos, pasando por su vector de compromiso y hasta las funcionalidades específicas de los ejecutables maliciosos usados. Si bien los dos primeros ejes ya fueron examinados en detalle, los binarios maliciosos involucrados no recibieron demasiada atención hasta el momento. El propósito de este artículo es brindar detalles técnicos de este malware que por ahora está muy poco documentado.
Canal de distribución
Como menciona el portal de noticias de Polonia, la amenaza se envía con sigilo a través de un ataque watering hole, gracias al cual un sitio de confianza que fue comprometido redirige a una página fraudulenta que esconde un exploit. En el caso de los ataques polacos, el punto de partida era el sitio oficial de Komisja Nadzoru Finansowego (la Autoridad de Supervisión Financiera de Polonia):
Sin embargo, nuestros datos indicaban que el sitio de la autoridad equivalente en México, la Comisión Nacional Bancaria y de Valores, también servía redirecciones maliciosas idénticas; desafortunadamente, la información publicada por servicios de rastreo web o por la propia institución no confirmó ni mencionó esto. Según nuestros registros, las redirecciones venían de esta página del sitio:
Fase 1: Dropper
Si el exploit kit logra la infección de malware deseada, el payload malicioso (una aplicación de consola de 64 bits) se ejecuta en la computadora de la víctima. A diferencia del dropper reportado por BAE Systems, este programa espera uno de tres argumentos: -l, -e, o -a (sección 2 en la siguiente figura). Mientras que el argumento -l tiene el mismo significado, los dos restantes son necesarios para extraer binarios de la siguiente fase desde los recursos (sección 4 en la figura) y para iniciar automáticamente uno de ellos como servicio (sección 5):
En la sección 5 de la figura de arriba, el dropper trata de cambiar la configuración de un servicio de sistema para hacer la carga maliciosa como servicio. El servicio se configura desde el administrador de control de servicios para arrancar automáticamente durante el inicio de sistema; para hacerlo, se necesitan privilegios de administrador.
A diferencia de las fases subsiguientes, en la primera la amenaza no se esconde muy cuidadosamente. Incluso contiene declaraciones detalladas que proveen información sobre el estado de la ejecución (en este caso, relacionadas a la extracción de recursos cifrados; sin embargo, la información de debug como los nombres originales de funciones no está presente).
El dropper emplea una carga de API dinámica en vez de tener funciones de Windows en su tabla de importación, lo cual está muy bien explicado en el reporte de Novetta “Operation Blockbuster” acerca del Lazarus Group, en la página 34. La sección 3 de la figura de arriba muestra un wrapper de esta funcionalidad, que va una librería de sistema tras otra.
Parece que los atacantes denotan la segunda fase como “loader” y la tercera, que contiene la principal función de malware, como “módulo”. El cargador es descifrado, mientras el módulo solo se extrae y ejecuta así como está. Para reducir su visibilidad durante el análisis forense, los archivos toman prestada su hora de creación del shlwapi.dll del sistema. Una característica importante del algoritmo de cifrado utilizado es que es se trata de una cadena de cifrado similar a RC-4 bastante reciente llamada Spritz. Ya hay disponibles implementaciones en C y Python de Spritz, y se corresponden al siguiente código desensamblado del dropper:
Fase 2: Loader
Hay más indicadores de la intención de preservar el bajo perfil de la amenaza. El loader está protegido por un packer comercial llamado Enigma Protector y nos dimos cuenta de que el módulo se almacena cifrado, esperando que el loader lo descifre y libere. Tras examinar más de cerca esta protección, hallamos que se usaba una copia no registrada de Enigma v. 1.31 para 64 bits. Fue tal como esperábamos, ya que creadores de malware con este nivel de capacidad no cometerían un error tan básico como dejar su identidad en riesgo potencial de ser descubierta gracias al uso de una copia debidamente registrada. Sin embargo, no es raro que los criminales se aprovechen de una aplicación filtrada o pirateada si está disponible.
Los atacantes que intentan construir una gran botnet en general no usan packers comerciales porque una buena proporción de los fabricantes anti-malware los detectan en forma genérica. Por lo tanto, restrigen el tamaño potencial de la botnet. Pero en el caso de un ataque dirigido, usar dicha protección tiene ventajas. Una obvia es que la reconstrucción del binario original, es decir, determinar cómo era antes de entrar en el proceso de camuflaje, casi nunca es fácil.
La impresión que a veces queda de que solo las máquinas con Windows de 64 bits pueden ser blanco de esta amenaza está errada, ya que también se extrajo una variante para 32 bits de computadoras de algunas instituciones afectadas. Aunque tiene la misma estructura general, esta última no es una mera recompilación de la primera, sino que tiene ligeras diferencias: las fases de dropper y loader se combinan en una, se usa cifrado RC4 clásico y no Spritz, y la fase módulo se almacena en el registro en vez de en el sistema de archivos. Además, la versión del protector Enigma aplicado es 3.7, con una única licencia de desarrollador, y aparentemente se usó para proteger al binario el 11 de enero de 2017.
Fase 3: Módulo
La tercera y última etapa es el módulo relativamente grande (~730 KB) que contiene las principales funciones del malware: comunicarse con el C&C y recibir órdenes de los operadores. Además, se inyecta a sí mismo en todas las sesiones iniciadas en el sistema Windows comprometido.
La siguiente captura de pantalla muestra ls situación tras cargar el módulo en la herramienta de desensamblado IDA Pro. La barra de arriba muestra varias partes del binario: las secciones de código en azul, y las secciones de datos en gris y amarillo. La diferencia entre las partes azules y celestes es que estas últimas representan el código enlazado estáticamente de las bibliotecas existentes. Además del tiempo de ejecución C habitual, identificamos el enlace de una biblioteca de transferencia de archivos multiprotocolo de código abierto llamada libcurl (versión 7.47.1, publicada el 8 de febrero de 2016), junto con trozos de código de proyectos como OpenSSL y XUnzip. El efecto de colores en la barra no se genera en forma automática: en este caso, tuvimos que marcar explícitamente partes que consideramos como código de biblioteca vinculado e importamos todos los nombres de las funciones. Las secciones en azul más oscuro representan el código escrito por los atacantes.
Hay solo una URL cifrada alojada en el módulo. La comunicación está cifrada, pero no registramos ninguna porque el servidor remoto no respondía al momento del análisis. El módulo soporta bastantes comandos; más que suficientes son de los que lo caracterizan como un Remote Acces Trojan (RAT). El diccionario de comandos es así: “SLEP”, “HIBN”, “DRIV”, “DIR”, “DIRP”, “CHDR”, “RUN”, “RUNX”, “DEL”, “WIPE”, “MOVE”, “FTIM”, “NEWF”, “DOWN”, “ZDWN”, “UPLD”, “PVEW”, “PKIL”, “CMDL”, “DIE”, “GCFG”, “SCFG”, “TCON”, “PEEX”, “PEIN”. Muchos se explican por sí mismos (“SLEP” es similar al inglés “sleep” de “dormir”, “PKIL” es matar un proceso, “UPLD” es exfiltrar información, “DOWN” es descargar, “DEL” es borrar un archivo, etc.). Es posible que las funciones originales de libcurl hayan sido personalizadas para ajustarse a las necesidades de los atacantes. De todas formas, libcurl es un proyecto grande con cientos de contribuyentes, decenas de miles de líneas de código y cientos de opciones. La inspección y el análisis preciso de la conexión están en proceso.
Kits de herramientas similares a Lazarus
Los investigadores de BAE Systems dicen sobre el dropper de 32 bits protegido con Enigma: “Una vez desempaquetado ejecuta una variante conocida de malware, que se envió como parte del kit de herramientas del grupo Lazarus…”. Además, Symantec afirma: “Algunas cadenas de código vistas en el malware utilizado comparten aspectos comunes con el código del malware utilizado por el grupo de amenazas conocido como Lazarus”. También es posible hallar una conexión en el reporte de Novetta, como la ya mencionada carga dinámica de API. Todas estas señales nos llevan a describir las propiedades cruciales de un kit de herramientas parecido a Lazarus de la siguiente manera:
- Malware multifase que se ejecuta en cascada
- La fase inicial es una aplicación de consola que espera al menos un parámetro
- Se cargan WINAPIs en forma dinámica
- Se usa RC4 o similar con una llave larga para el descifrado de la siguiente fase
- Las fases siguientes son librerías enlazadas en forma dinámica que se cargan como servicio con el tipo de arranque SERVICE_AUTO_START (se requieren privilegios de administrador para esta acción)
Nuestros registros muestran actividad de varios malware similares a Lazarus in-the-wild recientemente. Sin embargo, para proveer un panorama más claro del caso, necesitamos tiempo para recolectar más información relevante.
Un descubrimiento extraño
Durante nuestra investigación, encontramos otra muestra interesante que pertenece a la misma familia de malware. Una aplicación de consola esperando cuatro parámetros llamada fdsvc.exe (2), que se ejecuta en cascada (1). Además, descifra la siguiente fase usando RC4 con una llave de 32 bytes (4). No tiene las últimas dos propiedades. Por otro lado, inyecta el payload en todas las sesiones en curso de Windows; el payload tiene libcurl v. 7.49.1 enlazado en forma estática. Lo que hace a esta muestra especialmente interesante es la forma en que la etapa final parsea comandos de los operadores, que usan para ello el idioma ruso con translit, un método de codificación del alfabeto cirílico con letras del latino.
Pero debemos ser cuidadosos con la atribución. El idioma usado podría ser una pista falsa, principalmente porque los creadores de malware usualmente implementan comandos a través de números o atajos en inglés. Tener un comando de doce letras es bastante poco práctico.
Conclusión
Teniendo en cuenta las artimañas en el código, nos aventuramos a decir que esta no es una reutilización de código existente mucho antes de estos ataques a bancos polacos, ni tampoco un proyecto discontinuado y olvidado. De hecho, hemos observado malware que se parece a este ejemplo en las últimas semanas.
Fuente:https://www.welivesecurity.com/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
