Esta no es la primera vez que la industria del juego es apuntada por los atacantes, que buscan comprometer a los desarrolladores de juegos para insertar backdoors en sus entornos de desarrollo y de esta manera tener la posibilidad de distribuir su malware como parte de un software legítimo. En abril de 2013, Kaspersky Lab reportó que un popular videojuego había sido alterado en 2011 para incluir un backdoor. Dicho ataque fue atribuido a cibercriminales que Kaspersky denominó Grupo Winnti.

Recientemente, nuevos ataques de cadena de suministro despertaron la atención de los investigadores de ESET. En esta oportunidad, dos juegos y una aplicación de plataforma de videojuegos para incluir un backdoor. Una vez logrado esto, los ataques fueron mayormente dirigidos al continente asiático y a la industria de los juegos; por lo que no debería sorprender que se trate de una obra realizada por el mismo grupo que Kaspersky describió como “Winnti – Más que un simple juego”.

Tres casos: el mismo backdoor

Aunque el malware utiliza diferentes configuraciones para cada caso, los tres productos de software afectados incluyen el mismo código de backdoor y fueron lanzados utilizando la misma máquina. Mientras que dos de los productos comprometidos ya no incluyen el backdoor, uno de los desarrolladores afectados aún sigue distribuyendo la versión troyanizada que, irónicamente, se aprovecha de un juego llamado “infestation”, que en español quiere decir “infección, y que es producido por los desarrolladores tailandeses de “Electronics Extreme”. Desde el mes de febrero hemos intentado informarles varias veces y a través de distintos canales, pero sin éxito aparente.

Observemos primero cómo está embebido el payload malicioso y luego analicemos los detalles del propio backdoor.

Embebiendo el payload

El código del payload es iniciado en una etapa muy temprana durante la ejecución del archivo ejecutable backdoreado.  Justo después del punto de entrada PE, el estándar de llamada a la inicialización C Runtime (__scrt_common_main_seh en la Figura 1) está hookeada para ejecutar el payload malicioso antes que todo lo demás (Figura 2). Esto podría sugerir que los actores maliciosos cambiaron una configuración de construcción en lugar del código fuente en sí.

Figura 1: Archivo ejecutable de punto de entrada limpio

Figura 2: Archivo ejecutable de punto de entrada comprometido

El código añadido al ejecutable descifra y ejecuta el backdoor en la memoria, antes de reanudar la ejecución normal del código de inicialización de C Runtime y todo el subsecuente código de la aplicación host. Los datos embebidos del payload presentan una estructura específica, que se puede apreciar en la Figura 3, la cual está parseada por el código de desempaquetado añadido.

Figura 3.Estructrura del payload embebido

Incluye una llave RC4 (la cual es XOReada con 0x37) que es utilizada para descifrar el nombre de un archivo y el archivo DLL embebido.

El payload malicioso

El payload malicioso actual es bastante pequeño y contiene aproximadamente 17 KB de datos y código.

Configuración

Ilustrado en la Figura 4, los datos de configuración son simplemente una lista de strings separados por espacios en blanco.

Figura 4 – Datos de configuración del payload

La configuración consiste en cuatro campos:

1. URL del servidor C&C.
2. Variable (t) utilizada para determinar el tiempo de apagado en milisegundos antes de continuar la ejecución. El tiempo de espera es elegido de manera aleatoria en el rango de 2/3 t a 5/3 t.
3. Una cadena de caracteres que identifica una campaña.
4. Una lista separada por punto y coma de nombres de archivos ejecutables. Si cualquiera de estos está corriendo, el backdoor detiene su ejecución.

Los investigadores de ESET han identificado cinco versiones del payload:

En las primeras tres variantes, el código no fue recompilado, pero los datos de configuración fueron editados en el propio archivo DLL. El resto del contenido es una copia byte a byte.

Infraestructura C&C

Los nombres de dominio fueron cuidadosamente elegidos para que aparenten tener relación con el juego o con el autor de la aplicación. El dominio apex fue configurado para redirigir hacia un sitio legítimo importante utilizando el servicio de redirección Namecheap, mientras que el subdominio apunta al servidor malicioso C&C.

Al momento de escribir este artículo, ninguno de estos dominios resuelve y los servidores C&C no están respondiendo.

Reporte de reconocimiento

Un identificador de bot es generado desde la dirección MAC de las máquinas. El backdoor reporta información sobre la máquina, como por ejemplo, el nombre de usuario, nombre de la computadora, versión de Windows e idioma del sistema con el servidor C&C y espera para recibir instrucciones. Los datos están en cifrado XOR con la llave “*&b0i0rong2Y7un1” y codificados en base64.

Comandos

Este simple backdoor tiene cuatro comandos que pueden ser utilizados por el atacante:

• DownUrlFile
• DownRunUrlFile
• RunUrlBinInMem
• UnInstall

Los comandos son bastante autoexplicativos. Permiten al atacante correr ejecutables adicionales desde una URL dada.

El ultimo es quizás menos obvio. El comando UnInstall no remueve el malware del sistema. Después de todo, está embebido dentro de un ejecutable legítimo que aún necesita correr. Más que remover algo, lo que hace es deshabilitar el código malicioso estableciendo el siguiente valor de registro a 1:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\ImageFlag

Cuando el payload inicia, el valor de registro es consultado y la ejecución es cancelada si se establece el valor correspondiente. Quizás los atacantes están intentando reducir la carga de sus servidores C&C al evitar la devolución de llamadas de víctimas que no resulten interesantes.

Segunda fase

Basados en la telemetría de ESET, uno de los payload de segunda fase enviados a la víctima es Win64/Winnti.BN. Hasta donde podemos decir, su dropper fue descargado sobre HTTPS desde api.goallbandungtravel[.]com. Lo hemos visto instalado como un servicio de Windows y como una DLL en C:\Windows\System32 utilizando los siguientes nombres de archivo:

• cscsrv.dll
• dwmsvc.dll
• iassrv.dll
• mprsvc.dll
• nlasrv.dll
• powfsvc.dll
• racsvc.dll
• slcsvc.dll
• snmpsvc.dll
• sspisvc.dll

Las muestras que analizamos eran bastante grandes, con aproximadamente 60MB cada una de ellas. Sin embargo, esto es solo para aparentar, porque el tamaño real del archivo PE es de entre 63KB y 72KB, dependiendo de la versión. Los archivos del malware tienen varios archivos limpios adjuntados. Esto es hecho probablemente por el componente que droppea e instala este servicio malicioso.

Una vez que el servicio corre, adjunta la extensión .mui a su ruta DLL, lee ese archivo y lo descifra utilizando RC5. El archivo MUI descifrado contiene código de posición independiente con desplazamiento 0. La llave RC5 es derivada desde el número de serie del disco rígido y el string f@Ukd!rCto R$. — no fuimos capaces de obtener ningún archivo MUI ni el código que los instala en primer lugar. Por lo tanto, no sabemos exactamente el propósito de este servicio malicioso.

Recientes versiones del malware incluyen un mecanismo de actualización automática mediante la utilización del servidor C&C http://checkin.travelsanignacio[.]com. Este servidor C&C entregó la última versión de los archivos MUI cifrados con una llave estática RC5. Durante nuestro análisis, el servidor C&C no estaba respondiendo.

Blancos de ataque

Comencemos por señalar aquellos que no están apuntados. Una etapa temprana en el payload, el malware revisa si el idioma del sistema es ruso o chino (Figura 5). En cualquiera de estos casos, el malware deja de correr, lo que deja bastante claro que los atacantes no están interesados en computadoras configuradas con estos idiomas.

Figura 5 Revisión del idioma antes de ejecutar el payload

Estadísticas de distribución

La telemetría de ESET muestra que la mayoría de las víctimas está ubicada en Asia, siendo Tailandia el país más afectado, Dada la popularidad de las aplicaciones comprometidas, que continúan siendo distribuidas por sus desarrolladores, no sería llamativo que el número de víctimas alcance cifras en el entorno de decenas o cientos de miles.

Conclusión

Los ataques de cadena de suministro son difíciles de detectar desde la perspectiva del consumidor. Es imposible comenzar analizando cada pieza de software que corremos, especialmente con todas las actualizaciones regulares que instan y/o requieren instalar. Por lo tanto, depositamos nuestra confianza en los proveedores de software y que los archivos que distribuyen no incluyen malware. Quizás esa es la razón por la que múltiples grupos apuntan a desarrolladores de software: comprometiendo los resultados del proveedor en una botnet tan popular como el software que es vulnerado. Sin embargo, existe una desventaja de utilizar esta técnica: una vez que el esquema es revelado, el atacante pierde control y las computadoras pueden limpiarse mediante actualizaciones regulares.

No sabemos los motivos de los atacantes en este punto. ¿Se trata simplemente de una ganancia económica? ¿Hay alguna razón que explique por qué los tres productos afectados son de desarrolladores de Asia y del mercado asiático? ¿Estos ataques utilizan una botnet como parte de una operación de espionaje más amplia?

Los productos de ESET detectan esta amenaza como, Win32/HackedApp.Winnti.A, Win32/HackedApp.Winnti.B; el payload como Win32/Winnti.AG, y el de segunda fase como Win64/Winnti.BN.

Indicadores de Compromiso (IoCs)

Muestra de archivos comprometidos (Win32/HackedApp.Winnti.A and B)

Algunos hashes fueron redactados por solicitud de uno de los proveedores. Si por motivos particulares usted los necesita, puede contactarnos a través de: threatintel@eset.com.

Muestras del payload (Win32/Winnti.AG)

Muestras de segunda fase (Win64/Winnti.BN)

Dropper enviado por api.goallbandungtravel[.]com.

Matríz de MITRE ATT&CK