Una actividad maliciosa de DLL sideloading que se basa en el escenario clásico de sideloading, pero añade complejidad y capas a su ejecución. Además, la investigación indica que el actor o actores responsables de la amenaza les gusta tanto esta adaptación del escenario original que utilizaron múltiples variaciones del mismo, intercambiando repetidamente un componente concreto en el proceso para eludir la detección en este paso de la cadena de ataque.

¿Qué es una DLL?

 

Enlace estático (Static Linking)

En este caso el "linker" enlaza la biblioteca justo después de compilar nuestro código y como resultado de este enlazamiento se obtiene el ejecutable final. A efectos prácticos se puede entender este proceso como si el "linker" hiciese un “copia y pega” de las funciones de la biblioteca estática directamente a nuestro código.

Esta forma de enlazar una biblioteca tiene sus ventajas y sus inconvenientes. Imagina que en tu sistema están corriendo diez programas que hacen uso de una misma biblioteca. Cada uno de esos programas tendría que haberse compilado y enlazado con la biblioteca, aumentando el peso de cada ejecutable en el disco y el espacio que ocupa el proceso en la memoria. Que cada uno de estos programas cargue la misma biblioteca en memoria es algo que no parece muy eficiente, por esta razón existe el enlace dinámico.

Enlace Dinámico (Dinamic Linking)

Para solucionar esta duplicidad de bibliotecas cargadas en la memoria y obtener ejecutables más ligeros se hace uso de bibliotecas compartidas o de enlace dinámico: las famosas DLLs de Windows o los archivos .so (shared object) que tan importantes son también para la seguridad y la explotación de vulnerabilidades en GNU/Linux. 

Puede verse que uno de los primeros reportes que hablan de la técnica, cuya autoría es atribuida a la analista Amanda Stewart de Fireeye, se remonta al año 2014 (https://www.mandiant.com/sites/default/files/2021-09/rpt-dll-sideloading.pdf)

Aunque parezca una tontería, analizaremos en primer lugar el nombre.

• DLL: Dynamic Link Library. Es una biblioteca de enlace dinámico. Por ahorrar tiempo, les dejo el enlace de la documentación oficial de Microsoft donde se explica el concepto por si es desconocido por el lector (https://learn.microsoft.com/es-es/troubleshoot/windows-client/deployment/dynamic-link-library)
• SideLoading: Side Loading, traducido literalmente como, “cargado de forma lateral” (la verdad es que me he lucido con esta traducción).

Ejemplo DLL Sideloading

Formas anteriores del ataque, ya han sido tratadas anteriormente en el sector, principalmente en los blogs Sinophone CTFIoT y Zhizu. El ataque se basa en un ataque clásico de sideloading, consistente en una aplicación limpia, un cargador malicioso y una carga útil cifrada, con diversas modificaciones de estos componentes a lo largo del tiempo. Las últimas campañas añaden un giro en el que una aplicación limpia de primera fase carga “lateralmente” una segunda aplicación limpia y la autoejecuta. La segunda aplicación limpia carga la DLL del cargador malicioso. Después, la DLL del cargador malicioso ejecuta la carga útil final.

El actor de la amenaza más asociado a este ataque recibe diversos nombres: “Operation Dragon Breath”, “APT-Q-27” o “Golden Eye Dog”, y se cree que está especializado en los juegos de azar online y sus participantes. A estos actores les gustó tanto este escenario de dos aplicaciones limpias que utilizaron múltiples escenarios en los que la aplicación de la segunda etapa se sustituye por otras aplicaciones limpias.

Las campañas originales iban dirigidas a usuarios de Windows de habla china que participaban en juegos de azar online, y los vectores de infección iniciales se distribuyeron a través de Telegram. Hasta la fecha, se han identificado objetivos en Filipinas, Japón, Taiwán, Singapur, Hong Kong y China.

En esta investigación encontramos varias variaciones en el enfoque del doble limpiador-instalador; las variaciones implicaban principalmente cambios precisamente en el programa del que se abusaba en la segunda etapa, con algunos efectos secundarios causados a su vez por esos cambios. Describiremos el código más comúnmente encontrado en cada etapa, tocando las variaciones a medida que avancemos.

El principio: vector de infección

Al principio, la investigación llevó a un sitio web (telegramos[.]org) que ofrece, o dice ofrecer, versiones en chino de la aplicación Telegram para Android, iOS y Windows. 

Este es el sitio desde el que se cree que el usuario afectado descargó el paquete que causó la infección. La forma en que el usuario encontró el sitio por primera vez, ya sea a través de phishing o envenenamiento SEO o algún otro método, está fuera del alcance de esta investigación.

Instalador de primera etapa: Telegram

Como se ha mencionado anteriormente, la investigación inicial de estos ataques implicaba un instalador malicioso de Telegram. Más adelante en este artículo veremos variaciones en las que se utilizaron otras aplicaciones “señuelo”, pero Telegram fue con diferencia el señuelo más común, y diseccionarlo proporciona un buen ejemplo de cómo funciona el ataque.

Se crea un acceso directo en el escritorio. Sin embargo, este acceso directo no ejecuta el programa Telegram, sino un comando inusual:

C:\Users\{redacted}\AppData\Roaming\Tg_B518c1A0Ff8C\appR.exe /s /n /u /i:appR.dat appR.dll

Aquí appR.exe es el componente de Windows regsvr32.exe, con su nuevo nombre. Ejecutará la biblioteca appR.dll, que es otro componente de Windows renombrado, scrobj.dll: el motor de ejecución de scripts. A continuación, ejecutará el código Javascript almacenado en appR.dat:

Cuando se ejecuta el acceso directo, se ejecuta el código JavaScript. Para el usuario, muestra la esperada interfaz de usuario del escritorio de Telegram, principalmente en chino

Pero entre bastidores deja caer varios componentes de carga lateral en un directorio:

El instalador también crea un archivo de acceso directo en el directorio de inicio del usuario. De esta forma, el malware establece la persistencia y permite la ejecución automática tras el inicio del sistema.

Los componentes de carga lateral y el enlace de inicio solo se crean cuando se ejecuta el enlace Telegram del escritorio. Esto podría ser un truco anti análisis, ya que los sandboxes de análisis dinámico no verían los archivos sideloader descartados.

Fuentes:

https://redsquadron.incide.es/dll-sideloading-una-perspectiva-ofensiva-3a00013202f0

https://news.sophos.com/es-es/2023/05/04/un-doble-dragon-breath-da-un-nuevo-aire-a-los-ataques-de-dll-sideloading-1-de-2/

https://www.elladodelmal.com/2021/04/que-es-una-dll-y-en-que-consiste-el-dll.html