ESET descubre y disrumpe parte de la operación de VictoryGate, una botnet compuesta principalmente por equipos comprometidos en Perú y que es utilizada para minar criptomonedas.
Investigadores de ESET descubren una botnet no documentada previamente, a la que han denominado VictoryGate. La misma ha estado activa al menos desde mayo de 2019 y, desde entonces, se han identificado tres variantes de su módulo inicial y apróximadamente 10 payloads que son descargados por el equipo de la víctima desde sitios de file hosting en Internet. El módulo inicial es detectado por los productos de seguridad como MSIL/VictoryGate. A su vez, a través de la colaboración con distintas organizaciones, se ha logrado disminuir en gran medida el control que la misma tiene sobre los dispositivos afectados.
La botnet está compuesta principalmente por dispositivos ubicados en la región de LATAM, principalmente en Perú, país en donde están más del 90% de los dispositivos comprometidos. Realizaron actividades de sinkholing sobre varios subdominios hardcodeados en las muestras que la botnet utiliza como respaldo para su servidor de comando y control (C&C). La combinación de la información recopilada de sinkhole, sumada a su telemetría, les permitió estimar el tamaño de la botnet, la cual está conformada, como mínimo, por 35.000 dispositivos.
VictoryGate utiliza subdominios registrados con el proveedor de servicios de DNS dinámico No-IP, empresa que rápidamente dio de baja los dominios una vez que los mismos fueron reportados por ESET, limitando efectivamente el control de los bots por parte del atacante. Adicionalmente, la información recolectada en el sinkhole es compartida con la organización sin fines de lucro Shadowserver Foundation para alertar a las autoridades locales y operadores de red.
La actividad principal de la botnet ha sido la utilización de los equipos infectados para la minería de la criptomoneda Monero. Sin embargo, dado que el operador tiene la capacidad de actualizar los payloads que la víctima ejecuta en cualquier momento que lo desee, esta funcionalidad podría haber cambiado en cualquier momento. Esto representaba un riesgo considerable, dado que se ha detectado tráfico de red comprometido que se origina desde organizaciones tanto públicas como privadas, incluyendo empresas del sector financiero en Perú.
El impacto en el equipo de la víctima es:
- Elevado uso de recursos de la PC de la víctima. En todas las muestras analizadas, el malware hace uso de todos los hilos disponibles del procesador para realizar criptominería. Esto se traduce en un uso sostenido del CPU del rango de 90-99%. Esto puede causar ralentizamiento del equipo, sobrecalentamiento o incluso dañarlo.
- Los archivos contenidos en dispositivos USB que se conectan a un equipo infectado son escondidos en una carpeta con atributos de sistema en la raíz de la unidad extraíble. Esto significa que algunos usuarios pueden perder acceso a sus archivos originales si no remueven dicho atributo de la carpeta escondida.
En este artículo analizaremos algunos de los detalles técnicos de esta amenaza proporcionado por ESET.
¿Qué es VictoryGate?
Este es el nombre que le damos al módulo inicial de la amenaza, que recibe y ejecuta comandos del servidor de comando y control del atacante. Además, este módulo es el encargado de la propagación de la amenaza a través de medios de almacenamiento USB.
Propagación de la amenaza
El único vector de propagación que hemos podido confirmar durante la investigación es a través de medios extraíbles USB. El mecanismo funciona de la siguiente manera: la víctima recibe un pendrive que en algún momento fue conectado a una PC infectada. A primera vista, contiene todos los archivos originales con sus nombres e íconos correspondientes, sin embargo, los archivos originales fueron reemplazados por ejecutables de Windows, como se observa en la Figura 2. Es fácil para un usuario desprevenido ejecutar uno de estos archivos sin percibir nada inusual.
Cada uno de estos archivos maliciosos son scripts AutoIt que VictoryGate compila “on the fly” utilizando la plantilla que se muestra en la Figura 3. Vale la pena mencionar que a cada uno de estos archivos se les agrega metadatos aleatorios para que el hash resultante nunca sea el mismo.
La ejecución de cualquiera de estos archivos por parte del usuario hará que se ejecute tanto el archivo original que se desea abrir, así como el módulo inicial de la amenaza, ambos escondidos en una carpeta oculta (marcada con atributos de sistema) en la raíz de la unidad de almacenamiento extraíble.
Una vez ejecutado el módulo inicial escondido en el pendrive, el mismo realiza una copia de sí mismo en el directorio %AppData% en el sistema de archivos del equipo de la víctima, modificando su nombre para aparentar ser un archivo de Windows legítimo como “ctfmon2.exe”. Además, crea un acceso directo, que apunta a dicha copia, en la carpeta de inicio de Windows como un mecanismo simple de establecer persistencia en el equipo de la víctima.
El módulo inicial en sí es un archivo MSIL que tiene un tamaño de aproximadamente 200MB. Contiene un array de bytes excesivamente grande, probablemente para evadir la detección de productos de seguridad que tengan un límite de tamaño de archivo para realizar el escaneo. Contiene una DLL empaquetada, cifrada con XOR y comprimida con gzip, que es descifrada y cargada durante la ejecución realizando un late binding a través de la API de .NET Reflection. A su vez, esta DLL contiene otro archivo empaquetado, en este caso un script compilado AutoIt, además de las funciones RunPE para poder inyectarlo en algún proceso legítimo de Windows. Hemos observado los procesos vbc.exe (Compilador de Visual Basic) y csc.exe (Compilador de C#) siendo los objetivos de la amenaza.
La inyección se realiza creando una instancia del proceso vbc.exe en estado de suspensión, desmapeando sus secciones de memoria y finalmente cargando el archivo malicioso en la memoria que se le asignó al proceso. Como se puede ver en la Figura 5, VictoryGate utiliza varias funciones no documentadas de NTAPI, como NtWriteVirtualMemory, en lugar de utilizar funciones más comunes y mejor documentadas por Microsoft, como WriteProcessMemory. Esto se realiza para evadir las detecciones por API hooking básicas que algunos productos de seguridad utilizan.
El agente AutoIt inyectado es el responsable por la comunicación con el C&C, la descarga y ejecución de los distintos payloads, y el escaneo constante de unidades USB conectadas para poder infectarlas. Si detecta una nueva unidad, procederá a esconder los archivos originales y reemplazarlos por los scripts de propagación como mencionamos anteriormente.
Payloads descargados
Los payloads descargados también suelen ser scripts AutoIt compilados. El compilador tiene la habilidad de embeber ejecutables junto con el script en un único archivo. El malware hace uso de esta funcionalidad y dentro del ejecutable descargado podemos encontrar un archivo MSIL que es eventualmente ejecutado con la funcion AutoIt ShellExecute(). Además de la ejecución de este binario, el script crea un nuevo acceso directo en la carpeta de inicio de Windows vinculado al payload y una tarea programada que se ejecuta cada un minuto como mecanismos de persistencia adicionales.
En la Figura 6 se aprecia el flujo de ejecución de los payloads analizados:
Nuevamente, el payload inyectará el código en un proceso legítimo de Windows. En este caso, intentará inyectar el minero XMRig en el proceso ucsvc.exe (Boot File Servicing Utility).
Una vez ejecutado el archivo MSIL, tpmvscugr.exe, éste descifra un array cifrado con Rijndael, en una implementación similar a AES. Se trata de archivo binario empaquetado al cual llamamos gate.exe – sus métodos son invocados durante la ejecución utilizando la API de .NET Reflection.
El binario empaquetado no tiene el código necesario para realizar la inyección por sí mismo, sino que la última pieza para poder inyectar el minero en el proceso de ucsvc.exe es una DLL que es enviada por el C&C a través del tráfico de red. Dicho tráfico enviado está comprimido utilizando gzip y el contenido de la DLL es cifrado con AES. El stream cifrado es almacenado en una clave del registro y la clave para descifrar el archivo tiene que ser recuperada del tráfico de red entre el servidor y el nodo. Finalmente, esta DLL es cargada en la memoria del proceso de tpmvscugr.exe durante la ejecución mediante un late binding.
Esta DLL (auto.dll) contiene alunas funciones RunPE típicas que le permiten a gate.exe realizar la inyección.
Minería de Monero
Una vez que el proceso de ucsvc.exe fue inyectado con el minero XMRig, el C&C comienza la minería enviando un comando como el siguiente:
C:\Windows\system32\ucsvc.exe -algo cryptonight -url <Redacted>:19019 –user CPU_x64 –pass x –retries=50 –retry-pause=1 –keepalive –donate-level=1 –nicehash
La dirección IP que se ve en el comando no es un pool de minería, sino que se trata de un Stratum proxy – O XMRig proxy que añade un nivel de indirección, ya que no permite determinar el usuario del operador de la botnet.
Por otro lado, cuando el usuario intente averiguar a que se debe que su PC tenga un rendimiento tan lento, no encontrará en el administrador de tareas nada que llame su atención, ya que, como hemos visto en varias amenazas de este tipo, el proceso de minería finaliza cuando se abre dicho programa, y es resumido en cuanto el administrador de tareas se cierra.
Con la información recolectada durante nuestras actividades de sinkholing podemos determinar que hay en promedio 2,000 dispositivos minando constantemente a lo largo del día para el atacante. Si estimamos un hashrate promedio de 150 H/s por equipo se puede extrapolar que el dinero obtenido en esta campaña es de alrededor de 80XMR (USD 6,000).
Conclusión
VictoryGate es una nueva botnet que utiliza dispositivos de almacenamiento USB como mecanismo de propagación, una técnica recurrente en campañas de malware en la región de LATAM. La utilización de XMRig para la minería de Monero también es una tendencia que ha ido creciendo en campañas de este tipo a lo largo del mundo.
Una de las características interesantes de VictoryGate es que, en comparación con otras campañas, hace un esfuerzo mayor para evadir la detección por parte de las soluciones de seguridad. De todos modos, el factor más interesante de esta investigación ha sido nuestra habilidad de registrar nombres de dominios hardcodeados en las muestras analizadas para poder obtener información estadística sobre los equipos infectados. De esta manera, además, pudimos compartir los datos obtenidos con Shadowserver Foundation para alertar a las autoridades locales y a los propietarios de red. No-IP tamién ha sido de gran ayuda en dar de baja los nombres de dominio maliciosos, efectivamente removiendo los equipos infectados del operador de la botnet.
A pesar de nuestros esfuerzos, los pendrives infectados van a continuar en circulación, razón por la cual se seguirán produciendo nuevas infecciones. Sin embargo, la diferencia significativa que se logró a partir de esta investigación es que los equipos ya no recibirán comandos del C&C, por ende no descargarán nuevos payloads de Internet. De todos modos, aquellas PC que hayan sido infectadas previo a la disrupción continuarán minando para el atacante.