Il 29 agosto 2026 la Questura di Frosinone ha pubblicato un avviso relativo a una nuova ondata di attacchi zero-click contro la clonazione account WhatsApp su dispositivi Apple. L’allarme descrive uno scenario in cui le vittime trovano messaggi inviati dal proprio numero WhatsApp senza aver autorizzato alcun dispositivo, con richieste di denaro urgenti rivolte ai propri contatti. La Polizia di Stato raccomanda di mantenere aggiornati sistema operativo e applicazione, controllare periodicamente i dispositivi collegati e attivare la verifica in due passaggi.

Si tratta di uno scenario che il nostro laboratorio aveva già analizzato e segnalato a Meta nei mesi precedenti.

Le prime evidenze raccolte: maggio 2026

A maggio 2026 il nostro laboratorio ha ricevuto i primi casi di account WhatsApp compromessi su iPhone con iOS 16. L’analisi forense ha rivelato un pattern coerente e preoccupante: tutti i dispositivi coinvolti erano iPhone con versioni di iOS 16 non aggiornate all’ultima patch disponibile, nessun dispositivo risultava collegato nella sezione “Dispositivi collegati” di WhatsApp e la compromissione avveniva senza alcuna azione richiesta alla vittima – uno scenario compatibile con un attacco zero-click.

La prova di laboratorio: replica della sessione

Dopo la segnalazione a Meta, che ha preso in seria considerazione la nostra comunicazione, il team ha proseguito la ricerca e replicato in laboratorio lo scenario osservato, riuscendo a riprodurre lo scenario 0-click. Su dispositivi di test, un client su PC ha acquisito la sessione della vittima, letto le chat recenti e inviato messaggi come titolare dell’account. È il passaggio sperimentale che sviluppa quanto documentato nel precedente articolo.

La dimostrazione mostra simultaneamente tre schermi: il client dell’attaccante su PC, l’iPhone della vittima e il dispositivo del destinatario. L’attaccante invia un messaggio – una richiesta di bonifico urgente con IBAN, identica alle segnalazioni della Polizia di Stato – che appare ai contatti come proveniente dalla vittima. Quest’ultima vede il messaggio comparire nella propria chat con l’indicazione “Tu” (hai inviato tu questo messaggio), senza averlo mai scritto.

Il test è stato ripetuto con WhatsApp 26.33.73, ossia l’ultima versione disponibile al momento della scrittura, nelle condizioni controllate del laboratorio. Le prove confermano il comportamento anche sulla versione più recente di WhatsApp. E’ importante ribadire che l’attacco è compatibile con la combinazione dei CVE-2025-43300 e 2025-55177 e che il primo costituirebbe il vettore d’ingresso ed è dipendente da una versione obsoleta di iOS. Ciò significa che aggiornando il sistema operativo vi è una mitigazione, tuttavia WhatsApp resterebbe vulnerabile e quindi è possibile che successive vulnerabilità di iOS potrebbero essere sfruttate per perpetrare l’attacco anche sulle versioni più recenti del sistema operativo.

Tradotto in termini meno tecnici, ciò significa che vulnerabilità non note (0-day) che affliggono il sistema operativo di Apple potrebbero essere impiegate per sfruttare il baco di WhatsApp. In sostanza aggiornare non mitiga completamente il rischio ma riduce drasticamente la probabilità di essere infettati.

Le vulnerabilità nello specifico

Gli advisory pubblici descrivono una catena composta da due problemi distinti: un difetto di autorizzazione in WhatsApp, utilizzabile per innescare l’elaborazione di contenuti remoti, e una vulnerabilità del framework ImageIO a “livello Apple”. Le protezioni dell’account come la verifica in due passaggi, controllo dei dispositivi collegati, PIN e blocco biometrico dell’app, restano utili contro altri vettori, ma non sostituiscono le patch che correggono questi difetti del codice.

Meta indica che CVE-2025-55177, presente in WhatsApp per iOS prima della 2.25.21.73, poteva consentire a un soggetto non correlato di innescare sul dispositivo bersaglio l’elaborazione di contenuti da un URL arbitrario. Apple descrive CVE-2025-43300 come una scrittura fuori dai limiti del buffer delle librerie vulnerabili in ImageIO, con possibile corruzione della memoria durante l’elaborazione di un’immagine malevola, corretta sul ramo iOS 16 a partire dalla 16.7.12. Meta valuta che le due vulnerabilità possano essere state usate insieme in attacchi sofisticati e mirati.

Uno zero-click non richiede che la vittima apra un messaggio, tocchi un link o autorizzi un’operazione. Negli advisory, il difetto WhatsApp poteva innescare l’elaborazione di contenuti remoti e la falla ImageIO essere attivata da un’immagine malevola. Il punto di ingresso è l’elaborazione automatica, non un gesto dell’utente: a differenza delle forme più comuni di phishing, non esiste un link che la vittima possa scegliere di non aprire.

Installare le versioni corrette chiude le vulnerabilità note descritte qui. Questo non rende però un dispositivo immune da ogni attacco futuro: una catena diversa può sfruttare una vulnerabilità nuova, precedentemente sconosciuta e non ancora corretta.

Per comprendere il motivo per cui “aggiornato” non significa “invulnerabile”, occorre distinguere quattro condizioni:

• Vulnerabilità zero-day: un attaccante può sfruttare una falla nuova prima che il produttore abbia potuto correggerla. Gli aggiornamenti disponibili non possono contenere una patch che ancora non esiste;
• Finestra di esposizione: anche dopo la scoperta di una falla passa del tempo prima che la correzione venga sviluppata, distribuita e installata. In quella finestra il rischio resta, soprattutto per bersagli selezionati. Questa è la condizione odierna;
• Compromissione già avvenuta: una patch chiude il vettore noto, ma non certifica da sola la bonifica del telefono né la revoca di una sessione già sottratta. La persistenza varia e va verificata caso per caso con analisi forense; senza evidenze specifiche non è possibile affermare che questa compromissione non sopravviva all’aggiornamento;
• Supporto del dispositivo: i modelli che restano sul ramo iOS 16 devono installare l’ultima patch disponibile – al momento della pubblicazione, iOS 16.7.16 – e valutare la sostituzione del dispositivo.

In breve: “aggiornato” non significa “immune”, ma nemmeno “ancora vulnerabile alla stessa falla”. Aggiornare iOS e WhatsApp resta la prima azione da compiere; se l’account è già compromesso, occorre anche avviare il recupero, rinnovare l’autenticazione e valutare l’assistenza forense prima di operazioni che possano cancellare prove.

Consigli finali

Si vuole di seguito riassumere un elenco di buone pratiche indipendenti dall’attacco:

• Verificare l’identità di chi chiede denaro utilizzando un canale separato: una telefonata al numero già noto, un altro dispositivo o, quando possibile, un contatto di persona.
• Per i soggetti più esposti, valutare due protezioni diverse: la Modalità di isolamento di Apple e le Impostazioni restrittive dell’account di WhatsApp. Entrambe riducono la superficie d’attacco, con possibili limitazioni d’uso. L’impiego della modalità d’isolamento non sostituisce un aggiornamento disponibile.
• Controllare periodicamente la sezione “Dispositivi collegati” di WhatsApp e disconnettere ciò che non si riconosce, sapendo che nello scenario descritto il client dell’aggressore potrebbe non comparire nell’elenco.
• Se l’account risulta già compromesso, avvisare subito i contatti, avviare la procedura di recupero e, quando è necessario preservare le prove, rivolgersi a un professionista prima di reinstallare o inizializzare il dispositivo.

Conclusioni

Il nostro laboratorio continua a monitorare l’evoluzione di questa famiglia di attacchi e mantiene aperto il canale di comunicazione con Meta per la segnalazione di eventuali sviluppi. Nel frattempo il nostro Studio ha condiviso a Meta l’ambiente che replica l’attacco con l’indicazione precisa della vulnerabilità sfruttata dagli attaccanti.

In un precedente articolo pubblicato pochi giorni fa avevamo raccontato il primo stadio della catena: la ricostruzione dell’exploit BootROM usbliter su un iPhone XS di test, con il dispositivo che transitava in modalità PWND DFU, lo stato di accesso più profondo ottenibile prima che qualsiasi componente del sistema operativo Apple venga caricato. Era la prima porta della catena. Oggi documentiamo il completamento dello stadio successivo: il boot di un ramdisk SSH sull’iPhone XS con iOS 18.7.9 installato, l’accesso al filesystem del dispositivo via sessione root, e la conferma che la catena costruita è riproducibile end-to-end.

Il risultato non è un jailbreak – il dispositivo torna alla condizione di partenza al primo reboot, senza modifiche persistenti alla memoria flash – ma è la conferma che la metodologia documentata dalla ricerca pubblica sui SoC A12 è oggi praticabile anche su iOS 18.7.9, la release stabile più recente disponibile al momento della verifica.

Dove eravamo: lo stadio uno

Nell’articolo precedente avevamo descritto la fase iniziale della catena: il caricamento sull’iPhone XS di un handler personalizzato all’interno della BootROM, tramite il payload dell’exploit usbliter distribuito attraverso un Raspberry Pi Pico configurato come ponte USB. Il risultato di quella fase era la modalità PWND DFU: il device visibile al sistema operativo host come dispositivo Apple in DFU, ma con un handler custom installato nella BootROM che esponeva due opcode aggiuntivi (CUSTOM_DEMOTE e CUSTOM_BOOT). Il dispositivo restava però in una condizione di attesa: il payload era iniettato, ma nulla girava ancora in esecuzione vera e propria oltre alla BootROM stessa.

Lo stadio uno è la porta d’ingresso, ma non è utile in sé. Serve un secondo stadio che faccia partire un ambiente controllato dall’operatore – un iBoot patchato che accetti immagini non firmate, un kernel patchato per disattivare i controlli di integrità, un ramdisk custom che contenga gli strumenti di acquisizione e analisi. È questo che abbiamo costruito nei giorni successivi.

L’ecosistema di riferimento: il progetto ICH

La ricerca pubblica su A12/A13 si è consolidata negli ultimi mesi attorno a un ecosistema di repository su GitHub che coprono i diversi livelli della catena: il firmware per il microcontrollore che esegue l’exploit iniziale, il toolkit di post-exploitation con le primitive di lettura/scrittura sulla BootROM, i patchfinder che identificano gli offset corretti nel kernel e nell’iBoot per la versione di iOS in uso, gli script di orchestrazione che assemblano l’insieme in una procedura eseguibile.

Per la costruzione del bootchain patchato – in particolare per la patch dell’iBoot che consente il caricamento delle immagini firmware non firmate da Apple, per la patch del kernel che disabilita AMFI (Apple Mobile File Integrity) e i controlli di debug, e per l’assemblaggio del ramdisk custom che permette l’esecuzione del kernel patchato – ci siamo basati sul progetto open source ICH_A12_plus_Ramdisk, sviluppato dal ricercatore Pa7r0n e disponibile pubblicamente su GitHub all’indirizzo github.com/Pa7r0n/ICH_A12_plus_Ramdisk. Il progetto automatizza l’intera fase di build del bootchain per SoC A12 e A13 e per iOS dalla versione 17 alla 27, integra i patchfinder di riferimento, gestisce l’estrazione parziale dei firmware dall’IPSW ufficiale Apple e produce un bootchain firmato con il certificato IM4M generico per l’A12.

Il progetto richiede un ambiente macOS Apple per la fase di build, perché alcuni strumenti di manipolazione dei formati di firmware Apple (IMG4, IM4M, wrapping dei coprocessori) esistono solo come binari Mach-O nativi. La fase di flash del microcontrollore e la sessione di boot successiva possono avvenire da qualsiasi macchina con libimobiledevice funzionante.

La catena tecnica in sintesi

La sequenza documentata e verificata sul nostro iPhone XS è composta da tre fasi principali. Ogni fase richiede il completamento della precedente e non è persistente al reboot del device: questa è una caratteristica desiderabile per un’attività di ricerca forense, perché garantisce che l’intervento sull’oggetto in analisi sia limitato alla sessione corrente.

Fase 1 – Applicazione dell’exploit BootROM (PWND DFU)

Il dispositivo, portato manualmente in modalità DFU, viene connesso a un Raspberry Pi Pico 2 (microcontrollore RP2350) preventivamente programmato con il firmware usbliter. Il Pi Pico innesca la vulnerabilità nel controller USB della BootROM A12 e inietta lo shellcode custom. In circa 700 millisecondi il dispositivo è in stato PWND DFU: il descrittore USB espone la stringa aggiuntiva PWND:[usbliter8] che conferma il buon esito dell’iniezione. Il dispositivo viene ora scollegato dal Pi Pico e riconnesso direttamente al computer di lavoro tramite un cavo Lightning con connettore USB-A.

Fase 2 – Boot di un iBoot patchato in modalità Recovery

Dal computer di lavoro il tool usbliter8ctl (script Python distribuito con l’ecosistema di riferimento) invia al dispositivo un iBoot personalizzato – costruito nella fase di build dal progetto ICH – tramite l’opcode CUSTOM_BOOT esposto dall’handler installato nella BootROM. L’iBoot personalizzato contiene una patch chirurgica al validatore image4 (due istruzioni ARM64 sostituite in un punto identificato dinamicamente dal patchfinder) che permette il caricamento di immagini firmware successive non firmate da Apple. Il device passa dalla modalità DFU alla modalità Recovery, riconoscibile perché libimobiledevice ora vede il dispositivo con la stringa MODE: Recovery invece di MODE: DFU.

Fase 3 – Caricamento della catena di boot completa e avvio del kernel

All’iBoot in modalità Recovery vengono ora inviati, nell’ordine documentato dal progetto ICH: il DeviceTree, il trustcache, il ramdisk contenente dropbear e gli strumenti di analisi, il kernel patchato (con le due patch AMFI e debugger applicate dal patchfinder Leeksov), e i firmware dei coprocessori (AOP, ANE, AVE, ISP, GFX, SIO) necessari alla corretta inizializzazione del bus USB nel kernel. Al termine il comando bootx innesca l’esecuzione del kernel patchato, che monta il ramdisk come rootfs, lancia il minimo indispensabile di userspace e avvia dropbear in ascolto sulla porta 22.

Il momento della verità: la sessione SSH

Terminata la fase di boot, il dispositivo continua a essere visibile al computer di lavoro come dispositivo USB, ma questa volta il suo endpoint di rete è servito dal kernel appena caricato – non più dalla BootROM o dall’iBoot. Un port forwarding USB tramite iproxy (strumento standard di libimobiledevice) espone la porta 22 del dispositivo su una porta locale del computer, e da lì una comune sessione ssh apre la shell root sul telefono. La password è quella standard del ramdisk di ricerca – alpine – che rispetta la convenzione storica dei jailbreak Apple da oltre quindici anni.

Il primo comando eseguito sulla shell è mount_ich, uno strumento distribuito con il ramdisk che monta in un colpo solo tutti i filesystem del dispositivo: il volume di sistema (sealed system snapshot, sola lettura per design a partire da iOS 15), il volume Dati utente (contrassegnato APFS con flag protect, ovvero con Data Protection attiva at rest), il volume Preboot, il volume xART. A questo punto abbiamo una vista completa della struttura del filesystem del dispositivo, e – a livello di sistema operativo – l’accesso più profondo ottenibile senza modificare permanentemente il dispositivo.

Cosa vediamo e cosa non vediamo

Il fatto che i filesystem siano montati non implica che tutti i loro contenuti siano leggibili in chiaro. iOS applica la sua protezione dati a livello di singolo file, distinguendo quattro classi di protezione: dalla classe A (“Complete”, decifrabile solo quando il dispositivo è sbloccato dall’utente) alla classe D (“NoProtection”, decifrabile senza input utente perché la chiave è derivata solo dall’UID hardware). Nella condizione di ramdisk boot post-DFU il Secure Enclave non è stato coinvolto nel processo di autenticazione utente e non ha derivato le chiavi di classe A, B e C: i file appartenenti a queste classi restano cifrati a livello di storage, e la loro apertura dal ramdisk restituisce Operation not permitted.

Ciò che possiamo ottenere adesso: acquisizione BFU

Nello stato attuale della catena la nostra postazione è in grado di eseguire un’acquisizione di tipo BFU (Before First Unlock) del dispositivo: i file di classe D – che comprendono la struttura del sistema operativo, i log di sistema, i database diagnostici, un numero non trascurabile di database applicativi non protetti da Data Protection e le cache condivise – sono immediatamente leggibili e possono essere copiati bit-a-bit dal dispositivo attraverso la sessione SSH. È lo stesso livello di accesso che gli strumenti commerciali di acquisizione full file system offrono in modalità BFU e rappresenta il risultato utile per una parte rilevante dei casi di analisi che entrano nel nostro laboratorio – in particolare quando la richiesta operativa riguarda dati di sistema, log applicativi, artefatti di rete o ricostruzione di sequenze temporali.

Ciò che non escludiamo: dialogo con il Secure Enclave (AFU-equivalent)

L’accesso ai file di classe A, B e C – che comprendono la maggior parte dei database delle app di terze parti, gli attachment delle chat, il keychain e altri artefatti tipicamente rilevanti in ambito investigativo – richiede la comunicazione con il Secure Enclave dal kernel patchato attraverso l’interfaccia IOKit AppleSEPKeyStore. Quando la password del dispositivo è nota all’operatore (perché comunicata dal titolare, come avviene di frequente nelle attività di consulenza tecnica di parte, o autorizzata dal collegio giudicante), il processo consiste nel fornirla al Secure Enclave via chiamata IOKit, ricevere in risposta le chiavi di classe derivate e passare queste ultime al driver APFS del kernel per la decifratura on-the-fly dei file. Non è una capacità che possediamo oggi sul nostro laboratorio, ma non è nemmeno un obiettivo di ricerca esplorativa: è un lavoro di ingegneria mirata sopra una base già consolidata, con un margine di tuning ragionevole per portarlo a compimento.

A conferma della praticabilità dell’approccio, il progetto pubblico usbliter8-fun (github.com/34306/usbliter8-fun) documenta una catena end-to-end funzionante su iPhone 11 Pro con iOS 27 beta che va ben oltre il ramdisk SSH: include patch al kernel per bypassare le protezioni AMFI e i controlli di trust, il dialogo con il Secure Enclave per il boot del sistema operativo completo, e il ripristino di una condizione di device operativo con SpringBoard funzionante e SSH persistente. Il progetto non è direttamente riutilizzabile sul nostro iPhone XS – l’A13 e l’A12 hanno offset kernel diversi, iOS 27 introduce strutture di sicurezza (SPTM, TXM) assenti in iOS 18, e alcune scelte progettuali di quel progetto sono incompatibili con l’uso forense che ci interessa – ma dimostra che la metodologia è consolidata e che l’estensione al nostro contesto è una questione di porting mirato e non di ricerca da zero.

Prossimi passi

Il traguardo del ramdisk SSH funzionante rappresenta un punto di consolidamento significativo della catena, ma non è il traguardo finale della ricerca. Restano da affrontare almeno tre aspetti di rilievo per l’applicabilità operativa in ambito forense:

• L’implementazione del dialogo con il Secure Enclave per lo sblocco delle chiavi di classe A, B e C, condizione necessaria per accedere ai file protetti da Data Protection quando la password del dispositivo è nota all’operatore o comunicata al collegio giudicante.
• L’automazione della procedura di acquisizione bit-a-bit dei volumi APFS del dispositivo, con generazione degli hash di integrità della catena di custodia e produzione di un’immagine in formato standard per l’analisi successiva con strumenti di parsing forense.
• L’estensione della metodologia al SoC A13 (iPhone 11, 11 Pro, iPhone SE 2020) e alle versioni più recenti di iOS su A12/A13, sulla base della ricerca pubblica in corso da parte della comunità internazionale.

Continueremo a documentare l’attività man mano che i risultati saranno consolidati. Le condizioni per una loro applicabilità in un contesto operativo – con tutte le garanzie di documentazione, riproducibilità e attendibilità che la prova digitale richiede – sono ora considerevolmente più vicine di quanto lo fossero pochi mesi fa.