Ataques de DLL sideloading o Hijacking

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?

ara entender lo que es una DLL y la función que cumple vamos a prestar atención a su nombre: Biblioteca de Enlace Dinámico. Si programas en algún lenguaje compilado, como los de la familia del lenguaje de programación C, sabrás que una biblioteca no es otra cosa que un archivo que contiene código (como un conjunto de funciones) ya compilado y listo para ser usado en nuestros propios desarrollos.

Esto nos permite reutilizar código optimizado, testado y bien documentado para ahorramos trabajo y no “reinventar la rueda” como se suele decir. Para hacer uso de una biblioteca, un programa llamado "linker" tiene que enlazar (o vincular) esa biblioteca con nuestro código. Este enlace puede hacerse de dos formas distintas: de forma estática (Static Linking) o de forma dinámica (Dinamic Linking).

 

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. 

¿Qué es el secuestro de DLL o DLL Hijacking?

Llegados a este punto podemos definir el DLL Hijacking como el abuso de esta búsqueda sistemática de Windows mediante la detección de permisos mal configurados en los directorios en los que se buscan las DLLs. El objetivo de un ataque de DLL Hijacking es aprovechar permisos de escritura en uno de estos directorios para depositar en él una DLL con el mismo nombre que la DLL legítima pero que contenga código malicioso. 

De esta manera el sistema encontrará y cargará esa DLL antes que la DLL legítima que se pretendía cargar. El código malicioso que se introduce en la DLL suele tener el objetivo de elevar privilegios en el sistema, si el proceso que carga esa DLL se ejecuta con privilegios altos, o de generar persistencia si es un proceso que se ejecuta frecuentemente o al iniciarse el sistema.

En esencia, estas bibliotecas se cargan en un espacio propio de la memoria del sistema y pueden ser accedidas por uno o varios procesos en tiempo de ejecución. Siguiendo con el ejemplo anterior; esos diez procesos harían uso de una misma biblioteca compartida que se ha cargado una sola vez en una partición de la memoria. En la figura anterior se ve más claramente las diferencias entre estas dos formas de vinculación:

Aunque el concepto es siempre el mismo, se puede hablar de diferentes variantes o técnicas de DLL Hijacking. Al buscar información sobre este ataque es probable que te encuentres con términos como DLL Sideload o Phantom DLL Hijacking:

• DLL Sideload: Cuando se cuenta con permisos de escritura en un directorio que aparece en el orden de búsqueda antes que el directorio donde se encuentra el DLL legítimo. En ese directorio se pondrá la DLL maliciosa.

• Phantom DLL Hijacking: Cuando el DLL no se encuentra en ninguno de los directorios donde se busca y se tienen permisos de escritura en alguno de estos directorios, por lo que se depositará la DLL maliciosa ahí.

DLL SideLoading

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).

En resumen, este ataque abusará del orden de búsqueda de DLL que tienen un binario, posicionando la carga maliciosa al lado uno del otro.

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