El kit que cambió de manos tres veces en un año
A principios de 2025, se observó que un cliente de un proveedor comercial de software de vigilancia no identificado utilizaba un framework de exploits JavaScript previamente desconocido contra dispositivos iOS. En julio de 2025, un grupo de espionaje ruso sospechoso había adoptado el mismo framework y lo inyectaba silenciosamente en sitios web industriales y minoristas ucranianos como un iframe oculto. En diciembre de 2025, un actor de amenazas chino con motivación financiera lo desplegó en una red de sitios falsos de criptomonedas y apuestas sin restricciones geográficas, apuntando a cualquier usuario de iPhone que hiciera clic en el enlace equivocado. Dicho de otro modo: la misma herramienta poderosa pasó del espionaje al crimen financiero en cuestión de meses, adaptándose a distintos objetivos y blancos. Por ejemplo, el sitio web de una empresa energética ucraniana fue comprometido para distribuir cargas útiles de espionaje, mientras que más adelante, un sitio falso de intercambio de criptomonedas engañó a usuarios de todo el mundo para infectarlos.
El Grupo de Inteligencia de Amenazas de Google (GTIG) nombró públicamente este framework Coruna (también rastreado como CryptoWaters) el 4 de marzo de 2026. Contiene cinco cadenas de exploits completas para iOS y 23 exploits individuales que abarcan las versiones de iOS 13 a 17.2.1. iVerify lo calificó como "la primera explotación masiva observada contra dispositivos iOS" y señaló similitudes estructurales con herramientas desarrolladas por actores de amenazas vinculados al gobierno de EE. UU. Esto es relevante porque dichas similitudes estructurales sugieren la reutilización o adaptación de técnicas sofisticadas de nivel gubernamental en manos criminales, lo que eleva el nivel de riesgo para los defensores. En la práctica, esto significa que los atacantes ya no se limitan a exploits básicos: ahora emplean métodos avanzados que antes estaban reservados para operaciones de estados-nación.
Obtuvimos muestras en vivo de dominios de distribución activos y analizamos cada capa del JavaScript. Lo que sigue es un relato detallado de lo que hace este kit, desde la primera línea de código ofuscado hasta el binario Mach-O cifrado que se deposita en el dispositivo de la víctima, junto con un análisis completo de la infraestructura de dominios e IPs involucrados. Este análisis en profundidad revela no solo la mecánica técnica, sino también la huella operativa detrás de Coruna. Por ejemplo, rastreamos cómo la carga útil JavaScript del exploit se transforma dinámicamente durante la ejecución, evadiendo la detección mientras mantiene estabilidad en distintas versiones de iOS.
El problema de la distribución: por qué tu sitio web es la superficie de ataque
Antes de entrar en la mecánica del exploit, vale la pena aclarar qué significa "distribución" en este contexto, porque muchas organizaciones no han considerado completamente este aspecto. La distribución es el método por el cual el exploit llega al dispositivo de la víctima, a menudo a través de una página web aparentemente inofensiva.
Coruna se distribuye como un archivo HTML autocontenido, normalmente llamado group.html o analytics.html, incrustado como un `
Redes publicitarias. Un único creativo malicioso distribuido a través de una red publicitaria programática llega a todos los editores que ejecutan la etiqueta de esa red. El servidor del editor nunca toca la carga útil. El WAF del editor nunca la ve. El equipo de seguridad del editor no tiene visibilidad sobre lo que la etiqueta publicitaria cargó en el navegador del usuario. Si Coruna se hubiera distribuido a través de una red publicitaria de nivel medio, habría llegado a millones de usuarios de Safari en miles de sitios web legítimos y de buena reputación simultáneamente. Ninguno de esos editores lo habría sabido. Por ejemplo, imagina una red publicitaria sirviendo un banner malicioso en un sitio de noticias popular, y cada visitante podría haber quedado expuesto sin que el sitio lo supiera.
Scripts de terceros comprometidos. El sitio de comercio electrónico o medios de comunicación promedio carga entre 30 y 50 etiquetas JavaScript de terceros: analíticas, widgets de chat, herramientas de pruebas A/B, rastreadores de afiliados, gestores de consentimiento. Cada uno de esos scripts es un punto de inyección potencial. Un compromiso en la cadena de suministro de cualquiera de ellos, como las campañas de Magecart o el incidente de polyfill[.]io, podría haber convertido cada sitio que usara ese script en un nodo de distribución de Coruna. De nuevo, el servidor de origen no mostraría nada inusual. La carga útil se ejecuta en el navegador del usuario y reporta a un dominio C2 del que el editor nunca ha oído hablar. Dicho de otro modo: incluso un proveedor de scripts de confianza puede convertirse en un caballo de Troya si es comprometido. Por ejemplo, si el script de un proveedor de analíticas popular fuera secuestrado, miles de sitios web podrían distribuir Coruna sin saberlo.
Activos de CDN en caché. Varias de las URLs de distribución que identificamos se servían desde infraestructura CDN compartida (tubeluck[.]com, 668ddf[.]cc). Un atacante con acceso de escritura a un bucket de origen de CDN o con capacidad para envenenar una caché de CDN obtiene el mismo resultado. Por ejemplo, si un atacante logra subir un archivo malicioso a un bucket de CDN utilizado por varios sitios, puede distribuir exploits silenciosamente a todos los visitantes de esos sitios. Este escenario se ha dado en ataques anteriores donde los atacantes envenenaron cachés de CDN ampliamente utilizadas para propagar malware rápidamente.
La cuestión no es que estos vectores específicos hayan sido utilizados. La cuestión es que nada en la carga útil de Coruna requiere que el atacante sea propietario del sitio de distribución. La carga útil es un archivo JavaScript. Va donde va el JavaScript. Y el JavaScript va a todas partes.
Cómo llega al navegador: infraestructura de distribución
Las campañas que analizamos utilizaron más de 50 dominios de distribución, organizados en temáticas de señuelo reconocibles.
| Clúster | Dominios representativos | Temática del señuelo |
|---|---|---|
| CDN 668ddf[.]cc | osec2[.]668ddf[.]cc, 65sse[.]668ddf[.]cc, ose[.]668ddf[.]cc | Hosting compartido chino |
| Juegos / apuestas | 7p[.]game, 4u[.]game, b27[.]icu, h4k[.]icu, spin7[.]icu, seven7[.]vip | Apuestas en línea |
| Señuelos de bingo | land[.]77bingos[.]com, land[.]bingo777[.]now, land[.]777bingos[.]xyz | Apuestas de bingo |
| Señuelos de criptomonedas | goodcryptocurrency[.]top, binancealliancesintro[.]com, pepeairdrop01[.]com | Criptomonedas |
| CDN Tubeluck | w2a315[.]tubeluck[.]com, so5083[.]tubeluck[.]com | Infraestructura CDN compartida |
| Señuelos de analíticas | ai-scorepredict[.]com, goanalytics[.]xyz | Páginas de analíticas falsas |
Muchos de estos sitios indican explícitamente a los usuarios que visiten desde un dispositivo móvil para una "mejor experiencia", un empujón de ingeniería social para asegurarse de que el objetivo abra la página en Safari en iOS en lugar de en un navegador de escritorio. Esta táctica aumenta la probabilidad de que el exploit se ejecute con éxito, ya que apunta a versiones específicas de iOS. Por ejemplo, un sitio falso de bingo podría mostrar un popup que diga: "Para la mejor experiencia, abre esta página en tu iPhone", llevando a las víctimas al entorno adecuado.
Análisis de infraestructura: DNS, rDNS, WHOIS y alojamiento
Realizamos resolución DNS completa, búsquedas de DNS inverso, consultas de registro WHOIS/RDAP y pivotes de IP en todos los dominios de distribución y C2. Los resultados revelan una estrategia de infraestructura deliberada: abuso de los principales CDN en la nube para ocultar el origen real, un número reducido de IPs dedicadas para los sitios señuelo más sensibles, y patrones de registro que se agrupan estrechamente en torno a finales de 2025 y principios de 2026. Esta coordinación sugiere una campaña bien planificada en lugar de actividad oportunista aleatoria.
Desglose del alojamiento
La infraestructura de distribución se divide en cuatro niveles de alojamiento diferenciados.
Nivel 1: Proxy de Cloudflare. La mayor parte de los dominios de distribución de juegos de azar y gaming, incluyendo 7p[.]game, b27[.]icu, h4k[.]icu, spin7[.]icu, 7ff[.]online, 26a[.]online, tubeluck[.]com, ai-scorepredict[.]com y dbgopaxl[.]com, resuelven a IPs anycast de Cloudflare. Cloudflare proporciona protección DDoS, terminación TLS y ocultación efectiva de la IP de origen. Los servidores backend reales no son visibles desde el DNS. Esta configuración permite a los atacantes enmascarar su infraestructura real detrás de un servicio de buena reputación, complicando los esfuerzos de eliminación. Dicho de otro modo: Cloudflare actúa como un escudo, dificultando el rastreo de los servidores reales de los atacantes.
Nivel 2: AWS CloudFront. Un segundo clúster amplio utiliza AWS CloudFront como capa CDN. Los dominios 4u[.]game, seven7[.]vip, seven7[.]to, 4kgame[.]us, 7uspin[.]us, n49[.]top, 98a[.]online, cy8[.]top, 7fun[.]icu, k96[.]icu, t7c[.]icu, y4w[.]icu, y el clúster de bingo (land[.]77bingos[.]com, land[.]bingo777[.]now, land[.]777bingos[.]xyz) resuelven todos a nodos edge de CloudFront. El clúster de bingo comparte un único conjunto de cuatro IPs de CloudFront, lo que indica que se sirven desde la misma distribución y probablemente desde el mismo origen S3 o EC2. Esta consolidación ayuda a los atacantes a gestionar eficientemente múltiples señuelos manteniendo la resiliencia. Por ejemplo, si un dominio es eliminado, los demás siguen operativos, garantizando la distribución continua.
Nivel 3: IPs dedicadas en alojamiento tolerante al abuso. El hallazgo operativamente más significativo es el uso de IPs dedicadas en proveedores de alojamiento conocidos por su tolerancia al abuso para los sitios señuelo más sensibles. cryptocurrencyworld[.]top y bestcryptocurrency[.]top comparten una única IP dedicada: 95.214.181.109, registrada en Datacamp Limited en Hong Kong (AS212238), un proveedor de alojamiento a prueba de balas bien documentado. Estos dos dominios son los únicos en esa IP. mkkku[.]com resuelve a 185.53.179.128 (Team Internet AG, Alemania). El DNS inverso de esa IP reveló siete dominios de apuestas adicionales en el mismo servidor: bet247[.]ac, gem88[.]ac, gemwin[.]ac, gunbet[.]ac, i9-bet[.]ac, sbet[.]ac y taisunwin[.]ac, todos coherentes con la temática general de distribución de Coruna. btrank[.]top resuelve a una instancia dedicada de AWS EC2 en Tokio (54.248.167.86). ddus17[.]com resuelve a 103.110.221.8 (JT Telecom International, Japón) sin dominios co-alojados, coherente con un servidor dedicado. Este nivel muestra cómo los atacantes equilibran el ocultamiento con el control operativo. En otras palabras, utilizan hosts a prueba de balas donde pueden operar libremente, mientras siguen aprovechando los servicios en la nube para escalar.
Nivel 4: China Unicom. pc6[.]com, un gran portal chino de descarga de software listado entre las URLs de distribución, resuelve a nueve IPs en la red troncal de China Unicom (AS4837). Los pivotes de DNS inverso en estas IPs devolvieron cientos de dominios co-alojados cada uno, todos con nombres en chino y TLDs .cn, .cc y .cloud. Esto es coherente con un entorno de alojamiento compartido de gran escala. La URL de distribución de pc6[.]com probablemente representa una página comprometida en un sitio legítimo existente en lugar de infraestructura propia de los atacantes. Este ejemplo ilustra cómo los atacantes explotan plataformas legítimas para distribuir sus cargas útiles. Por ejemplo, un popular portal chino de software podría alojar iframes maliciosos sin saberlo, poniendo en riesgo a millones de usuarios.
Cronología de registro WHOIS
Los datos de registro RDAP se obtuvieron con éxito para un subconjunto de dominios de distribución. Las fechas se agrupan estrechamente, confirmando una campaña de registro coordinada. Por ejemplo, muchos dominios fueron registrados con días o semanas de diferencia entre sí a finales de 2025 y principios de 2026, lo que sugiere un despliegue planificado en lugar de adquisiciones de dominios aleatorias. Este patrón indica que los atacantes prepararon su infraestructura cuidadosamente, en lugar de improvisar sobre la marcha.
| Dominio | Registrado | Registrador | Servidores de nombres |
|---|---|---|---|
| ai-scorepredict[.]com | 2026-01-29 | Ultahost, Inc. | Cloudflare |
| pepeairdrop01[.]com | 2026-01-25 | Realtime Register B.V. | Suspendido (verificación pendiente) |
| binancealliancesintro[.]com | 2026-01-01 | GoDaddy.com, LLC | GoDaddy (ns37/ns38.domaincontrol.com) |
| mkkku[.]com | 2026-01-18 | Dynadot Inc | Dynadot (dyna-ns.net) |
| ddus17[.]com | 2026-01-23 | Hello Internet Corp | JT DNS (jtdnsv1.com) |
| appstoreconn[.]com | 2025-12-23 | Cloudflare, Inc. | Cloudflare |
| tubeluck[.]com | 2025-12-18 | Cloudflare, Inc. | Cloudflare |
| 77bingos[.]com | 2025-11-29 | NameCheap, Inc. | AWS Route 53 |
| dbgopaxl[.]com | 2024-04-07 | Cloudflare, Inc. | Cloudflare |
Todas las fechas de registro confirmadas se sitúan entre noviembre de 2025 y enero de 2026, una ventana ajustada de 10 semanas que se alinea perfectamente con la escalada observada de la campaña, desde el espionaje dirigido hasta la explotación financiera masiva. Esto es relevante porque un período de registro tan concentrado sugiere un esfuerzo coordinado para desplegar infraestructura rápidamente. Por ejemplo, pepeairdrop01[.]com está actualmente suspendido por su registrador debido a un fallo en la verificación del dominio, lo que indica presión activa de eliminación por parte de los defensores. Dicho de otro modo: este dominio probablemente fue marcado y desconectado rápidamente para interrumpir las operaciones de la campaña. Por su parte, dbgopaxl[.]com destaca como un caso atípico, registrado en abril de 2024. Esto sugiere que podría ser un activo preposicionado, configurado meses antes para uso futuro, o quizás un dominio legítimo que fue comprometido y reutilizado para esta campaña.
Los dominios C2, los 27 dominios .xyz generados por DGA, devolvieron errores 404 del servidor RDAP. Esto significa que han sido eliminados del registro o que nunca fueron registrados bajo una ruta consultable por RDAP estándar. Lo que esto significa en la práctica: estos dominios actúan como dominios de respaldo de corta duración generados algorítmicamente. Los operadores los registran y descartan de forma rotativa para adelantarse a los esfuerzos de eliminación y evitar la detección. Por ejemplo, si un dominio es bloqueado por los defensores, otro puede tomar su lugar rápidamente sin ninguna intervención manual, manteniendo la resiliencia de la infraestructura de mando y control.
Transparencia de certificados
Los registros de transparencia de certificados nos proporcionan una cronología independiente de cuándo los dominios comenzaron a usar HTTPS. Los hallazgos clave incluyen: b27[.]icu emitió su primer certificado TLS el 2025-06-01 (Amazon CA), confirmando que el dominio estaba activo al menos seis meses antes del pico de la campaña. Esta actividad temprana sugiere que pudo haberse utilizado para pruebas iniciales o reconocimiento. Otro ejemplo es 7p[.]game, que apareció por primera vez en los registros CT el 2024-03-21 (GoDaddy CA). Es el más antiguo del conjunto de distribución, lo que implica que es una operación de apuestas de larga trayectoria que adoptó la distribución de Coruna en lugar de ser un sitio señuelo creado específicamente para ello. ai-scorepredict[.]com emitió su primer certificado el 2026-01-29, exactamente el mismo día que su fecha de registro RDAP, confirmando que fue creado específicamente para esta campaña. Por último, tubeluck[.]com apareció por primera vez en los registros CT en 2019, lo que lo convierte en el dominio más antiguo de todo el conjunto de datos. Esto indica que es un servicio CDN o de alojamiento consolidado desde hace tiempo que el operador utiliza como infraestructura, probablemente para mezclar tráfico malicioso con contenido legítimo.
Infraestructura de dominios C2
Los 27 dominios C2 generados por DGA no devuelven actualmente ningún registro DNS A, lo que significa que no resuelven a ninguna dirección IP. Dos dominios, vvri8ocl4t3k8n6[.]xyz y rlau616jc7a7f7i[.]xyz, tenían entradas en URLScan del 4 de marzo de 2026, el día de la divulgación por parte de GTIG. Ambos resolvían a IPs de Cloudflare en ese momento. Esto confirma que la infraestructura C2 estaba activa y con fronting de Cloudflare el día de la divulgación. Desde entonces, la infraestructura ha sido eliminada o rotada a nuevos dominios. Es como cambiar las cerraduras tras un robo: los operadores trasladaron rápidamente su mando y control para evitar interrupciones y la detección por parte de los defensores.
Cuatro capas de ofuscación antes de ver un solo exploit
Abrir la página de entrega en un editor de texto no revela nada útil a primera vista. El framework Coruna utiliza una sofisticada arquitectura de ofuscación de cuatro capas diseñada específicamente para eludir herramientas de análisis estático y sandboxes automatizados. Esto significa que incluso los analistas con experiencia se enfrentan a un reto considerable solo para entender qué hace el código.
Capa 0: el bootstrap externo
El HTML de entrega contiene un bootstrap JavaScript mínimo. Cada cadena de texto significativa está oculta como un array de enteros decodificados mediante XOR en tiempo de ejecución. Por ejemplo:
[107, 49, 105, 97].map(x => String.fromCharCode(x ^ 84)).join("")
Aquí, cada entero se somete a XOR con la clave 84 para revelar el carácter real. La clave XOR varía por cadena, por lo que no existe un patrón único que coincida en todo el archivo. La lógica principal se oculta dentro de new Function(atob("..."))(): una cadena codificada en Base64 que se evalúa como una nueva función. Esto mantiene el código real fuera del árbol de análisis inicial y de la mayoría de los escáneres estáticos. En otras palabras, el código está bloqueado tras un rompecabezas que solo se revela en tiempo de ejecución, lo que hace que el análisis estático sea prácticamente imposible.
Capa 1: el despachador de módulos
Tras decodificar la Capa 0, se obtiene un objeto JavaScript registrado como globalThis.vKTo89. Este objeto contiene una implementación completa de SHA-256 y una tabla de búsqueda de módulos de exploit indexados por sus hashes SHA1. El despachador expone cinco funciones de API:
| Función | Propósito |
|---|---|
WLEBfI(url) |
Establece la URL base para la obtención remota de módulos |
ksQccv(salt) |
Establece el salt HMAC para la derivación del nombre de archivo del módulo |
OLdwIx(hash) |
Carga un módulo por hash SHA1 desde la caché local |
LBrh4t(hash) |
Obtiene y ejecuta un módulo remoto de forma asíncrona |
tI4mjA(hash, b64) |
Registra un módulo en línea por hash y código Base64 |
La función LBrh4t implementa un protocolo de entrega de módulos con clave. Dado un ID de hash de módulo, calcula SHA256(salt + hash_id).substring(0, 40) y solicita al servidor el nombre de archivo resultante. El salt observado en las muestras analizadas es cf40de81867d2397. Sin conocer el salt, un analista no puede predecir qué nombres de archivo solicitar, aunque conozca los IDs de hash de los módulos. La URL base se deriva de location.href.slice(0, lastIndexOf("/") + 1), lo que significa que todos los módulos de exploit se sirven desde el mismo dominio que la página de entrega. Esta configuración dificulta que los defensores intercepten o predigan las solicitudes de módulos, ocultando eficazmente los próximos movimientos del atacante.
Capa 2: código de módulo
Cada módulo se almacena como una cadena codificada en Base64. Una vez decodificado, el JavaScript del módulo sigue utilizando arrays de cadenas codificadas con XOR para todos los literales sensibles: rutas de framework, nombres de API, direcciones de memoria, constantes de versión. Esta ofuscación por capas garantiza que, aunque se decodifique una capa, los datos sensibles permanezcan ocultos, obligando a los analistas a despelar múltiples capas antes de comprender el payload.
Capa 3: payloads binarios en línea
Los módulos más grandes incrustan sus payloads binarios como cadenas codificadas en Base64 dentro del JavaScript. El shellcode ARM64 se almacena como binario sin procesar. El binario Mach-O se almacena con cada byte relleno con ceros hasta dos bytes (codificación UTF-16LE), añadiendo una capa adicional de ofuscación contra la detección de firmas binarias. Es como envolver un paquete dos veces para dificultar su identificación. Este ingenioso truco ayuda al malware a evadir las herramientas de detección basadas en firmas.
Medidas anti-análisis
El framework implementa varias comprobaciones activas anti-análisis antes de ejecutar cualquier código de exploit. Se interrumpe si se detecta el Modo de Aislamiento de Apple. Omite la ejecución en modo de navegación privada. Verifica la presencia de un motor de renderizado WebKit real creando un elemento `mathcolor="blue" se renderiza como rgb(0, 0, 255). También comprueba la disponibilidad de RTCPeerConnection para confirmar que se trata de un entorno de navegador genuino y no de un sandbox sin interfaz gráfica. Tras la ejecución, informa del resultado al C2 mediante una solicitud GET a <base_url>?e=<code>, donde 0 significa éxito, 1000 significa fallo del exploit, 1001 significa que la versión del objetivo no está soportada y 1003 significa que se detectó un sandbox. Estas comprobaciones ayudan al malware a evitar ejecutarse en entornos donde podría ser analizado o fallar, aumentando las probabilidades de una explotación exitosa.
La cadena de exploit: seis fases desde la carga de la página hasta el Mach-O
Fase 1: fingerprinting del objetivo
El módulo de fingerprinting se ejecuta primero y decide si el objetivo merece ser atacado y qué cadena de exploit utilizar. El script comprueba la cadena User-Agent en busca de Version/ (presente en todos los UAs de Safari) y AppleWebKit/. Si no se encuentra ninguno, se detiene de inmediato. A continuación, distingue iOS de macOS Safari mediante una combinación de typeof TouchEvent !== "undefined" y una prueba de inserción de Blob en IndexedDB. Concretamente, intentar almacenar un objeto Blob en IndexedDB lanza la excepción "BlobURLs are not yet supported" en iOS Safari, lo que sirve como fingerprint de plataforma fiable.
La parte técnicamente más sofisticada del fingerprinting es un oráculo de memoria WebAssembly. El script instancia una WebAssembly.Table y una WebAssembly.Instance, y luego lee las etiquetas de tipo de celda JSC (JavaScriptCore) internas desde la memoria. El valor de etiqueta 0x10016 indica macOS Safari; 0x10017 indica iOS Safari. Esta técnica lee la representación interna de objetos de JavaScriptCore directamente desde la memoria, lo que requiere un conocimiento profundo del código fuente de WebKit. La versión de iOS se extrae del User-Agent y se compara con una tabla de búsqueda de 19 versiones de iOS conocidas (de la 10.0.0 a la 17.0.0) y 13 versiones de macOS Safari, con rutas de exploit separadas seleccionadas para iOS 13 a 15.x e iOS 16.x en adelante. Este fingerprinting preciso garantiza que la cadena de exploit se ajuste perfectamente al entorno del objetivo, aumentando las probabilidades de éxito.
Fase 2: ejecución remota de código mediante confusión de tipos JIT (CVE-2024-23222)
La cadena de exploit principal en las muestras analizadas es cassowary, que apunta a CVE-2024-23222, un bug de confusión de tipos en JavaScriptCore parcheado por Apple en enero de 2024 con iOS 17.3.
El exploit comienza llamando a una función exactamente 1.000.000 de veces con argumentos de punto flotante. Esto obliga al compilador JIT de JSC a especializar la función para operaciones con arrays de floats, generando código máquina optimizado que asume que cada elemento del array siempre será un float de doble precisión. Una vez producida la compilación JIT, el exploit reemplaza un elemento del array objetivo con un objeto JavaScript en lugar de un float. El código compilado por JIT lee este valor como un float, interpretando el puntero del objeto como un double de 64 bits. Esta es la confusión de tipos: JSObject* está siendo tratado como double. Al leer de vuelta el valor float confundido, el exploit recupera la dirección del objeto en el heap de JSC. Este es el primitivo addrof.
La operación inversa, escribir un float manipulado en el array, hace que JSC interprete el double como un puntero a objeto, creando un primitivo fakeobj que apunta a memoria controlada por el atacante. Usando addrof y fakeobj juntos, el exploit construye un objeto ArrayBuffer falso cuyo puntero de almacenamiento de respaldo apunta a una dirección arbitraria. Leer o escribir a través de este ArrayBuffer falso proporciona lectura/escritura arbitraria completa de la memoria del proceso. El exploit estabiliza este primitivo mediante heap spraying con arrays de 16 elementos de valores float específicos y una clase de abstracción de enteros de 64 bits personalizada. Esta combinación permite al atacante manipular la memoria a voluntad, un paso crítico para la explotación posterior.
Fase 3: eludir ASLR mediante el escaneo de la caché compartida de dyld
Con la lectura/escritura arbitraria establecida, el exploit escanea la memoria del proceso en busca de la caché compartida de dyld para eludir ASLR. En iOS, localiza WebCore, CoreUtils e IOKit escaneando sus cabeceras de segmento __TEXT. En macOS, apunta a CoreFoundation, CoreGraphics, ActionKit y RESync. El exploit lee las cabeceras de segmento __TEXT de cada framework para determinar sus direcciones de carga, y localiza _ZN3JSC16jitOperationListE para encontrar regiones de memoria ejecutable asignadas por JIT. Este paso es crucial porque ASLR aleatoriza las ubicaciones de memoria, y conocer estas direcciones permite al exploit ejecutar código de forma fiable.
Fase 4: escapar del sandbox
El módulo de escape del sandbox combina dos técnicas. Un exploit del filtro SVG `pthread_main_thread_np, una API privada de macOS e iOS, para manipular el almacenamiento local del hilo y obtener acceso al contexto de ejecución del hilo principal, que tiene privilegios de sistema más amplios que el hilo del renderizador. Dicho de otro modo: escapar del sandbox es como salir de una habitación cerrada con llave para acceder a todo el edificio.
Fase 5: eludir la autenticación de punteros en Apple Silicon
En dispositivos Apple Silicon (todos los iPhone desde el XR y todos los Mac con chip de la serie M), el exploit debe eludir los Pointer Authentication Codes (PAC), el mecanismo de integridad de flujo de control impuesto por hardware de Apple. El módulo stager de macOS contiene los siguientes símbolos C++ internos de JSC:
_ZN3JSC20SecureARM64EHashPins27allocatePinForCurrentThreadEv
_ZN3JSC10LinkBuffer8linkCodeERNS_14MacroAssemblerENS_20JITCompilationEffortE
_ZN3WTF13MetaAllocator8allocateEmPv
jitCagePtr
El exploit abusa de jitCagePtr y SecureARM64EHashPins para asignar memoria ejecutable dentro de la jaula JIT y firmar el shellcode ARM64 con una firma PAC válida. Esto permite que código nativo no firmado se ejecute en hardware con PAC. La técnica asigna 40 MB de memoria con new Uint32Array(10000000) y rellena la memoria JIT con patrones predecibles mediante un JIT spray de sentencias x += 1 repetidas. Este enfoque engaña al hardware para que confíe en el código malicioso, eludiendo las protecciones PAC.
Fase 6: ejecución del shellcode y entrega del payload
Los módulos stager finales contienen tres componentes binarios incrustados:
| Componente | Tamaño | Formato | Propósito |
|---|---|---|---|
| Shellcode ARM64 | 31.308 bytes | Binario sin procesar | Ejecución de código nativo en la Etapa 1 |
| Mach-O cifrado | 14.954 bytes | Binario con relleno UTF-16LE | Binario nativo de la Etapa 2 |
| PlasmaLoader | ~1.324 bytes (cifrado) | .min.js obtenido remotamente |
Implante final |
El shellcode ARM64 comienza con el prólogo de función estándar STP X29, X30, [SP, #-16]! y se inyecta en memoria ejecutable asignada por JIT. Utiliza dlsym contra /usr/lib/system/libdyld.dylib para resolver funciones del sistema en tiempo de ejecución, evitando importaciones estáticas. El binario Mach-O hace referencia a frameworks privados de iOS, entre ellos SpringBoard, PassKitCore, CoreML, MediaToolbox y AppleMediaServices. Esto indica capacidades a nivel de sistema como acceso al llavero, enumeración de aplicaciones instaladas y manipulación de la pantalla de inicio. El payload final, PlasmaLoader (también denominado PLASMAGRID por Google GTIG), se obtiene del dominio de entrega como un archivo .min.js cifrado. Decodifica códigos QR de imágenes, obtiene módulos adicionales del C2 y exfiltra datos de carteras de criptomonedas de carteras populares como MetaMask, Exodus, Bitget Wallet y Base. Esto pone de manifiesto la clara motivación financiera de la campaña y su sofisticado enfoque hacia activos de alto valor.
Veintitrés exploits, cinco cadenas, cuatro años de CVEs
La cadena cassowary es una de las doce cadenas de exploit con nombre dentro de Coruna. El kit completo cubre iOS 13 hasta 17.2.1 sin lagunas. Esta cobertura completa significa que los atacantes pueden apuntar prácticamente a cualquier dispositivo que ejecute estas versiones de iOS, dejando pocos refugios seguros para las posibles víctimas.
| Cadena | CVE | Versiones de iOS objetivo | Tipo de exploit |
|---|---|---|---|
| Neutron | CVE-2020-27932 | 13.x | Confusión de tipos en el kernel |
| Dynamo | CVE-2020-27950 | 13.x | Divulgación de memoria del kernel |
| buffout | CVE-2021-30952 | 13.0 a 15.1.1 | Desbordamiento de enteros en WebKit |
| jacurutu | CVE-2022-48503 | 15.2 a 15.5 | Confusión de tipos en WebKit |
| IronLoader | CVE-2023-32409 | 16.0 a 16.4 | Escape del sandbox de WebKit |
| Photon | CVE-2023-32434 | 14.5 a 15.7.6 | Desbordamiento de enteros en XNU (Operación Triangulación) |
| Gallium | CVE-2023-38606 | 14.x | Escritura OOB en IOKit (Operación Triangulación) |
| Parallax | CVE-2023-41974 | 16.4 a 16.7 | Use-after-free en WebKit |
| terrorbird | CVE-2023-43000 | 16.2 a 16.5.1 | Use-after-free en WebKit |
| cassowary | CVE-2024-23222 | 16.6 a 17.2.1 | Confusión de tipos en WebKit (cadena principal) |
| Sparrow | CVE-2024-23225 | 17.0 a 17.3 | Corrupción de memoria del kernel |
| Rocket | CVE-2024-23296 | 17.1 a 17.4 | Corrupción de memoria en RTKit |
Dos de estas cadenas, Photon y Gallium, explotan vulnerabilidades utilizadas previamente como zero-days en la Operación Triangulación, la sofisticada campaña de espionaje en iOS documentada por Kaspersky en 2023. Su reutilización en una campaña criminal con motivación financiera ilustra directamente cómo las herramientas ofensivas de estados-nación se incorporan al ecosistema de amenazas más amplio una vez que los CVEs subyacentes se hacen públicos. Por ejemplo, tras la divulgación de estos CVEs, grupos criminales los adoptaron rápidamente para atacar a usuarios comunes con fines lucrativos, convirtiendo herramientas de espionaje avanzadas en malware de uso masivo. El 5 de marzo de 2026, CISA añadió CVE-2021-30952, CVE-2023-41974 y CVE-2023-43000 a su catálogo de Vulnerabilidades Explotadas Conocidas con un plazo de remediación del 26 de marzo de 2026 para las agencias federales. Esto subraya la urgencia de aplicar parches a estas vulnerabilidades para prevenir su explotación y proteger la infraestructura crítica.

La arquitectura de módulos al completo
[Página de entrega: group.html / analytics.html]
|
+-- Capa 0: Bootstrap (JS ofuscado con XOR)
| +-- Inicializa el despachador globalThis.vKTo89
|
+-- Capa 1: Objeto MM (Base64 -> JS)
| +-- Módulo 1ff010bb: Biblioteca matemática/utilitaria
| | +-- SHA256, aritmética BigInt, análisis de URLs
| +-- Módulo 6b57ca33: Motor de fingerprinting
| +-- Análisis de UA, detección de plataforma
| +-- Oráculo de memoria WebAssembly (etiquetas de celda JSC 0x10016/0x10017)
| +-- Prueba de Blob en IndexedDB (detección de iOS)
| +-- Prueba de renderizado MathML
| +-- Comprobación de entorno WebRTC
|
+-- Módulos remotos (obtenidos mediante URLs con clave SHA256)
+-- 8dbfa3fd: Exploit de confusión de tipos JIT (addrof/fakeobj)
+-- 55afb1a6: Primitiva de lectura/escritura arbitraria (ArrayBuffer falso)
+-- 5264a069: Variante de exploit basada en WebAssembly
+-- 166411bd: Spray JIT de WebAssembly / primitiva BigUint64Array
+-- d6cb72f5: Exploit del compilador JIT (calentamiento de 1M de iteraciones)
+-- dbfd6e84: Escape de sandbox (feConvolveMatrix + pthread)
|
+-- [Ruta iOS] bcb56dc5: Escáner de caché compartida dyld de iOS
| +-- Localizador de frameworks WebCore, IOKit, CoreUtils
|
+-- [Ruta macOS] 2d2c721e: Escáner de caché compartida dyld de macOS
| +-- Localizador de CoreFoundation, CoreGraphics, ActionKit
|
+-- [Stager iOS] 164349160: Stager de payload para iOS
| +-- Shellcode ARM64 (31.308 bytes)
| +-- Binario Mach-O cifrado (14.954 bytes)
|
+-- [Stager macOS] 6241388a: Stager de payload para macOS
+-- Shellcode ARM64 (31.308 bytes)
+-- Binario Mach-O cifrado (14.954 bytes)
+-- Bypass de PAC (jitCagePtr, SecureARM64EHashPins)
+-- Cadena ROP con JIT
Atribución y contexto del actor de amenazas
La campaña que distribuye Coruna mediante señuelos de criptomonedas y juegos de azar se atribuye a UNC6691, un actor de amenazas con motivación financiera que se cree opera desde China. Estas son las razones por las que esta atribución tiene sentido: la infraestructura utiliza de forma intensiva los TLD .icu, .top, .online y .game, que están habitualmente asociados a redes de fraude operadas desde China. Por ejemplo, dominios como mijieqi[.]cn y 668ddf[.]cc emplean caracteres chinos o convenciones de nomenclatura típicas de grupos de amenazas chinos. Dicho de otro modo: estas elecciones de dominio y las pistas lingüísticas ofrecen señales sólidas sobre el origen del operador. Es importante destacar que el exploit no impone restricciones geográficas; apunta a cualquier usuario de Safari en todo el mundo, lo que lo convierte en una amenaza global.
La migración del framework Coruna desde un proveedor comercial de software de vigilancia, pasando por un actor de espionaje estatal (UNC6353), hasta llegar a un grupo criminal con motivación financiera (UNC6691) en aproximadamente un año pone de relieve el activo mercado secundario de exploits móviles avanzados. Lo que esto significa en la práctica es que los exploits de día cero sofisticados, desarrollados inicialmente para el espionaje, se reutilizan rápidamente para el cibercrimen con fines lucrativos. Por ejemplo, los dos CVE de la Operación Triangulation incluidos en el kit —CVE-2023-32434 y CVE-2023-38606— fueron documentados públicamente por primera vez como días cero empleados en una campaña de espionaje de alto nivel. Ahora, esas mismas vulnerabilidades impulsan una herramienta de explotación masiva dirigida a carteras de criptomonedas, lo que ilustra la rapidez con la que los actores de amenazas cambian de táctica.
Qué debes hacer
La protección más eficaz es sencilla: actualiza todos los dispositivos Apple de inmediato. El kit falla explícitamente contra la versión más reciente de iOS disponible en el momento de la divulgación. Por ejemplo, los usuarios con iOS 17.3 o posterior están protegidos frente al exploit de la cadena principal cassowary. Mejor aún, el kit completo queda neutralizado en iOS 17.4 y versiones superiores. No esperes: actualizar tu dispositivo es la defensa más simple y fiable.
| Acción | Prioridad | Protege frente a |
|---|---|---|
| Actualizar a iOS 17.3+ | Crítica | cassowary (CVE-2024-23222) |
| Actualizar a iOS 17.4+ | Crítica | Sparrow (CVE-2024-23225), Rocket (CVE-2024-23296) |
| Activar el Modo de aislamiento | Alta | Todas las cadenas de Coruna (el kit aborta explícitamente en Modo de aislamiento) |
| Bloquear dominios DGA .xyz de 15 caracteres | Media | Comunicación con el C2 |
Alertar sobre peticiones GET con ?e= a dominios nuevos |
Media | Reporte de resultados del exploit |
Alertar sobre peticiones de archivos [hex de 40 caracteres].min.js |
Media | Entrega de PlasmaLoader |
Para los equipos web en particular: la pregunta no es solo si tus usuarios han parcheado sus dispositivos. También debes plantearte si tu sitio podría utilizarse para distribuir este payload a usuarios sin parchear. Por ejemplo, una etiqueta de anuncio comprometida, un script de analítica envenenado o un recurso de CDN secuestrado cargado por tus páginas podría convertir tu sitio en un nodo de distribución sin que lo sepas. Tus registros de servidor no mostrarían nada sospechoso, porque el exploit se ejecuta íntegramente en el navegador, reporta a un dominio C2 que nunca has visto y luego sale en silencio. Este sigilo hace que la detección sea extremadamente difícil sin una monitorización especializada.
Indicadores de compromiso
Dominios C2 (generados por DGA, TLD .xyz)
vvri8ocl4t3k8n6[.]xyz rlau616jc7a7f7i[.]xyz ol67el6pxg03ad7[.]xyz
6zvjeulzaw5c0mv[.]xyz ztvnhmhm4zj95w3[.]xyz v2gmupm7o4zihc3[.]xyz
pen0axt0u476duw[.]xyz hfteigt3kt0sf3z[.]xyz xfal48cf0ies7ew[.]xyz
yvgy29glwf72qnl[.]xyz lk4x6x2ejxaw2br[.]xyz 2s3b3rknfqtwwpo[.]xyz
xjslbdt9jdijn15[.]xyz hui4tbh9uv9x4yi[.]xyz xittgveqaufogve[.]xyz
xmmfrkq9oat1daq[.]xyz lsnngjyu9x6vcg0[.]xyz gdvynopz3pa0tik[.]xyz
o08h5rhu2lu1x0q[.]xyz zcjdlb5ubkhy41u[.]xyz 8fn4957c5g986jp[.]xyz
uawwydy3qas6ykv[.]xyz sf2bisx5nhdkygn3l[.]xyz roy2tlop2u[.]xyz
gqjs3ra34lyuvzb[.]xyz eg2bjo5x5r8yjb5[.]xyz b38w09ecdejfqsf[.]xyz
Dominios de entrega (selección)
ai-scorepredict[.]com pepeairdrop01[.]com
goodcryptocurrency[.]top cryptocurrencyworld[.]top
bestcryptocurrency[.]top binancealliancesintro[.]com
b27[.]icu 7p[.]game
4u[.]game h4k[.]icu
spin7[.]icu seven7[.]vip
seven7[.]to 4kgame[.]us
7uspin[.]us n49[.]top
98a[.]online 7ff[.]online
26a[.]online cy8[.]top
btrank[.]top mkkku[.]com
goanalytics[.]xyz kanav[.]blog
land[.]77bingos[.]com land[.]bingo777[.]now
land[.]777bingos[.]xyz dbgopaxl[.]com
lddx3z2d72aa8i6[.]xyz dd9l7e6ghme8pbk[.]xyz
fxrhcnfwxes90q[.]xyz 3v5w1km5gv[.]xyz
sj9ioz3a7y89cy7[.]xyz appstoreconn[.]com
ddus17[.]com tubeluck[.]com
IPs de infraestructura (no CDN)
| IP | ASN | Proveedor de alojamiento | Dominios |
|---|---|---|---|
95.214.181.109 |
AS212238 | Datacamp Limited, HK (bulletproof) | cryptocurrencyworld[.]top, bestcryptocurrency[.]top |
185.53.179.128 |
AS61969 | Team Internet AG, DE | mkkku[.]com |
103.110.221.8 |
AS137535 | JT Telecom International, JP | ddus17[.]com |
54.248.167.86 |
AS16509 | AWS EC2 ap-northeast-1 (Tokio) | btrank[.]top |
Dominios adicionales encontrados mediante pivote rDNS (Team Internet AG, 185.53.179.128)
bet247[.]ac gem88[.]ac gemwin[.]ac
gunbet[.]ac i9-bet[.]ac sbet[.]ac
taisunwin[.]ac
Firmas de JavaScript
Despachador de módulos: globalThis.vKTo89
Funciones de API: WLEBfI, ksQccv, OLdwIx, LBrh4t, tI4mjA
Ofuscación de URL: lysNguL, lysNguk, lysNgu6, lysNguv
Salt de despliegue: cf40de81867d2397
Patrón XOR: [n1,n2,...].map(x => String.fromCharCode(x ^ K)).join("")
Calentamiento JIT: new Uint32Array(10000000) + x += 1 repetido
Límites de versión: 13E4, 16E4
IDs de hash SHA1 de módulos
1ff010bb3e857e2b0383f1d9a1cf9f54e321fbb0 (biblioteca utilitaria)
6b57ca3347345883898400ea4318af3b9aa1dc5c (fingerprinting)
8dbfa3fdd44e287d57c55e74a97f526120ffd8f0 (confusión de tipos JIT)
55afb1a69f9e35265f29b113adaa6f34e8215813 (lectura/escritura arbitraria)
5264a0694295c0a1978d1b4b03b2ab909e5c6d09 (exploit WASM)
166411bd90ee39aed912bd49af8d86831b686337 (primitiva BigUint64)
d6cb72f5888b2ec1282b584155490e3b6e90a977 (exploit del compilador JIT)
dbfd6e840218865cb2269e6b7ed7d10ea9f22f93 (escape de sandbox)
bcb56dc5317128d4e53b8474535f4c099bf322b3 (escáner dyld de iOS)
2d2c721e64fbbb49c39654930563758332e4eff3 (escáner dyld de macOS)
164349160d3d35d83bfdcc001ccd23cd1b3b75d5 (stager de iOS)
6241388ab7da11aa490d4ecfed44d952568f008a (stager de macOS)
Firmas binarias
Shellcode ARM64: 31.308 bytes | comienza con fd 7b bf a9 fd 03 00 91 (prólogo STP X29, X30)
Payload Mach-O: 14.954 bytes | ARM64 (0xFEEDFACF) | relleno UTF-16LE en JS
PlasmaLoader: ~1.324 bytes cifrados | nombre de archivo: [hex de 40 caracteres].min.js
Resumen rápido
Coruna es un kit de exploits de iOS de grado spyware que contiene 23 exploits individuales distribuidos en cinco cadenas. Cubre todas las versiones de iOS desde la 13.0 hasta la 17.2.1. En su origen, fue creado por desarrolladores para un proveedor comercial de software de vigilancia. Posteriormente, lo utilizó un grupo de espionaje ruso. Ahora, un actor de amenazas chino con motivación financiera lo despliega activamente contra carteras de criptomonedas. Esta evolución muestra cómo los exploits pueden pasar entre distintos tipos de actores.
El kit se ejecuta íntegramente en el navegador como un payload JavaScript autocontenido. Utiliza cuatro capas de ofuscación y un protocolo de entrega de módulos con clave que hace que el análisis estático sea prácticamente imposible sin el salt de despliegue. La cadena de ejecución tiene seis fases y termina con un shellcode ARM64 firmado, un binario Mach-O y un implante final que exfiltra datos de las carteras MetaMask, Exodus, Bitget Wallet y Base. En pocas palabras: se trata de un ataque altamente sofisticado y de múltiples etapas que apunta directamente a carteras de criptomonedas populares dentro del entorno del navegador.
La cadena principal, denominada cassowary (CVE-2024-23222), apunta a las versiones de iOS entre la 16.6 y la 17.2.1 mediante una vulnerabilidad de confusión de tipos JIT en JavaScriptCore. Otras dos cadenas reutilizan días cero descubiertos originalmente durante la Operación Triangulation. Cabe destacar que tres CVE de este kit fueron añadidos al catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA al día siguiente de su divulgación pública, lo que subraya su gravedad.
La infraestructura detrás de Coruna abarca más de 50 dominios de entrega registrados en una ventana de 10 semanas entre noviembre de 2025 y enero de 2026. Estos dominios están alojados en Cloudflare, AWS CloudFront, un proveedor bulletproof en Hong Kong (Datacamp Limited) y una instancia dedicada de AWS EC2 en Tokio. Los 27 dominios C2 son generados por DGA usando la semilla "lazarus" y estaban protegidos por Cloudflare en el momento de la divulgación. Esta configuración de alojamiento diversificada ayuda a los operadores a eludir los intentos de eliminación y a mantener la resiliencia.
El punto crítico para los equipos web es este: este payload es un archivo JavaScript. No necesita residir en tu servidor para llegar a tus usuarios. Bastaría con una etiqueta de anuncio comprometida, un script de terceros envenenado o un recurso de CDN secuestrado. Tus registros no mostrarían nada sospechoso. cside monitoriza en tiempo real cada script que se ejecuta en los navegadores de tus usuarios, que es la única capa donde este ataque se vuelve visible. Sin esa monitorización, es posible que nunca detectes esta amenaza.
Sabe lo que ocurre en tu sitio web. No habrías sabido si este script fue inyectado en los navegadores de tus visitantes como consecuencia de uno de tus paquetes de código abierto, herramientas de marketing, anuncios o dependencias de tus dependencias. Lamentablemente, esto ocurre constantemente.
Usa cside para proteger tu negocio. Usa cside para proteger a tus clientes.
Referencias
- Google Threat Intelligence Group, "Coruna iOS Exploit Kit Uses 23 Exploits Across Five Chains Targeting iOS 13-17.2.1," The Hacker News, 4 de marzo de 2026.
- Apple Security Advisory, "CVE-2024-23222: WebKit type confusion issue," enero de 2024. nvd.nist.gov
- Catálogo de Vulnerabilidades Explotadas Conocidas de CISA, 5 de marzo de 2026. cisa.gov
- Help Net Security, "Apple fixes actively exploited WebKit zero-day (CVE-2024-23222)," 23 de enero de 2024.
- Infosecurity Magazine, "Coruna Exploit Kit Targets Older iPhones in Multi-Stage Attack," marzo de 2026.
- Security Affairs, "Google uncovers Coruna iOS Exploit Kit targeting iOS 13-17.2.1," marzo de 2026.
Este análisis se basa en la inspección directa de muestras activas de Coruna obtenidas de dominios de entrega en funcionamiento (b27[.]icu, 7p[.]game), combinada con inteligencia de amenazas pública de Google GTIG, CISA e iVerify. El análisis de infraestructura incluyó resolución DNS, pivotes de DNS inverso mediante HackerTarget, consultas de registro RDAP, registros de transparencia de certificados mediante crt.sh y DNS pasivo de URLScan. Todo el análisis binario se realizó en un entorno aislado para garantizar la seguridad.








