Variante de malware LightSpy dirigida a macOS

El 11 de abril de 2024, BlackBerry publicó un nuevo blog en el que detalla una nueva carga en VirusTotal del framework de spyware móvil LightSpy. BlackBerry afirmó que este malware era un implante para iOS; sin embargo, los investigadores de Huntress descubrieron que, aunque las muestras cargadas parecen novedosas, en realidad no atacan iOS en absoluto. Lo que se observó es una variante para macOS del malware LightSpy, de la que no se había informado anteriormente. Esta nueva capacidad demuestra que, además de los usuarios de iOS y Android, los usuarios de macOS podrían haber sido blanco de ataques.

Con base en el reporte de BlackBerry, varias publicaciones importantes, entre ellas Forbes, HackerNews y Mashable, informaron que la muestra cargada es una amenaza activa y peligrosa para iOS. Esto es incorrecto, ya que la muestra que analizó BlackBerry solo se ejecuta en dispositivos Intel con macOS, o en dispositivos con Apple Silicon que tengan Rosetta 2 habilitado.

Las publicaciones también afirmaron que esto probablemente fue lo que llevó a Apple a enviar “alertas de ataques de spyware”. Según nuestra evaluación, con base en el artículo de soporte más reciente de Apple, Acerca de las notificaciones de amenazas de Apple y la protección contra spyware mercenario, Apple se refiere al spyware Pegasus de NSO Group, más reciente y sofisticado.

También es importante señalar que, si bien pudimos encontrar la versión para Android de este malware en el mismo C2 que la versión para macOS, no parece que la versión para iOS también esté presente. En este artículo, nos centraremos únicamente en el implante para macOS. Para obtener más información sobre la versión para Android (también conocida como WyrmSpy), consulta este reporte del equipo de ThreatFabric.

Además de nuestro análisis, compartimos reglas YARA y Sigma que se pueden usar libremente para detectar el posible uso de la variante de LightSpy para macOS. El texto de todas las imágenes y capturas de pantalla de la terminal también está disponible en el repositorio de GitHub.

Gracias a los investigadores de TrendMicro, Kaspersky y ThreatFabric por su trabajo previo sobre el framework LightSpy; sus contribuciones fueron de enorme ayuda en nuestra investigación.

Análisis técnico

Confirmación de que el objetivo es macOS

Si bien existe una variante de LightSpy que afecta a los dispositivos móviles de Apple como el iPhone, cabe destacar que esta muestra solo ataca la plataforma macOS. Hay varios factores que lo respaldan, pero el principal es que todos estos binarios están compilados para la arquitectura x86_64, lo que descarta los iPhone basados en la arquitectura ARM. Esto se puede confirmar ejecutando el comando file en las muestras de macOS y de iOS.

En ambos casos, la estructura del implante es la misma: un dropper que carga una serie de módulos cargados dinámicamente (dylibs), similares a las DLL en Windows, que contienen la mayoría de las capacidades maliciosas.

Diferencias con la versión de iOS

Lo que hizo famoso a LightSpy fue una versión para iOS descubierta en 2020, documentada tanto por Kaspersky como por TrendMicro. Si bien hay muchas similitudes entre ambas, existen algunas diferencias interesantes que brindan nueva información sobre la organización detrás del framework, así como sobre sus objetivos.

En general, la versión para macOS parece más refinada que la versión para iOS. La seguridad operativa (opsec) mejoró considerablemente, las prácticas de desarrollo parecen más maduras y, en general, todo está más organizado. Un ejemplo rápido es que la versión para iOS almacena su información de C2 en texto plano:

La versión para macOS resuelve este problema usando un manifiesto de plugins, que ofrece más flexibilidad para actualizar los plugins más adelante, además de reducir las detecciones estáticas. A pesar de las diversas mejoras, LightSpy todavía deja mucho que desear en cuanto a técnicas antianálisis.

Todos los binarios, tanto de macOS como de iOS, contienen muchos artefactos del desarrollador. Si buscamos específicamente rutas de archivos, podemos obtener una idea bastante clara de cómo estaba organizado este malware.

Hay dos equipos que parecen haber participado en el desarrollo de LightSpy: mac y air. Obviamente, no hay forma de confirmar que no hubo varios equipos de desarrollo con el mismo nombre de usuario, pero esto igual ayuda a entender la organización del framework.

Etapa 1: Dropper

La primera etapa de este malware es un dropper (SHA256: afd03337d1500d6af9bc447bd900df26786ea4a4) que descarga y ejecuta la dylib principal del implante.

Verificación del archivo PID:
La versión para macOS de este malware usa un archivo de número de identificación de proceso (PID) ubicado en /Users/Shared/irc.pid para verificar que el implante no se esté ejecutando ya. Un archivo PID es simplemente un archivo que contiene el PID de un proceso en ejecución; se usa para identificar un proceso específico en ejecución y poder hacer referencia a él más adelante.

Extracción de la configuración:
La configuración de este malware se agrega al final del binario (en este caso, los últimos 0x1d0 bytes) y está cifrada con AES mediante una clave estática de 3e2717e8b3873b29.

Descarga de la etapa 2 y los plugins:
Antes de descargar los plugins del servidor C2, el dropper solicita macmanifest.json, que contiene mucha información sobre los plugins. Los MD5 corresponden a las versiones cifradas.

Verificación del payload:
Después de descargar la dylib principal responsable, se realiza otra llamada a la siguiente dirección:

Esta devuelve un blob JSON que se usa para verificar la integridad de la segunda etapa. El otro aspecto interesante que hay que señalar es la fecha, que muestra que tiene al menos tres años de antigüedad. Este periodo coincide con el descubrimiento original del malware LightSpy en 2020.

Descifrado del payload:
Los plugins y la dylib principal están cifrados con un XOR de tipo rotativo ubicado en la función _XorDecodeFile.

Por suerte, reimplementar la rutina es bastante sencillo y permite analizar fácilmente los plugins descargados.

Etapa 2: Implante

La segunda etapa (SHA256: 0f66a4daba647486d2c9d838592cba298df2dbf38f2008b6571af8a562bc306c) se encarga de cargar, mantener y usar los plugins. Durante esta etapa, el implante usa la clase DeviceInformation para consultar al dispositivo información del sistema. Recopila un conjunto estándar de información del dispositivo:

Al comparar (diff) los métodos de esa clase, se ve que la versión para macOS no recopila información que se encontraría en un teléfono, como los números de identidad internacional del abonado móvil (IMSI) o de identidad internacional de equipo móvil (IMEI). Además, al analizar funciones como getScreenSizeInches, la versión para iOS devuelve las dimensiones de los dispositivos iOS, mientras que la versión para macOS solo devuelve una única cadena, 13.3 inches.

La comunicación con el C2 todavía se realiza mediante WebSockets usando la biblioteca de código abierto SocketRocket, con toda la funcionalidad estándar que cabría esperar: envío de heartbeats, recepción de comandos, actualización del estado de los comandos, etc.

Etapa 3: Plugins

Este implante en particular descarga 10 payloads adicionales, cada uno para realizar una tarea específica. Como ya se han documentado bastante a fondo, a continuación, en los IOC, indicamos los distintos plugins (dylibs) asociados con la variante para macOS.

Conclusión

Aunque históricamente hemos visto que LightSpy ataca iOS, esta variante claramente apunta a macOS. A medida que el panorama de macOS evoluciona constantemente y los ataques dirigidos específicamente al ecosistema de Apple se vuelven más frecuentes, quisimos incluir también algunas oportunidades de detección.

También vale la pena señalar que, aunque esta muestra se cargó recientemente en VirusTotal desde India, esto no es un indicador particularmente sólido de una campaña activa ni de ataques dirigidos dentro de la región. Es un factor que contribuye, pero sin evidencia más concreta o visibilidad de los mecanismos de entrega, hay que tomarlo con mucha cautela.

Si bien no hemos hecho ninguna atribución en esta publicación, la mayoría de las investigaciones previas han asociado este malware con APT 41. Estamos seguros de que esta muestra efectivamente forma parte del framework LightSpy y no tenemos motivos para discrepar de esa atribución.

Apple, en un intento por frustrar a los actores de amenazas, ha introducido nuevas funciones en sus *OS, como el Modo de aislamiento, restricciones adicionales de TCC y módulos XProtect/XProtectRemediator en constante evolución diseñados para proteger al usuario final. También es una gran oportunidad para recordar mantener los dispositivos actualizados, sin importar la plataforma.

Apéndice A

Creamos reglas YARA que detectan el implante, el loader y las dylibs. Incluimos una regla privada que ayuda a limitar las detecciones solo a binarios Macho. Es importante tener en cuenta que, sin esa regla privada, las reglas no se ejecutarán, ya que todas verifican la presencia de un Macho en su condición. Las reglas están disponibles a continuación y en GitHub.

Reglas YARA

Regla Sigma

Apéndice B

IOCs

Infraestructura

Referencias

[1] https://blogs.blackberry.com/en/2024/04/lightspy-returns-renewed-espionage-campaign-targets-southern-asia-possibly-india

[2] https://documents.trendmicro.com/assets/Tech-Brief-Operation-Poisoned-News-Hong-Kong-Users-Targeted-with-Mobile-Malware-via-Local-News-Links.pdf

[3] https://www.threatfabric.com/blogs/lightspy-mapt-mobile-payment-system-attack

[4] https://securelist.com/ios-exploit-chain-deploys-lightspy-malware/96407/