// 1 CRITICAL · 4 ZERO-DAY · 7 CVE · 6 EXPLOIT NELLE ULTIME 24H
iVerify ha pubblicato l'analisi tecnica di DarkSword, un framework exploit iOS sofisticato che sfrutta vulnerabilità JavaScriptCore JIT via watering hole. La fonte

iVerify ha pubblicato il 18 marzo 2026 l'analisi tecnica di DarkSword, un framework exploit iOS multi-stadio che colpisce dispositivi Apple tramite watering hole su siti web legittimi compromessi. La scoperta, realizzata in collaborazione con Google Threat Intelligence e Lookout, documenta una chain completa in JavaScript che va dall'esecuzione remota di codice in Safari fino all'escalation di privilegi nel kernel, senza lasciare implant persistenti. Le versioni iOS target risultano 18.4-18.6.2, secondo la configurazione interna dei file exploit analizzati dalla fonte.

Punti chiave
  • iVerify ha identificato due domini ucraini compromessi come entry point: novosti[.]dn[.]ua e 7aac[.]gov[.]ua, con iframe invisibile che reindirizza verso server in Estonia.
  • L'exploit chain sfrutta vulnerabilità JavaScriptCore JIT specifiche per fasce di versione: RegExp match type confusion per iOS 18.4-18.5 e StoreBarrierInsertionPhase use-after-free per iOS 18.6-18.6.2.
  • Google Threat Intelligence risultava già a conoscenza della chain e l'aveva segnalata ad Apple; l'azienda ha inoltre osservato DarkSword utilizzato contro entità in Ucraina, Arabia Saudita, Turchia e Malaysia.
  • L'attacco termina dopo l'estrazione dei dati: il codice non prevede meccanismi di persistenza e si disattiva autonomamente, secondo quanto riportato nel post di iVerify.

Come funziona la catena di attacco su iOS

DarkSword si distingue per essere interamente costruito in JavaScript, senza binary implant o librerie mach-o tradizionali. La delivery avviene tramite iframe invisibile inserito in pagine di siti legittimi compromessi: la fonte cita esplicitamente novosti[.]dn[.]ua e 7aac[.]gov[.]ua, entrambi domini con rilevanza per utenti in Ucraina. Il reindirizzamento porta a un server geolocalizzato in Estonia che, secondo iVerify, erogava payload esclusivamente a indirizzi IP provenienti dall'Ucraina.

La prima fase sfrutta vulnerabilità nel motore JavaScriptCore JIT di Safari. Per iOS 18.4 e 18.5, iVerify documenta un attacco di type confusion nel matching RegExp; per 18.6 e 18.6.2, un use-after-free nella fase StoreBarrierInsertionPhase. Entrambe le tecniche ottengono esecuzione di codice all'interno del processo browser.

Da questa posizione, la chain aggira tre mitigazioni hardware e software di iOS: TPRO (Trusted Process Region Only), PAC (Pointer Authentication Codes) e SPRR (Special Purpose Register Restrictions). Il meccanismo, descritto nel dettaglio da iVerify, abusa strutture interne di dyld collocate in memoria stack scrivibile. Il successivo sandbox escape passa attraverso il GPU process, sfruttando un out-of-bounds write nel framework grafico ANGLE. La privilege escalation nel kernel completa la compromissione del dispositivo.

"The entire chain is built in JavaScript and does not contain any traditional binary implant or mach-o library which would be injected into other processes"

Cosa iVerify ha verificato e cosa rimane sulla carta

La fonte primaria documenta con precisione elementi verificabili: i nomi file dell'exploit chain (/rce_module.js, /sbx0_main_18.4.js, /pe_main.js), le versioni iOS target con relative tecniche JIT, i domini compromessi, il server Estonia con geofencing IP, e la collaborazione con Google e Lookout. iVerify afferma di aver riprodotto dinamicamente l'attacco su iPhone usati con iOS 18.6.x, dopo fallimenti con versioni precedenti.

Altre claim invece non dispongono di corrobazione indipendente nel dossier. Il "bypass MFA" è menzionato da iVerify ma il meccanismo tecnico non risulta dettagliato nel materiale disponibile. Analogamente, la "detection in tempo reale" tramite il prodotto MEDR di iVerify è claim promozionale del vendor, priva di verifica esterna. L'attribuzione del threat actor a operatori russi si basa su "commenti in russo nelle fasi iniziali del codice" e su collegamenti con l'attore di Coruna segnalati da Lookout, ma la fonte non espone elementi infrastrutturali che permettano attribuzione definitiva.

Il nome "DarkSword" deriva da una variabile nel codice implant: const TAG = 'DarkSword-WIFI-DUMP'. La fonte documenta che l'exfiltrazione include password WiFi, ma non specifica la natura completa dei dati estratti né il volume di dispositivi effettivamente compromessi.

Cosa fare adesso

Gli utenti con iPhone che eseguono versioni iOS 18.4-18.6.2 dovrebbero verificare la disponibilità dell'aggiornamento a iOS 26.1 o successivo, secondo quanto indicato da iVerify come versione con patch applicate. La fonte non documenta alternative di mitigazione per dispositivi che non possono aggiornare.

Le organizzazioni con utenti in Ucraina, Arabia Saudita, Turchia o Malaysia — i quattro paesi dove Google ha osservato targeting — dovrebbero considerare l'analisi del traffico web verso i domini compromessi noti. iVerify ha pubblicato gli indicatori di compromissione relativi a novosti[.]dn[.]ua e 7aac[.]gov[.]ua, oltre all'IP del server Estonia.

La mancanza di persistenza di DarkSword ha un'implicazione operativa concreta: un dispositivo compromesso non mostrerà implant residui dopo il riavvio, ma rimane vulnerabile a nuove infezioni se l'utente visita nuovamente siti compromessi. Questo pattern richiede controlli ripetuti dello storico di navigazione piuttosto che scansioni forensi tradizionali.

La fonte non fornisce istruzioni per verificare se un dispositivo specifico sia stato compromesso, né tool di detection open source. Le claim di detection del prodotto MEDR di iVerify restano non verificabili indipendentemente nel dossier.

La cronologia che la fonte non chiude

iVerify segnala che il server exploit mostrava file con ultima modifica il 23 dicembre 2025, secondo informazioni fornite da NGNG. La pubblicazione dell'analisi è avvenuta quasi tre mesi dopo, il 18 marzo 2026. La fonte non chiarisce quando iVerify abbia iniziato l'analisi, né se l'esposizione dei domini compromessi sia continuata in quel lasso di tempo. Apple non ha rilasciato conferma ufficiale delle vulnerabilità sottostanti: iVerify indica che le patch sarebbero presenti in iOS 26.1, 26.2 e 26.3, ma questo dato proviene esclusivamente dalla fonte vendor.

Google Threat Intelligence, citato nel post, risultava già a conoscenza della exploit chain e l'aveva segnalata ad Apple prima del contatto con iVerify. Lookout ha collaborato segnalando un URL sospetto "possibly related to the threat actor from Russia linked with Coruna". Questa rete di collaborazioni corrobora l'esistenza del framework, ma non verifica le claim promozionali del prodotto iVerify.

Domande che il brief non risolve

DarkSword è ancora attivo contro iPhone vulnerabili?

La fonte non documenta lo stato attuale dei domini compromessi o del server Estonia. iVerify ha pubblicato l'analisi il 18 marzo 2026, ma non specifica se l'infrastruttura risulti ancora operativa o se sia stata disattivata.

Perché l'attacco non lascia tracce di persistenza?

Secondo iVerify, il codice è progettato per "disengaged after successful data extraction". Questa scelta architetturale riduce la superficie di rilevamento da parte di strumenti forensi, ma il dossier non spiega se sia motivata da evasione o da limiti operativi degli operatori.

Qual è il ruolo effettivo di Google e Lookout nella scoperta?

Google Threat Intelligence era già a conoscenza della exploit chain e aveva segnalato ad Apple, secondo il post di iVerify. Lookout ha segnalato un URL sospetto collegato al threat actor di Coruna. Entrambe le collaborazioni corroborano l'esistenza del framework, ma non costituiscono verifica indipendente delle claim promozionali del prodotto MEDR di iVerify.

La struttura tecnica di DarkSword — exploit JIT in JavaScript, bypass di mitigazioni hardware via dyld, sandbox escape grafico, assenza di persistenza — rappresenta un evoluzione significativa nella sofisticazione degli attacchi mobile documentati pubblicamente. La lettura cauto-ottimistica è che questa esposizione renda la chain più rintracciabile; quella cauto-pessimistica, che la sua intera realizzazione in JavaScript abbassi la soglia di rilevamento per strumenti tradizionali. Entrambe restano ipotesi: la fonte non fornisce dati su detection rate o su campagne osservate al di là delle quattro nazioni citate da Google.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. iverify.io
  2. schema.org