À l'intérieur de Coruna - Exploit iOS par script web

Le kit qui a changé de mains trois fois en un an

Début 2025, un client d'un éditeur commercial de logiciels de surveillance non identifié a été observé en train d'utiliser un framework d'exploitation JavaScript jusque-là inconnu contre des appareils iOS. En juillet 2025, un groupe d'espionnage russe présumé s'était approprié ce même framework et l'injectait silencieusement dans des sites industriels et commerciaux ukrainiens sous la forme d'une iframe cachée. En décembre 2025, un acteur malveillant chinois à motivation financière le déployait sur un réseau de faux sites de cryptomonnaies et de jeux d'argent, sans restriction géographique, ciblant tout utilisateur d'iPhone ayant cliqué sur le mauvais lien. Pour le dire autrement : le même outil puissant est passé de l'espionnage à la cybercriminalité financière en quelques mois, s'adaptant à des objectifs et des cibles différents. Par exemple, le site d'une entreprise énergétique ukrainienne a été compromis pour délivrer des charges utiles d'espionnage, tandis que plus tard, un faux site d'échange de cryptomonnaies a piégé des utilisateurs du monde entier pour les infecter.

Le Threat Intelligence Group (GTIG) de Google a officiellement nommé ce framework Coruna (également référencé sous le nom de CryptoWaters) le 4 mars 2026. Il contient cinq chaînes d'exploitation iOS complètes et 23 exploits individuels couvrant les versions iOS 13 à 17.2.1. iVerify l'a qualifié de « première exploitation de masse observée contre des appareils iOS » et a relevé des similitudes structurelles avec des outils développés par des acteurs malveillants affiliés au gouvernement américain. Voici pourquoi c'est important : ces similitudes structurelles suggèrent la réutilisation ou l'adaptation de techniques sophistiquées de niveau gouvernemental entre des mains criminelles, ce qui élève considérablement les enjeux pour les défenseurs. Concrètement, cela signifie que les attaquants ne se limitent plus à des exploits basiques — ils manient désormais des méthodes avancées autrefois réservées aux opérations étatiques.

Nous avons obtenu des échantillons en direct depuis des domaines de diffusion actifs et analysé chaque couche du JavaScript. Ce qui suit est un compte rendu détaillé de ce que fait ce kit, depuis la première ligne de code obfusqué jusqu'au binaire Mach-O chiffré déposé sur l'appareil de la victime, accompagné d'une analyse complète de l'infrastructure des domaines et adresses IP impliqués. Cette plongée en profondeur révèle non seulement les mécanismes techniques, mais aussi l'empreinte opérationnelle derrière Coruna. Par exemple, nous avons retracé la façon dont la charge utile JavaScript de l'exploit se transforme dynamiquement lors de l'exécution, échappant à la détection tout en maintenant sa stabilité sur les différentes versions d'iOS.

Le problème de la diffusion : pourquoi votre site web est la surface d'attaque

Avant d'entrer dans les détails des mécanismes d'exploitation, il convient de clarifier ce que l'on entend par « diffusion », car de nombreuses organisations n'ont pas pleinement pris en compte cet aspect. La diffusion désigne la méthode par laquelle l'exploit atteint l'appareil de la victime, souvent via une page web en apparence anodine.

Coruna est diffusé sous la forme d'un fichier HTML autonome, généralement nommé group.html ou analytics.html, intégré en tant qu'`

Réseaux publicitaires. Une seule création malveillante diffusée via un réseau publicitaire programmatique atteint chaque éditeur exécutant la balise de ce réseau. Le serveur de l'éditeur ne touche jamais la charge utile. Le WAF de l'éditeur ne la voit jamais. L'équipe de sécurité de l'éditeur n'a aucune visibilité sur ce que la balise publicitaire a chargé dans le navigateur de l'utilisateur. Si Coruna avait été distribué via un réseau publicitaire de niveau intermédiaire, il aurait atteint des millions d'utilisateurs de Safari sur des milliers de sites web légitimes et réputés simultanément. Aucun de ces éditeurs n'en aurait rien su. Par exemple, imaginez un réseau publicitaire diffusant une bannière malveillante sur un site d'actualités populaire : chaque visiteur aurait pu être exposé à l'insu du site.

Scripts tiers compromis. Un site e-commerce ou média moyen charge 30 à 50 balises JavaScript tierces : analytics, widgets de chat, outils de tests A/B, trackers d'affiliation, gestionnaires de consentement. Chacun de ces scripts est un point d'injection potentiel. Une compromission de la chaîne d'approvisionnement de l'un d'entre eux — comme les campagnes Magecart ou l'incident polyfill[.]io — aurait pu transformer chaque site utilisant ce script en nœud de diffusion de Coruna. Là encore, le serveur d'origine n'aurait rien montré d'inhabituel. La charge utile s'exécute dans le navigateur de l'utilisateur et communique avec un domaine C2 que l'éditeur n'a jamais entendu mentionner. Pour le dire autrement : même un fournisseur de scripts de confiance peut devenir un cheval de Troie s'il est compromis. Par exemple, si le script d'un fournisseur d'analytics populaire était détourné, des milliers de sites web pourraient diffuser Coruna à leur insu.

Assets CDN mis en cache. Plusieurs des URL de diffusion que nous avons identifiées étaient servies depuis une infrastructure CDN partagée (tubeluck[.]com, 668ddf[.]cc). Un attaquant disposant d'un accès en écriture à un bucket d'origine CDN ou capable d'empoisonner un cache CDN obtient le même résultat. Par exemple, si un attaquant parvient à téléverser un fichier malveillant dans un bucket CDN utilisé par plusieurs sites, il peut diffuser silencieusement des exploits à tous les visiteurs de ces sites. Ce scénario s'est déjà produit lors d'attaques passées où des attaquants ont empoisonné des caches CDN largement utilisés pour propager rapidement des malwares.

L'enjeu n'est pas que ces vecteurs spécifiques aient été utilisés. L'enjeu est que rien dans la charge utile de Coruna n'exige que l'attaquant possède le site de diffusion. La charge utile est un fichier JavaScript. Elle va partout où va JavaScript. Et JavaScript va partout.

Comment il atteint le navigateur : l'infrastructure de diffusion

Les campagnes que nous avons analysées utilisaient plus de 50 domaines de diffusion, organisés selon des thèmes de leurres reconnaissables.

Nombre de ces sites invitent explicitement les utilisateurs à les visiter depuis un appareil mobile pour une « meilleure expérience » — une incitation d'ingénierie sociale visant à s'assurer que la cible ouvre la page dans Safari sur iOS plutôt que dans un navigateur de bureau. Cette tactique augmente la probabilité que l'exploit s'exécute avec succès, puisqu'il cible des versions iOS spécifiques. Par exemple, un faux site de bingo pourrait afficher une fenêtre contextuelle indiquant : « Pour une meilleure expérience, veuillez ouvrir cette page sur votre iPhone », incitant les victimes à se placer dans le bon environnement.

---

Analyse de l'infrastructure : DNS, rDNS, WHOIS et hébergement

Nous avons effectué une résolution DNS complète, des recherches DNS inversées, des requêtes d'enregistrement WHOIS/RDAP et des pivots d'adresses IP sur l'ensemble des domaines de diffusion et C2. Les résultats révèlent une stratégie d'infrastructure délibérée : abus des grands CDN cloud pour masquer l'origine réelle, un petit nombre d'adresses IP dédiées pour les sites leurres les plus sensibles, et des schémas d'enregistrement qui se concentrent étroitement autour de fin 2025 et début 2026. Cette coordination suggère une campagne soigneusement planifiée plutôt qu'une activité opportuniste aléatoire.

Répartition de l'hébergement

L'infrastructure de diffusion se divise en quatre niveaux d'hébergement distincts.

Niveau 1 : proxy Cloudflare. La majorité des domaines de diffusion liés aux jeux d'argent et aux jeux en ligne — notamment 7p[.]game, b27[.]icu, h4k[.]icu, spin7[.]icu, 7ff[.]online, 26a[.]online, tubeluck[.]com, ai-scorepredict[.]com et dbgopaxl[.]com — résolvent tous vers des adresses IP anycast Cloudflare. Cloudflare assure la protection DDoS, la terminaison TLS et une dissimulation efficace de l'adresse IP d'origine. Les serveurs backend réels ne sont pas visibles depuis le DNS. Cette configuration permet aux attaquants de masquer leur véritable infrastructure derrière un service réputé, compliquant les efforts de démantèlement. Pour le dire autrement : Cloudflare agit comme un bouclier, rendant difficile la localisation des vrais serveurs des attaquants.

Niveau 2 : AWS CloudFront. Un second grand cluster utilise AWS CloudFront comme couche CDN. Les domaines 4u[.]game, seven7[.]vip, seven7[.]to, 4kgame[.]us, 7uspin[.]us, n49[.]top, 98a[.]online, cy8[.]top, 7fun[.]icu, k96[.]icu, t7c[.]icu, y4w[.]icu ainsi que le cluster bingo (land[.]77bingos[.]com, land[.]bingo777[.]now, land[.]777bingos[.]xyz) résolvent tous vers des nœuds edge CloudFront. Le cluster bingo partage un même ensemble de quatre adresses IP CloudFront, ce qui indique qu'ils sont servis depuis la même distribution et vraisemblablement depuis la même origine S3 ou EC2. Cette consolidation permet aux attaquants de gérer efficacement plusieurs leurres tout en maintenant leur résilience. Par exemple, si un domaine est supprimé, les autres restent opérationnels, assurant une diffusion continue.

Niveau 3 : adresses IP dédiées sur hébergement tolérant aux abus. La découverte la plus significative sur le plan opérationnel est l'utilisation d'adresses IP dédiées chez des hébergeurs connus pour leur tolérance aux abus, pour les sites leurres les plus sensibles. cryptocurrencyworld[.]top et bestcryptocurrency[.]top partagent une seule adresse IP dédiée : 95.214.181.109, enregistrée auprès de Datacamp Limited à Hong Kong (AS212238), un hébergeur bulletproof bien documenté. Ces deux domaines sont les seuls sur cette adresse IP. mkkku[.]com résout vers 185.53.179.128 (Team Internet AG, Allemagne). Le DNS inversé sur cette adresse IP a révélé sept domaines de jeux d'argent supplémentaires sur le même serveur : bet247[.]ac, gem88[.]ac, gemwin[.]ac, gunbet[.]ac, i9-bet[.]ac, sbet[.]ac et taisunwin[.]ac, tous cohérents avec le thème général de diffusion de Coruna. btrank[.]top résout vers une instance AWS EC2 dédiée à Tokyo (54.248.167.86). ddus17[.]com résout vers 103.110.221.8 (JT Telecom International, Japon) sans domaines co-hébergés, ce qui est cohérent avec un serveur dédié. Ce niveau montre comment les attaquants équilibrent dissimulation et contrôle opérationnel. Autrement dit, ils utilisent des hébergeurs bulletproof là où ils peuvent opérer librement, tout en tirant parti des services cloud pour leur scalabilité.

Niveau 4 : China Unicom. pc6[.]com, un grand portail chinois de téléchargement de logiciels figurant parmi les URL de diffusion, résout vers neuf adresses IP sur le backbone de China Unicom (AS4837). Les pivots DNS inversés sur ces adresses IP ont retourné des centaines de domaines co-hébergés chacun, tous avec des noms en chinois et des TLD .cn, .cc et .cloud. Cela est cohérent avec un environnement d'hébergement partagé de grande taille. L'URL de diffusion pc6[.]com représente vraisemblablement une page compromise sur un site légitime existant plutôt qu'une infrastructure appartenant aux attaquants. Cet exemple illustre comment les attaquants exploitent des plateformes légitimes pour distribuer leurs charges utiles. Par exemple, un portail chinois de logiciels populaire pourrait héberger à son insu des iframes malveillantes, mettant des millions d'utilisateurs en danger.

Chronologie des enregistrements WHOIS

Les données d'enregistrement RDAP ont été récupérées avec succès pour un sous-ensemble de domaines de diffusion. Les dates se concentrent étroitement, confirmant une campagne d'enregistrement coordonnée. Par exemple, de nombreux domaines ont été enregistrés à quelques jours ou semaines d'intervalle fin 2025 et début 2026, ce qui suggère un déploiement planifié plutôt que des acquisitions de domaines aléatoires. Ce schéma indique que les attaquants ont préparé leur infrastructure soigneusement, plutôt que d'improviser.

Toutes les dates d'enregistrement confirmées se situent entre novembre 2025 et janvier 2026, une fenêtre de 10 semaines qui coïncide parfaitement avec l'escalade observée de la campagne, de l'espionnage ciblé à l'exploitation financière à grande échelle. Voici pourquoi c'est important : une période d'enregistrement aussi concentrée suggère un effort coordonné pour déployer rapidement l'infrastructure. Par exemple, pepeairdrop01[.]com est actuellement suspendu par son registrar pour non-respect de la vérification du domaine, ce qui indique une pression active de démantèlement de la part des défenseurs. Pour le dire autrement : ce domaine a vraisemblablement été signalé et mis hors ligne rapidement pour perturber les opérations de la campagne. dbgopaxl[.]com se distingue quant à lui comme une anomalie, enregistré dès avril 2024. Cela suggère qu'il pourrait s'agir d'un actif pré-positionné, mis en place des mois à l'avance en prévision d'une utilisation future, ou peut-être d'un domaine légitime compromis et réaffecté à cette campagne.

Les domaines C2 — les 27 domaines .xyz générés par DGA — ont retourné des erreurs 404 depuis le serveur RDAP. Cela signifie qu'ils ont soit été supprimés du registre, soit qu'ils n'ont jamais été enregistrés via un chemin interrogeable par RDAP standard. Concrètement, ces domaines fonctionnent comme des domaines de repli éphémères générés algorithmiquement. Les opérateurs les enregistrent et les abandonnent en rotation continue pour garder une longueur d'avance sur les efforts de démantèlement et éviter la détection. Par exemple, si un domaine est bloqué par les défenseurs, un autre peut rapidement prendre sa place sans aucune intervention manuelle, maintenant ainsi la résilience de l'infrastructure de commande et contrôle.

Transparence des certificats

Les journaux de transparence des certificats nous fournissent une chronologie indépendante indiquant quand les domaines ont commencé à utiliser HTTPS. Parmi les conclusions clés : b27[.]icu a émis son premier certificat TLS le 01/06/2025 (Amazon CA), confirmant que le domaine était actif au moins six mois avant le pic de la campagne. Cette activité précoce suggère qu'il a pu être utilisé pour des tests initiaux ou de la reconnaissance. Autre exemple : 7p[.]game est apparu pour la première fois dans les journaux CT le 21/03/2024 (GoDaddy CA). C'est le plus ancien de l'ensemble de diffusion, ce qui implique qu'il s'agit d'une opération de jeux d'argent de longue date ayant adopté la diffusion de Coruna plutôt que d'un site leurre créé spécifiquement. ai-scorepredict[.]com a émis son premier certificat le 29/01/2026, exactement le même jour que sa date d'enregistrement RDAP, confirmant qu'il a été créé spécifiquement pour cette campagne. Enfin, tubeluck[.]com est apparu pour la première fois dans les journaux CT en 2019, ce qui en fait le domaine le plus ancien de l'ensemble du jeu de données. Cela indique qu'il s'agit d'un service CDN ou d'hébergement établi de longue date que l'opérateur utilise comme infrastructure, vraisemblablement pour mêler le trafic malveillant au trafic légitime.

Infrastructure des domaines C2

Les 27 domaines C2 générés par DGA ne retournent actuellement aucun enregistrement DNS A, ce qui signifie qu'ils ne résolvent vers aucune adresse IP. Deux domaines, vvri8ocl4t3k8n6[.]xyz et rlau616jc7a7f7i[.]xyz, avaient des entrées URLScan datées du 4 mars 2026, jour de la divulgation par le GTIG. Tous deux résolvaient vers des adresses IP Cloudflare à ce moment-là. Cela confirme que l'infrastructure C2 était active et frontée par Cloudflare le jour de la divulgation. Depuis, l'infrastructure a soit été démantelée, soit pivotée vers de nouveaux domaines. C'est comme changer les serrures après une effraction : les opérateurs ont rapidement déplacé leur commande et contrôle pour éviter toute perturbation et échapper à la détection des défenseurs.

---

Quatre couches d'obfuscation avant de voir le moindre exploit

Ouvrir la page de livraison dans un éditeur de texte ne révèle rien d'utile au premier coup d'œil. Le framework Coruna utilise une architecture d'obfuscation sophistiquée à quatre couches, conçue spécifiquement pour contourner les outils d'analyse statique et les sandboxes automatisées. Cela signifie que même les analystes expérimentés font face à un défi de taille rien que pour comprendre ce que fait le code.

Couche 0 : le bootstrap externe

Le HTML de livraison contient un bootstrap JavaScript minimal. Chaque chaîne de caractères significative est dissimulée sous forme de tableau d'entiers décodés par XOR à l'exécution. Par exemple :

[107, 49, 105, 97].map(x => String.fromCharCode(x ^ 84)).join("")

Ici, chaque entier est soumis à un XOR avec la clé 84 pour révéler le caractère réel. La clé XOR varie selon la chaîne, il n'existe donc aucun motif unique à repérer dans l'ensemble du fichier. La logique principale se cache dans new Function(atob("..."))() : une chaîne encodée en Base64 évaluée comme une nouvelle fonction. Cela maintient le vrai code hors de l'arbre d'analyse initial et à l'écart de la plupart des scanners statiques. Autrement dit, le code est verrouillé derrière une énigme qui ne se révèle qu'à l'exécution, rendant l'analyse statique quasiment impossible.

Couche 1 : le répartiteur de modules

Après décodage de la couche 0, on obtient un objet JavaScript enregistré sous globalThis.vKTo89. Cet objet contient une implémentation complète de SHA-256 et une table de correspondance des modules d'exploitation indexés par leurs hachages SHA1. Le répartiteur expose cinq fonctions d'API :

La fonction LBrh4t implémente un protocole de livraison de modules à clé. Pour un identifiant de hachage de module donné, elle calcule SHA256(salt + hash_id).substring(0, 40) et récupère le nom de fichier résultant depuis le serveur. Le sel observé dans les échantillons analysés est cf40de81867d2397. Sans connaître le sel, un analyste ne peut pas prédire quels noms de fichiers demander, même s'il connaît les identifiants de hachage des modules. L'URL de base est dérivée de location.href.slice(0, lastIndexOf("/") + 1), ce qui signifie que tous les modules d'exploitation sont servis depuis le même domaine que la page de livraison. Cette configuration rend difficile l'interception ou la prédiction des récupérations de modules par les défenseurs, dissimulant efficacement les prochaines actions de l'attaquant.

Couche 2 : le code des modules

Chaque module est stocké sous forme de chaîne encodée en Base64. Une fois décodé, le JavaScript du module continue d'utiliser des tableaux de chaînes encodées par XOR pour tous les littéraux sensibles : chemins de framework, noms d'API, adresses mémoire, constantes de version. Cette obfuscation en couches garantit que même si une couche est décodée, les données sensibles restent cachées, obligeant les analystes à décortiquer plusieurs couches avant de comprendre la charge utile.

Couche 3 : les charges utiles binaires inline

Les modules les plus volumineux intègrent leurs charges utiles binaires sous forme de chaînes encodées en Base64 dans le JavaScript. Le shellcode ARM64 est stocké en binaire brut. Le binaire Mach-O est stocké avec chaque octet complété à deux octets (encodage UTF-16LE), ajoutant une couche supplémentaire d'obfuscation contre la détection par signature binaire. C'est comme emballer un colis deux fois pour le rendre plus difficile à identifier. Cette astuce ingénieuse aide le malware à contourner les outils de détection basés sur les signatures.

Mesures anti-analyse

Le framework met en œuvre plusieurs vérifications anti-analyse actives avant d'exécuter tout code d'exploitation. Il s'interrompt si le mode Lockdown d'Apple est détecté. Il ignore l'exécution en mode navigation privée. Il vérifie la présence d'un vrai moteur de rendu WebKit en créant un élément `$`\; et\; en\; s\text{'}assurant\; que$mathcolor="blue" s'affiche en rgb(0, 0, 255). Il vérifie également la disponibilité de RTCPeerConnection pour confirmer un environnement de navigateur authentique plutôt qu'une sandbox headless. Après l'exécution, il signale le résultat au C2 via une requête GET vers <base_url>?e=<code>, où 0 signifie succès, 1000 signifie échec de l'exploitation, 1001 signifie que la version cible n'est pas prise en charge, et 1003 signifie qu'une sandbox a été détectée. Ces vérifications aident le malware à éviter de s'exécuter dans des environnements où il pourrait être analysé ou échouer, augmentant ainsi les chances d'exploitation réussie.

---

La chaîne d'exploitation : six phases du chargement de la page au Mach-O

Phase 1 : empreinte de la cible

Le module d'empreinte s'exécute en premier et détermine si la cible vaut la peine d'être attaquée et quelle chaîne d'exploitation utiliser. Le script vérifie la chaîne User-Agent pour Version/ (présente dans tous les UA Safari) et AppleWebKit/. Si aucune n'est trouvée, il s'arrête immédiatement. Ensuite, il distingue iOS de macOS Safari en combinant typeof TouchEvent !== "undefined" et un test d'insertion de Blob dans IndexedDB. Plus précisément, tenter de stocker un objet Blob dans IndexedDB lève l'exception "BlobURLs are not yet supported" sur iOS Safari, ce qui constitue une empreinte de plateforme fiable.

La partie techniquement la plus sophistiquée de l'empreinte est un oracle mémoire WebAssembly. Le script instancie un WebAssembly.Table et un WebAssembly.Instance, puis lit les balises de type de cellule JSC (JavaScriptCore) internes depuis la mémoire. La valeur de balise 0x10016 indique macOS Safari ; 0x10017 indique iOS Safari. Cette technique lit directement la représentation interne des objets de JavaScriptCore depuis la mémoire, nécessitant une connaissance approfondie du code source de WebKit. La version iOS est extraite du User-Agent et comparée à une table de correspondance de 19 versions iOS connues (de 10.0.0 à 17.0.0) et 13 versions de macOS Safari, avec des chemins d'exploitation distincts sélectionnés pour iOS 13 à 15.x et iOS 16.x et supérieur. Cette empreinte précise garantit que la chaîne d'exploitation correspond parfaitement à l'environnement de la cible, augmentant les chances de succès.

Phase 2 : exécution de code à distance via confusion de types JIT (CVE-2024-23222)

La chaîne d'exploitation principale dans les échantillons que nous avons analysés est cassowary, ciblant CVE-2024-23222, un bug de confusion de types dans JavaScriptCore corrigé par Apple en janvier 2024 avec iOS 17.3.

L'exploitation commence par l'appel d'une fonction exactement 1 000 000 fois avec des arguments en virgule flottante. Cela force le compilateur JIT de JSC à spécialiser la fonction pour les opérations sur les tableaux de flottants, générant du code machine optimisé qui suppose que chaque élément du tableau sera toujours un flottant double précision. Une fois la compilation JIT effectuée, l'exploit remplace un élément du tableau cible par un objet JavaScript au lieu d'un flottant. Le code compilé JIT lit cette valeur comme un flottant, interprétant le pointeur de l'objet comme un double 64 bits. C'est la confusion de types : JSObject* est traité comme double. En relisant la valeur flottante confuse, l'exploit récupère l'adresse de l'objet dans le tas JSC. C'est le primitif addrof.

L'opération inverse, écrire un flottant forgé dans le tableau, amène JSC à interpréter le double comme un pointeur d'objet, créant un primitif fakeobj pointant vers une mémoire contrôlée par l'attaquant. En combinant addrof et fakeobj, l'exploit construit un faux objet ArrayBuffer dont le pointeur de stockage de sauvegarde est défini sur une adresse arbitraire. La lecture ou l'écriture via ce faux ArrayBuffer fournit une lecture/écriture arbitraire complète de la mémoire du processus. L'exploit stabilise ce primitif en utilisant du heap spraying avec des tableaux de 16 éléments de valeurs flottantes spécifiques et une classe d'abstraction d'entiers 64 bits personnalisée. Cette combinaison permet à l'attaquant de manipuler la mémoire à volonté, une étape cruciale pour l'exploitation ultérieure.

Phase 3 : contournement de l'ASLR via le scan du cache partagé dyld

Une fois la lecture/écriture arbitraire établie, l'exploit scanne la mémoire du processus à la recherche du cache partagé dyld pour contourner l'ASLR. Sur iOS, il localise WebCore, CoreUtils et IOKit en recherchant leurs en-têtes de segment __TEXT. Sur macOS, il cible CoreFoundation, CoreGraphics, ActionKit et RESync. L'exploit lit les en-têtes de segment __TEXT de chaque framework pour déterminer leurs adresses de chargement, et localise _ZN3JSC16jitOperationListE pour trouver les régions de mémoire exécutable allouées par JIT. Cette étape est cruciale car l'ASLR randomise les emplacements mémoire, et connaître ces adresses permet à l'exploit d'exécuter du code de manière fiable.

Phase 4 : évasion du sandbox

Le module d'évasion du sandbox combine deux techniques. Un exploit de filtre SVG `` corrompt la mémoire dans le processus de composition WebKit, permettant à l'exploit de s'échapper du sandbox du moteur de rendu. Simultanément, l'exploit utilise pthread_main_thread_np, une API privée de macOS et iOS, pour manipuler le stockage local aux threads et accéder au contexte d'exécution du thread principal, qui dispose de privilèges système plus étendus que le thread du moteur de rendu. Pour illustrer : s'échapper du sandbox, c'est comme sortir d'une pièce verrouillée pour accéder à tout le bâtiment.

Phase 5 : contournement de l'authentification des pointeurs sur Apple Silicon

Sur les appareils Apple Silicon (tous les iPhone depuis le XR et tous les Mac de la série M), l'exploit doit contourner les Pointer Authentication Codes (PAC), le mécanisme d'intégrité du flux de contrôle appliqué par le matériel d'Apple. Le module stager macOS contient les symboles C++ internes JSC suivants :

_ZN3JSC20SecureARM64EHashPins27allocatePinForCurrentThreadEv
_ZN3JSC10LinkBuffer8linkCodeERNS_14MacroAssemblerENS_20JITCompilationEffortE
_ZN3WTF13MetaAllocator8allocateEmPv
jitCagePtr

L'exploit détourne jitCagePtr et SecureARM64EHashPins pour allouer de la mémoire exécutable dans la cage JIT et signer le shellcode ARM64 avec une signature PAC valide. Cela permet à du code natif non signé de s'exécuter sur du matériel avec PAC activé. La technique alloue 40 Mo de mémoire avec new Uint32Array(10000000) et remplit la mémoire JIT avec des motifs prévisibles via un JIT spray d'instructions x += 1 répétées. Cette approche trompe le matériel pour qu'il fasse confiance au code malveillant, contournant ainsi les protections PAC.

Phase 6 : exécution du shellcode et livraison de la charge utile

Les modules stager finaux contiennent trois composants binaires embarqués :

Le shellcode ARM64 commence par le prologue de fonction standard STP X29, X30, [SP, #-16]! et est injecté dans de la mémoire exécutable allouée par JIT. Il utilise dlsym contre /usr/lib/system/libdyld.dylib pour résoudre les fonctions système à l'exécution, évitant ainsi les imports statiques. Le binaire Mach-O référence des frameworks iOS privés, notamment SpringBoard, PassKitCore, CoreML, MediaToolbox et AppleMediaServices. Cela indique des capacités au niveau système telles que l'accès au trousseau, l'énumération des applications installées et la manipulation de l'écran d'accueil. La charge utile finale, PlasmaLoader (également appelé PLASMAGRID par Google GTIG), est récupérée depuis le domaine de livraison sous forme de fichier .min.js chiffré. Elle décode des QR codes à partir d'images, récupère des modules supplémentaires depuis le C2 et exfiltre des données de portefeuilles de cryptomonnaies depuis des portefeuilles populaires tels que MetaMask, Exodus, Bitget Wallet et Base. Cela révèle la motivation financière évidente de la campagne et son ciblage sophistiqué d'actifs de valeur.

---

Vingt-trois exploits, cinq chaînes, quatre ans de CVE

La chaîne cassowary est l'une des douze chaînes d'exploitation nommées au sein de Coruna. Le kit complet couvre iOS 13 à 17.2.1 sans interruption. Cette couverture complète signifie que les attaquants peuvent cibler pratiquement n'importe quel appareil exécutant ces versions d'iOS, laissant peu de refuges sûrs aux victimes potentielles.

Deux de ces chaînes, Photon et Gallium, exploitent des vulnérabilités précédemment utilisées comme zero-days dans Operation Triangulation, la sophistiquée campagne d'espionnage iOS documentée par Kaspersky en 2023. Leur réutilisation dans une campagne criminelle à motivation financière illustre directement la façon dont les outils offensifs étatiques migrent vers l'écosystème de menaces plus large une fois que les CVE sous-jacents deviennent publics. Par exemple, après la divulgation de ces CVE, des groupes criminels les ont rapidement adoptés pour cibler des utilisateurs ordinaires à des fins lucratives, transformant des outils d'espionnage avancés en malwares grand public. Le 5 mars 2026, la CISA a ajouté CVE-2021-30952, CVE-2023-41974 et CVE-2023-43000 à son catalogue des vulnérabilités exploitées connues, avec une échéance de remédiation au 26 mars 2026 pour les agences fédérales. Cela souligne l'urgence d'appliquer les correctifs pour ces vulnérabilités afin de prévenir leur exploitation et de protéger les infrastructures critiques.

L'architecture des modules en détail

[Page de livraison : group.html / analytics.html]
    |
    +-- Couche 0 : Bootstrap (JS obfusqué par XOR)
    |   +-- Initialise le dispatcher globalThis.vKTo89
    |
    +-- Couche 1 : Objet MM (Base64 -> JS)
    |   +-- Module 1ff010bb : bibliothèque mathématique/utilitaire
    |   |   +-- SHA256, arithmétique BigInt, analyse d'URL
    |   +-- Module 6b57ca33 : moteur de fingerprinting
    |       +-- Analyse UA, détection de plateforme
    |       +-- Oracle mémoire WebAssembly (balises de cellule JSC 0x10016/0x10017)
    |       +-- Test Blob IndexedDB (détection iOS)
    |       +-- Test de rendu MathML
    |       +-- Vérification de l'environnement WebRTC
    |
    +-- Modules distants (récupérés via des URL indexées par SHA256)
        +-- 8dbfa3fd : exploit de confusion de types JIT (addrof/fakeobj)
        +-- 55afb1a6 : primitive R/W arbitraire (faux ArrayBuffer)
        +-- 5264a069 : variante d'exploit basée sur WebAssembly
        +-- 166411bd : spray JIT WebAssembly / primitive BigUint64Array
        +-- d6cb72f5 : exploit du compilateur JIT (préchauffage sur 1M d'itérations)
        +-- dbfd6e84 : échappement de sandbox (feConvolveMatrix + pthread)
        |
        +-- [chemin iOS] bcb56dc5 : scanner du cache partagé dyld iOS
        |   +-- Localisateur de frameworks WebCore, IOKit, CoreUtils
        |
        +-- [chemin macOS] 2d2c721e : scanner du cache partagé dyld macOS
        |   +-- Localisateur CoreFoundation, CoreGraphics, ActionKit
        |
        +-- [stager iOS] 164349160 : stager de charge utile iOS
        |   +-- Shellcode ARM64 (31 308 octets)
        |   +-- Binaire Mach-O chiffré (14 954 octets)
        |
        +-- [stager macOS] 6241388a : stager de charge utile macOS
            +-- Shellcode ARM64 (31 308 octets)
            +-- Binaire Mach-O chiffré (14 954 octets)
            +-- Contournement PAC (jitCagePtr, SecureARM64EHashPins)
            +-- Chaîne ROP JIT

---

Attribution et contexte de l'acteur malveillant

La campagne distribuant Coruna via des leurres liés aux cryptomonnaies et aux jeux d'argent est attribuée à UNC6691, un acteur malveillant à motivation financière présumé opérer depuis la Chine. Voici pourquoi cette attribution est cohérente : l'infrastructure utilise massivement les TLD .icu, .top, .online et .game, couramment associés aux réseaux de fraude opérés depuis la Chine. Par exemple, des domaines comme mijieqi[.]cn et 668ddf[.]cc emploient des caractères chinois ou des conventions de nommage typiques des groupes malveillants chinois. En d'autres termes, ces choix de domaines et ces indices linguistiques constituent des signaux forts quant à l'origine des opérateurs. Il est important de noter que l'exploit n'impose aucune restriction géographique ; il cible tout utilisateur de Safari dans le monde, ce qui en fait une menace mondiale.

La migration du framework Coruna depuis un éditeur commercial de logiciels de surveillance, en passant par un acteur d'espionnage étatique (UNC6353), jusqu'à un groupe criminel à motivation financière (UNC6691) en l'espace d'environ un an, met en évidence l'existence d'un marché secondaire actif pour les exploits mobiles avancés. Concrètement, cela signifie que des exploits zero-day sophistiqués, initialement développés à des fins d'espionnage, sont rapidement réutilisés à des fins lucratives dans le cadre de la cybercriminalité. Par exemple, les deux CVE d'Operation Triangulation intégrés dans le kit — CVE-2023-32434 et CVE-2023-38606 — ont d'abord été documentés publiquement comme des zero-days utilisés dans une campagne d'espionnage de haut niveau. Ces mêmes vulnérabilités alimentent désormais un outil d'exploitation de masse ciblant les portefeuilles de cryptomonnaies, illustrant la rapidité avec laquelle les acteurs malveillants font évoluer leurs tactiques.

---

Ce que vous devez faire

La protection la plus efficace est simple : mettez à jour tous vos appareils Apple immédiatement. Le kit échoue explicitement contre la dernière version d'iOS disponible au moment de la divulgation. Par exemple, les utilisateurs sous iOS 17.3 ou version ultérieure sont protégés contre l'exploit de la chaîne principale cassowary. Mieux encore, le kit complet est neutralisé sur iOS 17.4 et versions ultérieures. N'attendez pas — mettre à jour votre appareil est la défense la plus simple et la plus fiable.

Pour les équipes web en particulier : la question n'est pas seulement de savoir si vos utilisateurs ont mis à jour leurs appareils. Vous devez également vous demander si votre site pourrait être utilisé pour distribuer cette charge utile à des utilisateurs non mis à jour. Par exemple, une balise publicitaire compromise, un script d'analytics empoisonné ou un asset CDN détourné chargé par vos pages pourrait transformer votre site en nœud de distribution à votre insu. Vos journaux serveur n'afficheraient rien de suspect, car l'exploit s'exécute entièrement dans le navigateur, envoie ses rapports à un domaine C2 que vous n'avez jamais vu, puis se termine silencieusement. Cette furtivité rend la détection extrêmement difficile sans surveillance spécialisée.

---

Indicateurs de compromission

Domaines C2 (générés par 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

Domaines de livraison (sélection)

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

Adresses IP d'infrastructure (hors CDN)

Domaines supplémentaires découverts via pivot rDNS (Team Internet AG, 185.53.179.128)

bet247[.]ac    gem88[.]ac    gemwin[.]ac
gunbet[.]ac    i9-bet[.]ac   sbet[.]ac
taisunwin[.]ac

Signatures JavaScript

Dispatcher de modules :  globalThis.vKTo89
Fonctions API :          WLEBfI, ksQccv, OLdwIx, LBrh4t, tI4mjA
Obfuscation d'URL :      lysNguL, lysNguk, lysNgu6, lysNguv
Sel de déploiement :     cf40de81867d2397
Motif XOR :              [n1,n2,...].map(x => String.fromCharCode(x ^ K)).join("")
Préchauffage JIT :       new Uint32Array(10000000) + x += 1 répété
Limites de version :     13E4, 16E4

Identifiants de hachage SHA1 des modules

1ff010bb3e857e2b0383f1d9a1cf9f54e321fbb0  (bibliothèque utilitaire)
6b57ca3347345883898400ea4318af3b9aa1dc5c  (fingerprinting)
8dbfa3fdd44e287d57c55e74a97f526120ffd8f0  (confusion de types JIT)
55afb1a69f9e35265f29b113adaa6f34e8215813  (R/W arbitraire)
5264a0694295c0a1978d1b4b03b2ab909e5c6d09  (exploit WASM)
166411bd90ee39aed912bd49af8d86831b686337  (primitive BigUint64)
d6cb72f5888b2ec1282b584155490e3b6e90a977  (exploit du compilateur JIT)
dbfd6e840218865cb2269e6b7ed7d10ea9f22f93  (échappement de sandbox)
bcb56dc5317128d4e53b8474535f4c099bf322b3  (scanner dyld iOS)
2d2c721e64fbbb49c39654930563758332e4eff3  (scanner dyld macOS)
164349160d3d35d83bfdcc001ccd23cd1b3b75d5  (stager iOS)
6241388ab7da11aa490d4ecfed44d952568f008a  (stager macOS)

Signatures binaires

Shellcode ARM64 :  31 308 octets | commence par fd 7b bf a9 fd 03 00 91 (prologue STP X29, X30)
Charge utile Mach-O :   14 954 octets | ARM64 (0xFEEDFACF) | encodé en UTF-16LE dans JS
PlasmaLoader :     ~1 324 octets chiffrés | nom de fichier : [hex sur 40 caractères].min.js

---

Récapitulatif

Coruna est un kit d'exploitation iOS de niveau spyware contenant 23 exploits individuels répartis sur cinq chaînes. Il couvre toutes les versions d'iOS de 13.0 à 17.2.1. À l'origine, ses développeurs l'ont créé pour un éditeur commercial de logiciels de surveillance. Un groupe d'espionnage russe l'a ensuite utilisé. Aujourd'hui, un acteur malveillant chinois à motivation financière le déploie activement contre des portefeuilles de cryptomonnaies. Cette évolution illustre la façon dont les exploits peuvent circuler entre différents types d'acteurs.

Le kit s'exécute entièrement dans le navigateur sous la forme d'une charge utile JavaScript autonome. Il utilise quatre couches d'obfuscation et un protocole de livraison de modules à clé qui rend l'analyse statique quasi impossible sans le sel de déploiement. La chaîne d'exécution comporte six phases, aboutissant à un shellcode ARM64 signé, un binaire Mach-O et un implant final qui exfiltre les données des portefeuilles MetaMask, Exodus, Bitget Wallet et Base. En résumé : il s'agit d'une attaque multi-étapes hautement sophistiquée qui cible directement les portefeuilles crypto populaires au sein de l'environnement navigateur.

La chaîne principale, appelée cassowary (CVE-2024-23222), cible les versions iOS 16.6 à 17.2.1 en exploitant une vulnérabilité de confusion de types JIT dans JavaScriptCore. Deux autres chaînes réutilisent des zero-days initialement découverts lors d'Operation Triangulation. À noter que trois CVE issus de ce kit ont été ajoutés au catalogue des vulnérabilités exploitées connues (KEV) de la CISA le lendemain de leur divulgation publique, ce qui souligne leur gravité.

L'infrastructure derrière Coruna s'étend sur plus de 50 domaines de livraison enregistrés sur une fenêtre de 10 semaines entre novembre 2025 et janvier 2026. Ces domaines sont hébergés chez Cloudflare, AWS CloudFront, un hébergeur bulletproof à Hong Kong (Datacamp Limited) et une instance AWS EC2 dédiée à Tokyo. Les 27 domaines C2 sont générés par DGA à partir de la graine « lazarus » et étaient frontés par Cloudflare au moment de la divulgation. Cette configuration d'hébergement diversifiée aide les opérateurs à contourner les tentatives de démantèlement et à maintenir leur résilience.

Le point essentiel pour les équipes web : cette charge utile est un fichier JavaScript. Elle n'a pas besoin de résider sur votre serveur pour atteindre vos utilisateurs. Une balise publicitaire compromise, un script tiers empoisonné ou un asset CDN détourné suffiraient. Vos journaux n'afficheraient rien de suspect. cside surveille en temps réel chaque script qui s'exécute dans le navigateur de vos utilisateurs — c'est la seule couche où cette attaque devient visible. Sans une telle surveillance, vous pourriez ne jamais détecter cette menace.

---

---

Références

1. Google Threat Intelligence Group, « Coruna iOS Exploit Kit Uses 23 Exploits Across Five Chains Targeting iOS 13-17.2.1 », The Hacker News, 4 mars 2026.
2. Avis de sécurité Apple, « CVE-2024-23222 : problème de confusion de types WebKit », janvier 2024. nvd.nist.gov
3. Catalogue des vulnérabilités exploitées connues de la CISA, 5 mars 2026. cisa.gov
4. Help Net Security, « Apple fixes actively exploited WebKit zero-day (CVE-2024-23222) », 23 janvier 2024.
5. Infosecurity Magazine, « Coruna Exploit Kit Targets Older iPhones in Multi-Stage Attack », mars 2026.
6. Security Affairs, « Google uncovers Coruna iOS Exploit Kit targeting iOS 13-17.2.1 », mars 2026.

---

Cette analyse est basée sur l'inspection directe d'échantillons Coruna actifs récupérés depuis des domaines de livraison en activité (b27[.]icu, 7p[.]game), combinée à des renseignements sur les menaces publics provenant de Google GTIG, de la CISA et d'iVerify. L'analyse d'infrastructure a impliqué la résolution DNS, des pivots DNS inversés via HackerTarget, des requêtes d'enregistrement RDAP, des journaux de transparence des certificats via crt.sh et le DNS passif URLScan. Toute l'analyse binaire a été réalisée dans un environnement isolé afin de garantir la sécurité.