DCRat: el malware que se camufla como Adobe para robar información

Desde el laboratorio de ESET Latinoamérica hemos detectado una amenaza que se propaga por la región, con foco en los países de Colombia y Ecuador. Esta amenaza, la cual afecta a sistemas operativos Windows, es detectada por nuestras soluciones de seguridad como Win32/Loader.Lycaon.AB.

La amenaza intenta camuflarse de aplicación legítima de Adobe, manipulando los metadatos del archivo ejecutable para aparentar legitimidad. Sin embargo, el archivo carece de firma digital válida, lo que confirma su origen fraudulento.

El objetivo es infectar a las víctimas con el troyano DCRat, una variante de AsyncRAT, un software usado en varias campañas de la región. Si bien no se encontraron los métodos de propagación para llegar hasta sus víctimas, se encontró que la cadena de infección inicia con archivos comprimidos que utilizan nombres que aparentan ser comunicaciones judiciales o gubernamentales como, por ejemplo, “Informe Especial Notificado Nro. 113510000548595265844”, lo cual deja pensar que se trata de una propagación a través de correo electrónico.

Este método de propagación de archivos comprimidos con malware vía correos electrónicos de malspam coincide con investigaciones previas en la región, acompañado del uso de temáticas que generan temor o urgencia en la víctima para aumentar la probabilidad de que el destinatario ejecute el archivo malicioso. En la Imagen 1, se observa cómo la amenaza presenta sus campos de metadatos configurados para aparentar ser una aplicación de Adobe.

Sin embargo, no cuenta con firma digital válida ni certificado asociado, lo cual confirma que no se trata de un binario legítimo emitido por la compañía.

A continuación, se detalla el comportamiento de esta amenaza cuando se ejecuta en un entorno que no esté adecuadamente protegido.

El loader

El siguiente análisis fue realizado sobre la muestra SHA1: 758d3c028faaf023c28890f3c4a68cdbce5159e3.

Evasión de defensas

El flujo de ejecución del binario analizado comienza antes del punto de entrada (o Entry Point) declarado en el código, ya que la amenaza tiene registrada una rutina en la tabla de funciones TLS del ejecutable. Esta estructura forma parte del formato PE y es leída por el cargador de Windows al crear el proceso, lo que permite definir una o más funciones (TLS Callbacks) que serán invocadas automáticamente por el sistema antes de transferir el control al Entry Point oficial del binario.

En este caso, la totalidad de la rutina maliciosa se encuentra contenida dentro del TLS Callback. Esta estrategia tiene un propósito anti-análisis, ya que muchos enfoques de ingeniería inversa parten del supuesto de que la lógica maliciosa se inicia en el Entry Point, lo que puede llevar a pasar por alto actividades maliciosas que ocurren en la fase previa de inicialización.

Otra estrategia utilizada por el código malicioso es la resolución dinámica de funciones, particularmente algunas de las pertenecientes a la API de Windows asociadas con la gestión de memoria como VirtualProtect. Tal como se observa en la Imagen 2, el binario construye de manera manual los nombres de las funciones, cargando caracter por caracter en la pila.

Una vez formada la cadena correspondiente, el malware lo utiliza para obtener la dirección real de la función y así llamarla, en lugar de referenciarla directamente en la tabla de imports.

Persistencia

Como puede verse en la Imagen 3, el loader asegura persistencia agregando una entrada en los registros de Windows sobre la ruta HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. Dicha entrada se define con clave la cadena de caracteres “LLFTOOL” y por valor la ruta donde va a estar instalada la amenaza, C:\Users\<USUARIO>\Documents\KCSoftwares\sdk\mdb2db.exe.

El nombre “LLFTool” hace referencia a una herramienta de manejo de discos. Además, la ruta del ejecutable deja ver que los atacantes intentan camuflarlo como un SDK, o una herramienta de desarrollo de software. Ambas técnicas buscan impostar legitimidad en el código malicioso.

En cuanto al contenido del ejecutable, el malware emplea su propio binario que se copia en disco con un tamaño mayor al original debido a la adición de bytes nulos al final. Este padding, si bien no altera la ejecución del binario, deja al archivo con alrededor de 900 MB extras vacíos. Esto podría impactar en su análisis con herramientas automatizadas o entornos tipo sandbox que toman en cuenta el tamaño del archivo o el contenido útil del mismo para identificar comportamientos maliciosos, además de cambiar su hash.

Ejecución

Luego de asegurar la persistencia en el sistema, el loader comienza las operaciones para inyectar y ejecutar la amenaza final. Una de ellas es verificar registros de Windows asociados a la versión actual de .NET del equipo víctima, con el objetivo de seleccionar la ruta adecuada del programa legítimo donde inyectará el payload. Una vez determinado el entorno, procede a desofuscar un shellcode mediante operaciones lógicas simples (como AND u OR), para luego seguir ejecutando su código.

Este shellcode contiene los últimos pasos de la infección, así como el propio payload encriptado en su memoria. En primer lugar, ejecuta una rutina de desofuscación basada en XOR con la clave 851B5D9F635B2774136FF413C55F4440A57C281CC8D6B3E506206FD73A4C839AA1818E8C7D7EB90120C79993133781EB21A6C836F9C20CB8A7D1181A608ACC87, con la cual desencripta el payload en memoria antes de su inyección.

Luego, y gracias a la versión de Microsoft .NET determinada anteriormente, se lanza un proceso en estado suspendido correspondiente al ejecutable en la ruta C:\Windows\Microsoft.Net\Framework\<VERSION_ACTUAL>\csc.exe para luego reemplazar la memoria de este por el código del payload, empleando la técnica Process Hollowing.

Con base en la versión de Microsoft .NET detectada, ejecuta el archivo C:\Windows\Microsoft.Net\Framework\<VERSION_ACTUAL>\csc.exe de esta librería, para luego inyectarle el payload final por medio de la técnica Process Hollowing.

Este ejecutable corresponde al compilador de C# de Microsoft dentro del framework .NET, aunque se han visto otros programas legítimos usados con el mismo objetivo, como el precompilador de ASP.NET, relacionados también a ejecuciones de AsyncRAT.

Una vez que el loader delegó la infección al proceso inyectado, este se autoelimina antes de finalizar su ejecución

DCRat, una variante de AsyncRAT

DCRat, el payload final, es uno de los tantos forks existentes de AsyncRAT y uno de los más propagados mundialmente.

DCRat incluye las funcionalidades típicas de un troyano de acceso remoto, entre las que se destacan:

• Captura de pantalla y webcam
• Registro de teclas (keylogger)
• Administración de archivos y procesos
• Ejecución remota de comandos (CMD/PowerShell)
• Carga y descarga de archivos
• Acceso a credenciales almacenadas (browsers, sistemas)
• Persistencia mediante modificaciones en el registro o carpetas de inicio
• Autoactualización del binario
• Plugins adicionales descargables desde el servidor de Comando y Control

Inicialmente, el código malicioso envía información básica del sistema al servidor C&C, que funciona tanto para identificar a la víctima como para la toma de decisiones por parte de los atacantes sobre ejecución de otras amenazas en el sistema.

La Imagen 4 muestra la lógica utilizada en DCRat para enviar la información básica de la víctima hacia el servidor C&C.

Como característica de AsyncRAT y sus variantes, podemos encontrar las configuraciones iniciales cifradas utilizando AES256 y Base64. Dichas configuraciones en la muestra analizada son:

• Host y puerto: pctrabajonuevo2[.]casacam[.]net:8849
• Protocolo: TCP
• Mutex: DcRatMutex_qwqdanchun
• Llave AES: 4ff06580a02ea318bc7f6f9ed382b62947a700969d6dee30a789e62a1a03ed94

Más allá de modificaciones estructurales, entre las “mejoras” más destacables que ofrece DCRat con respecto a AsyncRAT es el robustecimiento de las capacidades anti-análisis. Esto se refleja en, por ejemplo, la inclusión de una función (verImagen 5) que aborta la ejecución de la amenaza si encuentra procesos relacionados con análisis dinámico de malware o de monitoreo del sistema.

DCRat también implementa otras técnicas de evasión como la desactivación de componentes AMSI así como ETW patching, que funcionan desactivando las funciones de seguridad que detectan y registran comportamientos maliciosos.

Indicadores de compromiso

Hashes

Los hashes de las muestras analizadas y archivos relacionados con la campaña, son:

Registros de Windows

El registro utilizado para la persistencia es:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

• Carpetas y archivos modificados

La muestra crea los siguientes directorios y archivos:

• C:\Users\<NOMBRE_USUARIO> \Documents\KCSoftwares\sdk\
• mdb2db.exe

Indicadores de red

Las URL e IP relacionadas al servidor C&C son:

• pctrabajonuevo2[.]casacam[.]net
• 154[.]216[.]19[.]63

Técnicas MITRE ATT&CK

A continuación, se listan las tácticas, técnicas y procedimientos utilizadas en las muestras analizadas utilizando el framework MITRE ATT&CK.