Coruna: el framework utilizado en la operación Triangulation

Introducción

El 4 de marzo de 2026, Google y iVerify publicaron informes sobre un kit de exploits muy sofisticado dirigido a dispositivos iPhone de Apple. Según Google, este kit se descubrió por primera vez en ataques dirigidos llevados a cabo por un cliente de un proveedor de vigilancia no identificado. Posteriormente, otros atacantes lo utilizaron en ataques de watering hole en Ucrania y en campañas con motivaciones económicas en China. Además, se identificó una instancia de la versión de depuración del kit de exploits que permitió revelar los nombres internos de los exploits y el nombre del framework utilizado por sus desarrolladores: Coruna. El análisis del kit reveló que se basa en el abuso de múltiples vulnerabilidades ya corregidas mediante parches, además de incluir exploits para CVE-2023-32434 y CVE-2023-38606. Estas dos vulnerabilidades llamaron especialmente nuestra atención porque se descubrieron por primera vez como vulnerabilidades de día cero usadas en la operación Triangulation.

La operación Triangulation es una compleja campaña de amenaza persistente avanzada (APT, por sus siglas en inglés) dirigida a dispositivos iOS. Descubrimos esta operación mientras monitoreábamos el tráfico de nuestra propia red Wi-Fi corporativa. Durante este proceso, detectamos actividad sospechosa procedente de varios teléfonos con sistema operativo iOS. Nuestra investigación reveló que la campaña utilizaba un sofisticado implante de spyware y varios exploits de día cero. Durante los más de seis meses que duró la investigación, fuimos dando a conocer nuestros hallazgos sobre el ataque. Los expertos del GReAT de Kaspersky también presentaron estos hallazgos en el 37.º Chaos Communication Congress (37C3).

Aunque los detalles de CVE-2023-32434 y de CVE-2023-38606 son públicos desde hace tiempo y otros investigadores han desarrollado sus propios exploits sin acceso al código de Triangulation, decidimos realizar un análisis detallado de los exploits utilizados por Coruna. Algunos de los enlaces utilizados para distribuir el kit de exploits proporcionados por Google seguían activos al momento de la publicación del informe, lo que nos permitió recopilar, descifrar y analizar todos los componentes de Coruna.

Nuestro análisis reveló que el exploit de kernel utilizado en Coruna para abusar de las vulnerabilidades CVE-2023-32434 y CVE-2023-38606 es, en realidad, una versión actualizada del mismo exploit utilizado en la operación Triangulation. Las imágenes a continuación muestran las dos cadenas de ataque a alto nivel y destacan en rojo los exploits utilizados en cada una.

Cadena de ataque de la operación Triangulation (simplificada)

Cadena de ataque de Coruna (simplificada)

Además, descubrimos otros cuatro exploits adicionales de kernel incluidos en Coruna que no habíamos observado en la operación Triangulation. Dos de ellos fueron desarrollados después del descubrimiento de esta operación. Todos comparten código y se basan en el mismo framework de explotación del kernel, cuyas similitudes también están presentes en otros componentes de Coruna. Esto nos lleva a concluir que el kit de exploits no fue creado ensamblando componentes independientes, sino que fue desarrollado como un conjunto coherente. Creemos que se trata de una versión actualizada del mismo framework de explotación que se utilizó, al menos parcialmente, en la Operación Triangulation.

Detalles técnicos

Si bien nuestra investigación sobre los exploits y las vulnerabilidades utilizadas por Coruna continúa, en esta publicación ofrecemos una descripción general del kit de exploits y la cadena de ataque.

Safari

El ataque comienza con un stager que identifica el navegador y, en función de su versión, selecciona y ejecuta los exploits apropiados de ejecución remota de código (RCE, por sus siglas en inglés) y los exploits de autenticación de punteros (PAC, por sus siglas en inglés). El stager también contiene la URL de un archivo cifrado con información sobre los paquetes disponibles, incluidos los exploits y otros componentes, además de una clave de 256 bits utilizada para descifrarlo.

Payload

El payload se encarga de iniciar la explotación del kernel. Una vez iniciado, descarga un archivo que contiene información sobre los demás componentes del kit de exploits y lleva a cabo una serie de pasos para extraerlos, procesando para ello distintos formatos de archivo.

En primer lugar, descifra el archivo descargado mediante el cifrado de flujo ChaCha20. El resultado es un contenedor identificado por el número mágico 0xBEDF00D que almacena datos comprimidos con LZMA.

Formato de archivo usado por el kit de exploits para almacenar datos comprimidos

Los datos descomprimidos presentan otro contenedor con el número mágico 0xF00DBEEF. Este formato de archivo se usa en el kit de exploits para almacenar y recuperar archivos por sus identificadores.

A continuación, brindamos una descripción de todos los valores posibles de identificador de archivo.

Formato de archivo usado por el kit de exploits para almacenar archivos

En esta etapa, cuando el payload recopila información sobre los paquetes disponibles, el contenedor contiene un único archivo, cuyo identificador es 0x70000.

Finalmente, llegamos al archivo que contiene información sobre todos los paquetes de archivos disponibles. Este comienza con el valor mágico 0x12345678 y el kit de exploits utiliza este formato para obtener las URL y las claves de descifrado de los componentes adicionales que deben descargarse.

Formato utilizado por el kit de exploits para almacenar información sobre los paquetes de archivos

Los componentes necesarios para explotar un dispositivo específico se seleccionan mediante el identificador del paquete. Su byte de mayor peso especifica el tipo de paquete y el hardware requerido. Hemos observado los siguientes tipos de paquetes:

• 0xF2: exploit para ARM64,
• 0xF3: exploit para ARM64E,
• 0xA2: loader Mach-O para ARM64,
• 0xA3: loader Mach-O para ARM64E,
• 2: implante para ARM64,
• 0xE2: implante para ARM64E.

El código del payload también admite otros tipos de paquetes, como 0xF1, correspondiente a un exploit para dispositivos ARM antiguos que no son compatibles con arquitecturas de 64 bits. Sin embargo, los archivos correspondientes a estos exploits no fueron encontrados.

Otros bytes del identificador de paquete definen la versión de firmware compatible y la generación de la CPU.

Algunos de los identificadores de paquete observados (aquellos con contenido único)

Los archivos dentro de estos paquetes también se almacenan en contenedores 0xF00DBEEF cifrados y comprimidos, pero en este caso la compresión es opcional y viene determinada por el segundo bit del campo Flags.

Los distintos paquetes contienen diferentes conjuntos de archivos. En la siguiente tabla se ofrece una descripción de todos los identificadores de archivo posibles.

Identificadores de archivo observados

Una vez descargados los componentes necesarios, el payload comienza a ejecutar los exploits del kernel, los loaders Mach-O y el launcher del malware. Para ello, selecciona el loader Mach-O adecuado en función de la versión de firmware, el procesador y la presencia del permiso iokit-open-service.

Exploits del kernel

Analizamos los cinco exploits de kernel del kit y descubrimos que uno de ellos es una versión actualizada del mismo exploit que identificamos en la operación Triangulation. Si bien presenta numerosos cambios menores, los más relevantes son los siguientes:

• El código tiene en cuenta más valores de las cadenas de versión de XNU, lo que permite una comprobación de versión más precisa.
• Se agregó una verificación para iOS 17.2. Consideramos que esta era la versión más reciente de iOS al momento del desarrollo, ya que fue lanzada en diciembre de 2023.
• Se agregaron verificaciones para los procesadores más nuevos de Apple: A17, M3, M3 Pro, M3 Max, lanzados en 2023.
• Se añadió una comprobación para iOS 16.5 beta 4, versión que corrigió la vulnerabilidad tras nuestro informe a Apple.

¿Por qué este exploit necesita comprobar la presencia de procesadores iOS 17.2 o posteriores si las vulnerabilidades que abusa se corrigieron en iOS 16.5 beta 4? La respuesta se puede encontrar al examinar los otros exploits: todos se basan en el mismo código fuente. La única diferencia radica en las vulnerabilidades que explotan. Por lo tanto, estas comprobaciones se incorporaron para dar soporte a los exploits más recientes y quedaron presentes en la versión anterior tras volver a compilarla.

Launcher

El launcher se encarga de orquestar las actividades posteriores a la explotación y utiliza el exploit de kernel y la interfaz que este proporciona. Sin embargo, dado que durante la ejecución del exploit se crean objetos especiales en el kernel que permiten leer y escribir en su memoria, el launcher simplemente reutiliza estos objetos, sin necesidad de volver a desencadenar las vulnerabilidades ni repetir todo el proceso de explotación.

A continuación, el launcher elimina los artefactos de la explotación, obtiene de una configuración el nombre del proceso objetivo para la inyección, identificada por el número mágico 0xDEADD00F, e inyecta un stager en dicho proceso. Este se utiliza para ejecutar el propio launcher y, finalmente, iniciar el implante.

Conclusiones

Este caso vuelve a poner de manifiesto los riesgos asociados con este tipo de herramientas maliciosas, especialmente por su potencial de reutilización y distribución a gran escala. Desarrollado originalmente para operaciones de ciberespionaje, este framework también ha comenzado a ser utilizado por otros actores de amenazas, lo que amplía el número de usuarios que podrían verse afectados, especialmente aquellos cuyos dispositivos no cuentan con las últimas actualizaciones de seguridad.

Su diseño modular y la facilidad con la que puede reutilizarse podría favorecer su adopción por parte de otros actores maliciosos. Por este motivo, recomendamos instalar las últimas actualizaciones de seguridad lo antes posible.