El equipo de investigación de ESET descubrió recientemente el uso de herramientas que nunca habían sido documentadas previamente que fueron utilizadas en ataques dirigidos contra empresas de alto perfil y organismos gubernamentales, principalmente en Asia. Estos ataques fueron realizados por un grupo de espionaje previamente desconocido al que hemos llamado Worok. Este grupo ha estado activo desde al menos 2020. El conjunto de herramientas que utiliza Worok incluye CLRLoad, un loader en C++, PowHeartBeat, un backdoor en PowerShell y PNGLoad, un loader en C# que usa esteganografía para extraer payloads maliciosos ocultos desde archivos PNG.
¿Qué es Worok?
Durante la divulgación de la vulnerabilidad de ProxyShell (CVE-2021-34523) a principios de 2021, desde los laboratorios de ESET detectamos actividad de varios grupos de APT explotando las vulnerabilidades en Microsoft Exchange. Uno de ellos mostró características comunes con TA428:
- Horarios de actividad
- Mercados verticales a los que apuntó
- Uso de ShadowPad
El resto del conjunto de herramientas es muy diferente: por ejemplo, TA428 participó en el compromiso de Able Desktop en 2020. Consideramos que los vínculos no son lo suficientemente fuertes como para considerar que Worok es el mismo grupo que TA428, pero los dos grupos podrían compartir herramientas. y tienen intereses comunes. Por lo tanto, decidimos crear un grupo y lo llamamos Worok. El nombre fue elegido después de un mutex en un loader utilizado por el grupo. Luego se pudo vincular a este grupo actividad posterior en la que se utilizó variantes de las mismas herramientas. Según la telemetría de ESET, Worok ha estado activo desde fines de 2020 y continúa en actividad al momento de escribir este artículo.
A fines de 2020, Worok estaba apuntando a gobiernos y empresas en varios países, en particular a:
- Una empresa de telecomunicaciones en el este de Asia
- Un banco en Asia Central
- Una empresa de la industria marítima en el sudeste asiático
- Una entidad gubernamental en el Medio Oriente
- Una empresa privada en el sur de África
Hubo una interrupción significativa en sus operaciones entre mayo de 2021 y enero de 2022, pero la actividad de Worok regresó en 2022-02 apuntando a:
- Una empresa de energía en Asia Central
- Un organismo público en el sudeste asiático
La Imagen 1 muestra las regiones y perfil de blancos de ataque.
Imagen 1. Mapa de las regiones y perfil de blancos apuntados
Teniendo en cuenta los perfiles de los blancos de ataque y las herramientas que hemos visto desplegadas contra estas víctimas, creemos que el objetivo principal de Worok es robar información.
Análisis técnico
Si bien se desconoce la mayoría de los accesos iniciales, en algunos casos a lo largo de 2021 y 2022 hemos visto el uso de exploits contra las vulnerabilidades de ProxyShell. En tales casos, normalmente se cargan webshells después de explotar estas vulnerabilidades para proporcionar persistencia en la red de la víctima. Luego, los operadores utilizaron varios implantes para obtener más capacidades.
Una vez que se obtuvo el acceso, los operadores desplegaron en la red de víctima múltiples herramientas disponibles públicamente para el reconocimiento, incluidas Mimikatz, EarthWorm, ReGeorg, y NBTscan, y luego desplegaron sus implantes personalizados: un loader de primera etapa, seguido de un loader de .NET de segunda etapa (PNGLoad ). Desafortunadamente, no hemos podido recuperar ninguno de los payloads finales. En 2021, el loader de primera etapa era un CLR en assembly (CLRLoad), mientras que en 2022 fue reemplazado, en la mayoría de los casos, por un backdoor para PowerShell con múltiples capacidades (PowHeartBeat); ambas cadenas de ejecución se muestran en la Imagen 2.
Imagen 2. Cadenas de compromiso de Worok
CLRLoad: Loader CLR en assembly
CLRLoad is a generic Windows PE that we have seen in both 32-and 64-bit versions. It is a loader written in C++ that loads the next stage (PNGLoad), which must be a Common Language Runtime (CLR) assembly DLL file. That code is loaded from a file located on disk in a legitimate directory, presumably to mislead victims or incident responders into thinking it is legitimate software.
Algunas muestras de CLRLoad comienzan descodificando la ruta completa del archivo cuyo contenido cargarán en la siguiente etapa. Estas rutas de archivo están codificadas con un XOR de un solo byte, con una clave diferente en cada muestra. Decodificadas o en texto sin formato, estas rutas de archivo son absolutas, siendo las siguientes las que hemos encontrado:
- C:\Program Files\VMware\VMware Tools\VMware VGAuth\xsec_1_5.dll
- C:\Program Files\UltraViewer\msvbvm80.dll
- C:\Program Files\Internet Explorer\Jsprofile.dll
- C:\Program Files\WinRar\RarExtMgt.dll
- C:\Program Files (x86)\Foxit Software\Foxit Reader\lucenelib.dll
A continuación, se crea un mutex y hemos visto un nombre diferente en cada muestra. El loader comprueba este mutex; si lo encuentra, sale, porque el loader ya se está ejecutando. En una de las muestras se encontró el mutex Wo0r0KGWhYGO, que le dio al grupo su nombre de Worok.
CLRLoad luego carga un CLR en assembly desde la ruta del archivo posiblemente decodificado. Como código no administrado, CLRLoad logra esto en variantes de 32 bits llamando a CorBindToRuntimeEx a través de la API de Windows, mientras que en variantes de 64 bits lo hace llamando a CLRCreateInstance.
PowHeartBeat: backdoor para PowerShell
PowHeartBeat es un backdoor con todas las funciones escrita en PowerShell, ofuscada mediante varias técnicas, como compresión, codificación y cifrado. Según la telemetría de ESET, creemos que PowHeartBeat reemplazó a CLRLoad en campañas más recientes como la herramienta utilizada para lanzar PNGLoad.
La primera capa del código del backdoor consta de varios fragmentos de código PowerShell codificado en base64. Una vez que se reconstruye el payload se ejecuta a través de IEX. Una vez decodificado, se ejecuta otra capa de código ofuscado, que podemos ver en la Figura 3.
Figura 3. Extracto de la función principal decodificada de la segunda capa de PowHeartBeat
La segunda capa del backdoor primero descifra primero en base64 la siguiente capa de su código, que luego se descifra con Triple DES (modo CBC). Después del descifrado, este código se descomprime utilizando el algoritmo gzip, lo que genera la tercera capa de código de PowerShell, que es el actual backdoor. Se divide en dos partes principales: configuración y manejo de comandos de backdoor.
La capa principal del código de backdoor también está escrita en PowerShell y usa HTTP o ICMP para comunicarse con el servidor C&C. Funciona como se muestra en la Figura 4.
Imagen 4. Funcionamiento de PowerHeartBeat.
Si quieres conocer más detalles del análisis técnico, como la configuración, la forma de cifrado de datos, cómo se lleva adelante la comunicación con el servidor de C&C, la lista de comandos que soporte el backdoor, los IoC, y detalles sobre PNGLoad, un loader utilizado en la segunda etapa de la infección que utiliza de archivos PNG para crear un payload y ejecutarlo, te invitamos a leer la versión completa en inglés.
