El SideWalk puede ser tan peligroso como el CROSSWALK

Los investigadores de ESET han descubierto recientemente una nueva puerta trasera modular indocumentada, SideWalk, que está siendo utilizada por un grupo de APT que hemos llamado SparklingGoblin; esta puerta trasera se usó durante una de las campañas recientes de SparklingGoblin dirigida a una empresa minorista de computadoras con sede en EE. UU. Esta puerta trasera comparte múltiples similitudes con otra puerta trasera utilizada por el grupo: PASO DE PEATONES.

SideWalk es una puerta trasera modular que puede cargar dinámicamente módulos adicionales enviados desde su servidor C&C, hace uso de Google Docs como solucionador de puntos muertos y trabajadores de Cloudflare como servidor C&C. También puede manejar correctamente la comunicación detrás de un proxy.

SparklingGoblin, miembro de la familia Winnti

En noviembre de 2019, descubrimos una campaña de Winnti Group dirigida a varias universidades de Hong Kong que había comenzado a fines de octubre de 2019, y publicamos un entrada de blog sobre esto. Durante esa campaña, los atacantes utilizaron principalmente el Puerta trasera ShadowPad y el malware Winnti, pero también el Puerta trasera Spyder y una puerta trasera basada en DarkShell (una RAT de código abierto) que llamamos Doraemon.

Posteriormente a esa campaña, en mayo de 2020 (como se documenta en nuestro Informe de amenazas del segundo trimestre de 2020) observamos una nueva campaña dirigida a una de las universidades que anteriormente había sido comprometida por Winnti Group en octubre de 2019, donde los atacantes utilizaron la puerta trasera CROSSWALK y una variante de PlugX utilizando Google Docs como solucionador de puntos muertos. Aunque esa campaña mostraba vínculos con Winnti Group, el modus operandi era bastante diferente y comenzamos a rastrearlo como un actor de amenaza independiente.

Tras el compromiso de la universidad de Hong Kong, observamos múltiples compromisos contra organizaciones de todo el mundo que utilizan conjuntos de herramientas y TTP similares. Teniendo en cuenta esos TTP en particular y para evitar aumentar la confusión general en torno a la etiqueta "Winnti Group", decidimos documentar este grupo de actividad como un nuevo grupo, al que hemos denominado SparklingGoblin, y que creemos que está conectado con Winnti Group mientras exhibimos. algunas diferencias.

Victimología

Desde mediados de 2020, de acuerdo con nuestra telemetría, SparklingGoblin ha estado muy activo y seguirá siéndolo en 2021. Aunque el grupo apunta principalmente al este y sudeste de Asia, hemos visto a SparklingGoblin apuntando a una amplia gama de organizaciones y verticales en todo el mundo, con un enfoque particular centrarse en el sector académico, pero incluyendo:

• Sectores académicos en Macao, Hong Kong y Taiwán
• Una organización religiosa en Taiwán
• Un fabricante de computadoras y electrónica en Taiwán
• Organizaciones gubernamentales en el sudeste asiático
• Una plataforma de comercio electrónico en Corea del Sur
• El sector de la educación en Canadá
• Empresas de medios en India, Bahrein y EE. UU.
• Una empresa minorista de informática con sede en EE. UU.
• Gobierno local en el país de Georgia
• Organizaciones no identificadas en Corea del Sur y Singapur

Figura 1. Distribución geográfica de los objetivos de SparklingGoblin

Acera

La puesta en escena de SideWalk se resume en la Figura 2. La puerta trasera de SideWalk es un shellcode encriptado con ChaCha20 que se carga desde el disco mediante los cargadores .NET basados ​​en InstallUtil de SparklingGoblin.

Figura 2. Mecanismo de estadificación SideWalk

Además, como mostraremos a continuación, la puerta trasera SideWalk comparte múltiples similitudes con CROSSWALK, que es una puerta trasera modular atribuida a APT41 de FireEye y documentado públicamente por Carbon Black.

Primera etapa

El shellcode de SideWalk se implementa cifrado en el disco con el nombre Microsoft.WebService.targets y se cargó con el cargador .NET basado en InstallUtil de SparklingGoblin ofuscado con un ConfuserEx, un protector de código abierto para aplicaciones .NET que el grupo utiliza con frecuencia.

Los cargadores .NET de SparklingGoblin persisten a través de una tarea programada con uno de los siguientes nombres de archivo:

• RasTaskStart
• RasTaskManager
• Servicio web

Ejecuta el cargador utilizando el Utilidad InstallUtil.exe usando el siguiente comando:

dónde InstallWebService.sql es el cargador .NET malicioso. Cuando comencé con el / U bandera, como aquí, la Desinstalar método del USCInstaller clase en el UPrivate Se llama al método de espacio de nombres del cargador .NET (consulte la Figura 3).

Figura 3. Jerarquía de un cargador basado en InstallUtil

Una versión desobstruida del RunShellcode El método llamado por el método Uninstall se muestra en la Figura 4.

Figura 4. Método de cargador .NET llamado por el método Uninstall y que descifra e inyecta el código de shell.

Como podemos ver, el cargador es responsable de leer el shellcode cifrado del disco, descifrarlo e inyectarlo en un proceso legítimo usando el proceso de técnica de vaciado. Tenga en cuenta que el algoritmo de descifrado utilizado varía según las muestras.

Además, tenga en cuenta que SparklingGoblin utiliza una variedad de cargadores de shellcode diferentes, como el cargador Motnug y los cargadores basados ​​en ChaCha20. Motnug es un cargador de shellcode bastante simple que se usa con frecuencia para cargar la puerta trasera CROSSWALK, mientras que los cargadores basados ​​en ChaCha20, como sugieren sus nombres, se utilizan para descifrar y cargar shellcode cifrado con el Algoritmo ChaCha20. La implementación de ChaCha20 utilizada en este cargador es la misma que se utiliza en la puerta trasera SideWalk que se describe a continuación. Esta implementación se basa en un contador (modo CTR), utilizando una clave nonce de 12 bytes y una clave de 32 bytes con un valor de contador de 11, lo que lleva al siguiente estado inicial:

El valor del contador 0x0000000B difiere de la implementación habitual de ChaCha20, donde generalmente se establece en 0.

Tenga en cuenta que estos cargadores basados ​​en ChaCha20 se documentaron previamente en un entrada de blog de Positive Technologies.

Inicialización

Similar a CROSSWALK, el shellcode SideWalk utiliza una estructura principal para almacenar cadenas, variables, la tabla de direcciones de importación (IAT) y sus datos de configuración. Luego, esta estructura se pasa como argumento a todas las funciones que la necesitan. Durante la inicialización de SideWalk, primero se descifran las cadenas y se agregan a la estructura, luego se completa la parte de la estructura responsable de almacenar el IAT y, finalmente, se descifra la configuración de SideWalk.

Descifrado de grupos de cadenas y datos

Al comienzo de su ejecución, la sección de datos al final del código de shell se descifra utilizando un bucle XOR y esta clave de 16 bytes: B0 1D 1E 4B 68 76 FF 2E 49 16 EB 2B 74 4C BB 3A. Esta sección, una vez descifrada, contiene las cadenas que utilizará SideWalk, que incluyen:

• claves de registro
• claves de descifrado
• ruta para escribir archivos recibidos del servidor C&C
• Método HTTP que se utilizará
• Parámetros de solicitud HTTP
• URL utilizadas para recuperar la configuración del proxy local
• delimitadores utilizados para recuperar la dirección IP encriptada del documento de Google Docs

El grupo de cadenas descifrado se enumera en la Figura 5 a continuación.

Figura 5. Cadenas de configuración descifradas de SideWalk

Tenga en cuenta que, al igual que SideWalk, CROSSWALK también comienza su ejecución descifrando un grupo de cadenas utilizando un bucle XOR y una clave de 16 bytes.

Descifrado de instrucciones

Después de descifrar la sección de datos al final del código de shell, SideWalk procede a descifrar el resto de sus instrucciones (comenzando en el desplazamiento 0x528) utilizando el mismo bucle XOR con una clave diferente de 16 bytes: 26 74 94 78 36 60 C1 0C 41 56 0E 60 B1 54 D7 31.

Anti-manipulación

Una vez que ha descifrado sus datos y código, SideWalk procede a verificar su integridad calculando una suma de comprobación de 32 bits, rotando el resultado hacia la derecha en 13 bits en cada palabra de 32 bits y comparando el valor hash con uno de referencia correspondiente a la shellcode sin alterar. Si el hash es diferente del valor de referencia, sale. Esto permite que el shellcode detecte puntos de interrupción o parches en su código y evite la ejecución en tales casos. El código descompilado correspondiente se muestra en la Figura 6.

Figura 6. Código descompilado del procedimiento anti-manipulación de SideWalk

YO EN

Además del grupo de cadenas, los datos decodificados también contienen los nombres de las DLL, así como los hash de los nombres de las funciones, que se cargarán. A diferencia de CROSSWALK, donde se usa la representación de cadena de los hash, los hash se almacenan directamente en su representación binaria sin procesar. La parte correspondiente de la estructura principal, después de haber resuelto las direcciones de importación, se muestra en la Figura 7. Los nombres de las DLL que se van a cargar están resaltados en gris, el hash de los nombres de las funciones de la API de Windows que se van a importar están en violeta y las direcciones de las funciones importadas están en verde.

Figura 7. Estructura de IAT de SideWalk

SideWalk itera sobre las exportaciones de cada una de las DLL enumeradas en los datos decodificados y las hash con un algoritmo de hash personalizado y luego las compara con los hash de los nombres de función que se van a importar. Una vez que se encuentra una coincidencia, la dirección de la función coincidente se agrega a la estructura principal.

Configuración

Una vez que se llena el IAT, SideWalk procede a descifrar su configuración. La configuración se cifra mediante el algoritmo ChaCha20 y la clave de descifrado es parte del conjunto de cadenas mencionado anteriormente. La implementación de ChaCha20 es la misma que se usa para el cargador basado en ChaCha20. La configuración descifrada contiene valores utilizados por SideWalk para un funcionamiento adecuado, así como la update.facebookint.workers (.) dev Servidor de C&C y la URL del documento de Google Docs que luego se utiliza como solucionador de puntos muertos.

Tenga en cuenta que el update.facebookint.workers (.) dev el dominio es un Trabajador de Cloudflare que permite a los operadores de malware personalizar el servidor, ejecutándose en un servicio web público ampliamente utilizado. Durante esa campaña, SparklingGoblin también usó un dominio de trabajador de Cloudflare con Cobalt Strike: cdn.cloudfiare.workers (.) dev.

Actividad de red

Una característica de SideWalk es verificar si existe una configuración de proxy antes de comenzar a comunicarse con el servidor C&C. Para ello, prueba dos técnicas:

• Una llamada a la función API WinHttpGetIEProxyConfigForCurrentUser, con URL predefinidas contenidas en su configuración:
• Si SideWalk puede ajustar sus privilegios para SeDebugPrivilege, intenta recuperar la configuración del proxy de HKU Software Microsoft Windows CurrentVersion Internet Settings ProxyServer. De lo contrario, intenta recuperarlo de HKCU Software Microsoft Windows CurrentVersion Internet Settings ProxyServer.

Si se encuentra un proxy, SideWalk lo usará para comunicarse con el servidor C&C. Este comportamiento es muy similar a la forma en que CROSSWALK maneja los proxies.

SideWalk intenta obtener la configuración de proxy de la sesión de usuario actual robando el token de usuario de explorer.exe (el nombre del proceso para buscar está en la configuración) y llamar a la API de Windows WinHttpGetIEProxyConfigForCurrentUser.

Tenga en cuenta que SideWalk tiene los permisos necesarios para hacerse pasar por usuarios conectados porque lo carga el cargador .NET basado en InstallUtil, que persiste como una tarea programada y, por lo tanto, se ejecuta bajo la SISTEMA cuenta. Curiosamente, el mismo procedimiento para obtener el token explorer.exe se describe en este Blog de idioma chino. El procedimiento descompilado se muestra en la Figura 8.

Figura 8. Código descompilado responsable de la suplantación de identidad del usuario antes de recuperar la configuración del proxy

Formatos de solicitudes

La página de Google Docs utilizada por SideWalk como solucionador de puntos muertos se muestra en la siguiente captura de pantalla (Figura 9) y, en el momento de escribir este artículo, todavía está activa. Tenga en cuenta que cualquiera puede editar esta página.

Figura 9. Documento de Google Docs utilizado por SideWalk como solucionador de puntos muertos

La cadena presente en esta página tiene el formato que se muestra en la Figura 10.

Figura 10. Formato de la cadena alojada en el documento de Google Docs

Esta cadena se compone de:

• Se utilizan delimitadores para un análisis adecuado.
• Una carga útil y su tamaño, que consta de una dirección IP cifrada con ChaCha20, la clave para descifrarla y, para una verificación de integridad, el hash de la clave de descifrado.
• Cadenas adicionales que no se utilizan actualmente.

Para facilitar el uso futuro potencial de ese formato, hemos proporcionado un script en nuestro repositorio de GitHub.

La dirección IP descifrada es 80.85.155 (.) 80. Ese servidor C&C utiliza un certificado autofirmado para el facebookint (.) com dominio. Este dominio se ha atribuido a BARIO de Microsoft, que se superpone parcialmente con lo que definimos como Winnti Group. Como esta dirección IP no es la primera que utiliza el malware, se considera la alternativa.

El protocolo de comunicación utilizado por SideWalk para comunicarse con su servidor C&C es HTTPS y el formato de los encabezados de solicitud POST enviados al C&C se puede ver en la Figura 11.

Figura 11. Ejemplo de una solicitud POST utilizada por SideWalk

Tanto la URL como los valores de la gtsid y gtuvid los parámetros se generan aleatoriamente. los Anfitrión El campo es la IP obtenida de Google Docs o está configurado como update.facebookint.workers (.) dev. Los datos de la solicitud POST son una carga útil cifrada. El formato utilizado por esta solicitud es el formato de comunicación utilizado por los operadores de SideWalk entre el servidor de C&C y las máquinas infectadas, por ejemplo, solicitudes y respuestas. El formato de los datos de la solicitud POST se muestra en la Figura 12.

Figura 12. Formato de los datos de la solicitud POST

Tenga en cuenta que este formato se usa tanto para la solicitud como para la respuesta, lo que significa que cuando SideWalk maneja los datos enviados desde el servidor C&C, los analiza de acuerdo con el mismo formato. No hay ninguna similitud particular en el lado de la comunicación del servidor C&C entre CROSSWALK y SideWalk.

En este formato, los campos son:

• picadillo: el hash de los datos de 0x10 para tamaño total de la carga útil. El algoritmo hash es un hash personalizado combinado de múltiples llamadas MD5 en diferentes partes de los datos hash.
• Talla: el tamaño es igual a tamaño_total – 0x0D.
• clave1, key2: ChaCha20 claves para cifrar el búfer de encabezado y el búfer de datos.
• búfer de parámetros: búfer opcional (puede ser 0… 0).
• identificación de víctima: información de autenticación, que es el resultado de un hash personalizado de diversa información de la máquina, incluido el GUID de la máquina y el nombre de la computadora.
• ID de ejecución: antes de lanzar los hilos, este ID se genera usando CryptGenRandom. Es diferente para cada ejecución.
• ID de comando / ID de respuesta: ID de la acción que ha manejado el malware cuando es una solicitud del malware al servidor de C&C y el ID del comando a ejecutar cuando es una respuesta del servidor de C&C al malware.
• encimera: número de comandos ejecutados desde el inicio del proceso SideWalk actual.
• datos: los datos comprimidos y cifrados con ChaCha20 obtenidos por el malware o enviados por el servidor C&C.
• tamaño comprimido: el tamaño de los datos comprimidos LZ4.
• tamaño de datos: el tamaño de los datos sin comprimir.

Búfer de encabezado y Búfer de datos se cifran con las claves correspondientes. El primero representa los metadatos para identificar la máquina que se vio comprometida, y el segundo búfer corresponde a los datos reales compartidos entre el servidor C&C y el malware. Los detalles de estos campos que se muestran en la Figura 12 son visibles una vez descifrados.

Capacidades

Cuando comenzamos a analizar SideWalk, dado que su servidor C&C ya estaba inactivo, algunas de las posibles acciones no eran del todo comprensibles sin conocer los datos enviados por el servidor C&C; sin embargo, la mayoría de las capacidades del malware están documentadas en la siguiente tabla.

Tabla 1. Comandos de C&C admitidos por SideWalk

Nota: Como no recuperamos ningún complemento del servidor C&C, es difícil evaluar todas las capacidades de SideWalk.

La conexión CROSSWALK

Aunque el código SideWalk y CROSSWALK es diferente, ambas familias comparten múltiples similitudes arquitectónicas, con una técnica anti-manipulación, un modelo de subprocesos y un diseño de datos similares, y la forma en que estos datos se manejan durante la ejecución. En cuanto a las características, ambas puertas traseras son modulares y pueden manejar proxies para comunicarse correctamente con sus servidores C&C.

Estas similitudes se describen a continuación y se resumen en una tabla al final de esta sección.

Teniendo en cuenta todas estas similitudes, creemos que SideWalk y CROSSWALK probablemente estén codificados por los mismos desarrolladores.

Arquitectura

El modelo de roscado es muy similar entre SideWalk y CROSSWALK. Los autores dividen las tareas entre hilos y usan PostThreadMessage Llamadas a la API de Windows para comunicarse entre ellos. Por ejemplo, un subproceso es responsable de realizar una solicitud y, una vez que obtiene la respuesta, la transfiere al subproceso correspondiente.

El estilo de programación también es muy similar; se utiliza un enfoque funcional. Una estructura de datos almacena la configuración, las cadenas y las importaciones, y se pasa como argumento a todas las funciones que lo necesitan.

Por ejemplo, aquí hay algunos prototipos de funciones:

• __int64 getMachineGuid (main_struct * main_struct, __int64 machineguid)
• __int64 writeBufferToFile (main_struct * main_struct, __int64 buffer, unsigned int nbBytes)
• __int64 recv (main_struct * main_struct, socket __int64, unsigned int nbBytes, __int64 buffer)

Tanto SideWalk como CROSSWALK son puertas traseras modulares que pueden cargar módulos adicionales enviados por el servidor C&C. El manejo del módulo SideWalk se implementa de manera similar a CROSSWALK. Algunas de las posibles operaciones del módulo son ejecución, instalación y desinstalación.

Funcionalidades

Al igual que CROSSWALK, durante su inicialización, SideWalk calcula un valor hash de 32 bits del código de shell al comienzo de su ejecución utilizando un bucle ROR4.

CROSSWALK y SideWalk reúnen artefactos similares; entre ellos:

• Configuración de IP
• versión del sistema operativo
• Nombre de usuario
• Nombre del computador
• Nombre del archivo
• ID de proceso actual
• Tiempo actual

El manejo de proxy es el mismo en CROSSWALK y SideWalk. Ambos usan URL legítimas comunes (como https://www.google.com o https://www.twitter.com) y un WinHttpGetIEProxyConfigForCurrentUser Llamada a la API de Windows para recuperar la configuración del proxy.

Disposición de datos

SideWalk y CROSSWALK siguen el mismo diseño de shellcode, con instrucciones seguidas de cadenas, IAT y datos de configuración cifrados.

Manejo de datos

SideWalk y CROSSWALK procesan los datos al final del código de shell de la misma manera:

• Primero, la sección de datos se descifra mediante un bucle XOR de 16 bytes.
• Luego, las direcciones de función de los hash de nombre almacenados en la sección de datos se resuelven y almacenan en su estructura principal (apuntando al IAT en la sección de datos).
• Finalmente, se descifra su configuración que contiene la dirección del servidor C&C (aunque el algoritmo de descifrado utilizado por SideWalk es diferente).

Tabla 2. Resumen de las similitudes entre SideWalk y CROSSWALK

Conclusión

SideWalk es una puerta trasera previamente indocumentada utilizada por el grupo APT SparklingGoblin. Lo más probable es que haya sido producido por los mismos desarrolladores que los que están detrás de CROSSWALK, con los que comparte muchas estructuras de diseño y detalles de implementación.

SparklingGoblin es un grupo con algún nivel de conexión con Winnti Group. Fue muy activo en 2020 y la primera mitad de 2021, comprometiendo a múltiples organizaciones en una amplia gama de verticales en todo el mundo y con un enfoque particular en el sector académico y el este de Asia.

ESET Research ahora ofrece un informe de inteligencia APT privado y una fuente de datos. Para cualquier consulta sobre este nuevo servicio, o investigaciones publicadas en WLS, contáctenos en amenazaintel@eset.com.

Indicadores de compromiso (IoC)

Se puede encontrar una lista completa de indicadores de compromiso y ejemplos en nuestro repositorio de GitHub.

Muestras

Tenga en cuenta que la muestra de SideWalk a la que se hace referencia a continuación no es aquella en la que se basa nuestro análisis; la muestra real utilizada durante el compromiso es la que se analiza en detalle en el texto de esta entrada de blog.

La red

update.facebookint.workers (.) dev
cdn.cloudfiare.workers (.) dev
104.21.49 (.) 220
80.85.155 (.) 80
193.38.54 (.) 110

Nombres de archivo

C: Windows System32 Tasks Microsoft Windows WindowsUpdate WebService
C: windows system32 tasks Microsoft Windows Ras RasTaskStart
iislog.tmp
mscorsecimpl.tlb
C_25749.NLS
Microsoft.WebService.targets

Certificado SSL

Técnicas MITRE ATT & CK

Esta mesa fue construida usando versión 9 del marco MITRE ATT & CK.