Avances en la cadena de entrega: creación de scripts con Nietzsche

Autores:

• Jozsef Gegeny, investigador de seguridad sénior
• Norbert Biro, investigador de seguridad sénior
• Robert Neumann, responsable de Acronis TRU Labs

El papel que desempeñan las cadenas de entrega ha ido cobrando cada vez más importancia en la última década. Los ciberdelincuentes han pasado de realizar una simple entrega mediante un archivo adjunto malicioso en un correo electrónico o una descarga desapercibida a realizar múltiples pasos intermedios hasta lograr desplegar su carga útil definitiva. Estos pasos adicionales se diseñaron para eludir las soluciones de seguridad desplegadas y garantizar la entrega de la carga útil, no obstante, debido a su complejidad, en ocasiones innecesaria, también plantean riesgos adicionales. Al igual que las cadenas tradicionales, si se rompe algún "eslabón", se pierde la continuidad para siempre.

Recientemente hemos detectado una cadena de entrega compleja que utiliza varios lenguajes de scripting con el objetivo final de desplegar familias de malware de alto perfil, como DCRat, de código abierto, o Rhadamanthys, un malware de tipo "infostealer" que se utiliza para robar información.

Nuestra investigación comenzó al recibir un mensaje de correo electrónico con un archivo adjunto en forma de archivo comprimido RAR. El archivo comprimido —como cabía esperar— no contenía ningún contenido legítimo, sino un archivo de Visual Basic Script (VBS) llamado "Citación por embargo de cuenta". El nombre del archivo sugería que el objetivo del ataque era de algún país de habla hispana. Se trataba de un aviso legal relacionado con el embargo o bloqueo de una cuenta bancaria debido a una deuda u otras obligaciones financieras. La intención era evidente: quien recibiera el mensaje no debería dudar en abrir el archivo adjunto de inmediato, lo que provocaría que se ejecutara una cadena de entrega maliciosa.

En este caso, el archivo VBS malicioso empleaba droppers anidados, un tipo de troyano que instala malware en el sistema de la víctima, y que a su vez contiene otros droppers en su interior que van instalando malware uno tras otro, lo que da lugar a un proceso de entrega en varias fases. Hemos dividido nuestro análisis en cuatro fases distintas, tal y como se ilustra en la figura siguiente:

El script de Visual Basic tiene un tamaño de unos 200 KB, lo que indica que no se trata de un simple script de automatización elaborado por alguien sin experiencia. Si observamos con más detenimiento, también se hace evidente de inmediato que estamos ante un caso de ofuscación. El tamaño del archivo, bastante inusual, se debe en parte a la ofuscación, como se demostrará en un análisis posterior. También contiene una carga útil codificada, que se extraerá en la Fase 3.

Hay distintas formas de abordar la ofuscación: se puede desofuscar manualmente (es decir, revertir la ofuscación), aprovechar el soporte de AMSI de Microsoft, o bien simplemente ignorarla si somos capaces de capturar la carga útil definitiva cuando la ejecución llegue a esa fase. En Acronis, creemos firmemente en un enfoque de seguridad multicapa en lo que respecta a la detección de amenazas. Por lo tanto, preferimos neutralizar el contenido malicioso antes de su ejecución siempre que sea posible. Además del soporte de AMSI, también utilizamos un emulador de scripts genérico desarrollado internamente, basado en un concepto de Árbol de sintaxis abstracta (AST), para automatizar la desofuscación en escenarios similares.

Después de desofuscarlo, el script se vuelve mucho más fácil de interpretar para las personas. La función principal del script de Virtual Basic (VBS) inicial es generar un archivo de procesamiento por lotes (BAT) de Windows y transferir la ejecución a este. El archivo BAT malicioso se colocará en el directorio del perfil del usuario:

El script de VBS también crea una copia de sí mismo en el mismo directorio:

No es de extrañar que el script procesado por lotes de la segunda fase también emplee la ofuscación, de forma coherente con la capa anterior.

Al ejecutarse, el archivo de procesamiento por lotes construye una cadena codificada en Base64 a partir de numerosas variables de entorno con la ayuda del comando "set". Esta cadena en Base64 representa un script de PowerShell compacto, que se ejecutará mediante el argumento "-command" como si se hubiera escrito en el símbolo del sistema de Windows PowerShell:

Básicamente, descarga los datos de Base64 descodificados que representan un script de PowerShell en el directorio del perfil del usuario, como:

y lo ejecuta con el siguiente comando:

Curiosamente, parece que los ciberdelincuentes no se molestaron en ofuscar esta capa, ya que todo el código se puede leer e interpretar sin problemas:

No obstante, lo verdaderamente curioso es que contenga algunas citas notables como las siguientes:

La mayoría de las citas, si no todas, son de Friedrich Nietzsche, un famoso filósofo alemán. Las comillas se añaden como comentarios en el script de PowerShell y no tienen ninguna finalidad funcional. Se ve que los autores de este ataque de malware podrían ser amantes de la filosofía.

La función principal de este script es localizar el archivo aguwDl.bat de las fases anteriores en el directorio del perfil del usuario, leer la última línea del mismo (que es larguísima), eliminar los bytes de marcador, y finalmente descodificar y cargar la carga útil resultante en la memoria:

La carga útil que se cargó en la memoria es un ejecutable de Windows en formato .NET y pertenece a una familia de troyanos de acceso remoto muy popular llamada DCRat.

La carga útil se empaqueta con un compresor .NET personalizado y se ofusca en gran medida. Durante el análisis, identificamos que contiene dos blobs de datos cifrados en su estructura de recursos.

Estos blobs de datos utilizan únicamente un cifrado básico y pueden descifrarse con facilidad mediante una operación XOR byte a byte con la clave 0x78. La decodificación de estos recursos revela dos ejecutables adicionales:

Uno es el ejecutable principal de DCRat y el otro es una biblioteca que proporciona soporte al módulo compresor en la carga y ejecución de la muestra de DCRat directamente en la memoria, sin escribirla en el disco. Esto se consigue mediante una técnica conocida como RunPE, implementada en la biblioteca auxiliar. El binario principal de DCRat está bastante desactualizado, pero sigue siendo capaz de infectar sistemas con la ayuda de métodos de entrega similares.

Las cadenas de entrega utilizadas en las campañas maliciosas evolucionan y se hacen cada vez más complejas constantemente. Los ciberdelincuentes no dejan de buscar nuevas formas de ocultar su carga útil definitiva, incluso si tienen que utilizar otras variantes de familias de malware bien conocidas en el sector de la seguridad desde hace años. Si lo consiguen, incluso los binarios de malware obsoletos podrían ejecutarse sin ningún tipo de intervención que los detenga, a menos que se cuente con una solución de seguridad desplegada que sea capaz de detectarlos en la memoria.

Al mismo tiempo, cuanto más complejas sean estas cadenas de entrega, mayor será el riesgo de infección, y cuantas más fases las compongan, mayor será la posibilidad de interceptar el ataque en alguna de ellas, lo que impediría en última instancia que la carga útil consiga el objetivo previsto por sus creadores.

Al analizar esta campaña, nos encontramos con un par de campañas similares en las que la cadena de infección era idéntica —tal y como se ha descrito en este artículo—, a excepción de la carga útil definitiva, que era diferente. En lugar de desplegar DCRat, los atacantes utilizaron el infostealer Rhadamanthys y otro troyano de acceso remoto muy popular: Remcos.

Las soluciones Acronis Advanced Security + Detección y respuesta ampliadas (XDR) detectaron correctamente los componentes utilizados en la cadena de ataque descrita en este artículo.