AdFection / Candiru: come la pubblicità diventa un attacco zero-click

18 ott 2026 · @Federico

Premessa

Pochi giorni fa, il 15 ottobre 2026, Citizen Lab (Report 195, con aggiornamento del 16 ottobre) ha pubblicato la prima conferma tecnica di un attacco con spyware mercenario zero-click, ovvero che infetta il dispositivo target senza che questo abbia compiuto alcuna azione, consegnato tramite pubblicità mirata, tecnica che i ricercatori hanno battezzato AdFection, e nello stesso periodo Confiant ha pubblicato un'indagine coordinata che analizza il codice degli annunci. In questo caso gli attaccanti non hanno usato canali speciali per raggiungere i dispositivi ma la stessa infrastruttura che Internet usa ogni giorno per vendere spazi pubblicitari.

Gli attori principali sono tre e vedono Discover-Tech Ltd, una società israeliana che si presenta come operatore pubblicitario (DSP "MyDSP") ma che, secondo i ricercatori, funziona da ponte tra l'ecosistema pubblicitario e i fornitori di spyware, poi c'è Controlium,

• Controlium: la piattaforma di Discover-Tech con cui i clienti selezionano i bersagli e programmano i "controlled ads" (a inizio ottobre 2026 Google, che ha collaborato all'indagine, ha rimosso Discover-Tech dai propri registri di fornitori e ne ha interrotto l'accesso ai suoi ad exchange, con misure analoghe da parte di IAB Europe, Beeswax, Vungle ed Eskimi) ed infine Integrity Labs (ex Candiru) che è il fornitore dello spyware installato sui dispositivi, società inserita nel 2021 nella Entity List del Dipartimento del Commercio USA, acquisita nel 2025 da un fondo statunitense e che naviga ormai in acque molto agitate.

Il caso documentato riguarda la rete di Al Jazeera che ha avuto almeno 45 dispositivi presi di mira tra il 2024 ed il 2025, con infezioni da spyware di Candiru distribuito tramite annunci di giochi o banner funzionanti come cavalli di Troia (Discover-Tech.); il campione recuperato da uno dei dispositivi è una DLL per Windows.

In questa relazione ho scelto di distinguere nettamente quello che è documentato dai rapporti, quello che è ricostruito dai ricercatori e quelli che sono esempi illustrativi, con dati inventati ma coerenti o, ove possibile, presi dai dati che ho reperito nei report tecnici online e che userò per spiegare il meccanismo.

Una cosa che si legge spesso a proposito dell'industria israeliana dello spyware è che le "menti" alla base di queste attività siano reperite tra le elite del loro famigerato esercito, con dei veri e propri ingegneri "geni" rappresentati come hacker fuoriclasse.

C'è una cosa strana, un paradosso che attraversa tutta questa storia. La stessa catena capace di iniettare un vettore zero-click dentro le aste pubblicitarie mondiali, con un codice d'attacco (attribuito a Candiru) dotato di un canale cifrato C2 con ECDH e chiavi RSA per tenere fuori persino i ricercatori, e capace anche di consegnare il codice una sola volta per bersaglio per non lasciare tracce, si è però dimenticata di chiudere la porta di casa: quella dell'intermediario Discover-Tech. Davvero. Se leggete i report dei leak di sicurezza vedrete che altro che sicurezza, qui siamo a livelli da smanettone impunito e secondo me, senza nulla togliere ai ricercatori, è proprio per questo che Discover-Tech, e con lei i suoi clienti tra cui Integrity Labs, si è fatta beccare con le mani nella marmellata. Alla faccia dei geni, perché qui l'elenco degli errori è ben oltre l'imbarazzante:

• Nel pannello Controlium l'autenticazione, basata su Auth0 di Okta, sarebbe stata aggirabile banalmente (i ricercatori non l'hanno testato) perché il backend ignorava il JWT firmato da Auth0 e si fidava invece di un oggetto user cifrato con una chiave segreta, udite udite, pubblicata nel codice della piattaforma stessa e non solo, e qui viene la comica, il codice corretto, quello che avrebbe usato il JWT, c'era ma era commentato; cioè lo avevano scritto o copiato da chissadove e poi disattivato, pensando probabilmente che fosse codice inutile..

E i log di accesso? Scaricabili perfino senza password, perché l'endpoint /csv-download rispondeva a chiunque. Infatti Citizen Lab ha esportato 128 giorni di log e identificato 120 nomi utente distinti, clienti ma anche dipendenti di Discover-Tech, con i loro IP, ed è così che i ricercatori hanno collegato Controlium a Candiru/Integrity Labs, Bindecy e Intelos, non gliel'ha dettola fata turchina.

E poi la chicca delle chicce: avete mai visto una pagina di login, di una casa che tra l'altro lavora per fornitori di spyware di altissimo livello, integrare tutto (TUTTO) il frontend del pannello Controlium? Ora, questo di per sé è prassi comune nelle web app moderne; il problema è cosa conteneva quel frontend: la chiave segreta e i riferimenti a endpoint lasciati senza protezione. Infatti, pure qui, è bastato salvarla e aprirla con un editor per ricostruire l'interfaccia di un pannello di targeting per spyware mercenario.

Ma mica è finita qui, c'erano poco meno di quattro miliardi di record d'asta leggibili da chiunque, perchè due istanze Apache Druid aperte sul web esponevano la cronologia delle offerte di MyDSP. E le chiavi di cifratura? Regalate! Le chiavi AES dello schema "Ad URL OpSec" (si, proprio la protezione pensata apposta contro i ricercatori) erano pubblicate su una pagina "Decoder" del loro stesso sito myipinfo[.]io. In pratica sono stati capaci di fornire la serratura anti-analisi con la chiave appesa..

E poi il cameo. C'è un detto qui in piemonte che recita "J asu d'Cavour, je gniun ca i lauda, as laudu da lur"", che tradotto letteralmente suona come "gli asini di Cavour se nessuno li loda lo fanno da soli". Ecco, calza a pennello con la questa storia perché all'endpoint /jsConfig il pannello restituiva il messaggio ONLY DEKEL IS ALLOWED!!!, probabile riferimento al CEO Dekel Boni. Ecco, questo conclude l'opera.

E c'è poi anche che la libreria SDK consegnata ai bersagli (stavolta quella attribuita a Candiru) era offuscata in modo leggero, forse volutamente, per sembrare normale codice pubblicitario.

Sapete cosa penso io? Penso che questi geni incompresi dal mondo, almeno quelli che gestivano l'infrastruttura di Discover-Tech, abbiano sostanzialmente usato una qualche AI abliterared per generare del codice complesso, poi ci si sono affogati dentro vuoi per le capacità limitate vuoi per la fretta, ed alla fine hanno prodotto un "branded damage". Per me nulla di più semplice che sia andata in questo modo e non sono solo io a pensarlo: diversi analisti che hanno commentato i report hanno letto in queste falle una sciatteria tipica di chi vende "attacchi come servizio". Sciatteria che però sembrerebbe riguarda solo l'infrastruttura di Discover-Tech, perché il codice d'attacco attribuito a Candiru è, almeno secondo quanto scrive Confiant, "rigoroso e pulito".

Comunque l'interessante è capire come uno spyware zero possa distribuirsi attraverso una pubblicità digitale e per rispondere a questa domanda partiamo dal presupposto che un'app o una pagina web richiedono una pubblicità per monetizzare i propri spazi, ed il punto di partenza è qualunque spazio pubblicitario che sia esso un banner in un'app Android o iOS, oppure in una pagina web.

Nei dati analizzati da Citizen Lab il canale prevalente sono le app con il 76,7% delle offerte di MyDSP che riguardava impression in-app mentre solo il 23,3% il browser. Questo è un trend generale e lo sa meglio di me chi tutti i giorni opera nell'ambito delle sponsorizzazioni digitali; il mobile la fa da padrone ed è logico.

Nelle app gli annunci venivano mostrati dentro le WebView, che sono dei piccoli browser web integrati all'interno di un'app mobile e permetteno di visualizzare pagine o contenuti web direttamente dentro l'interfaccia dell'app; le app possono anche usare annunci nativi, i cui elementi sono resi direttamente dalle viste dell'app attraverso API. Il vettore documentato, però, è il codice HTML/JavaScript contenuto nella creatività, che gira proprio dentro WebView e browser: un annuncio nativo puro non esegue il JavaScript della creatività, e un'app che non mostra pubblicità non offre affatto questo canale d'ingresso.

Finite le statistiche, entriamo un po' più nei dettagli tecnici per capire come nasce il contagio e perché zero-click. Sappiate che nel mondo avvengono ogni giorno centinaia di miliardi di aste ad in tempo reale (RTB), che hanno sempre lo stesso preludio ovvero richiesta d'annuncio dal dispositivo, spazio vuoto, raccolta dei dati del dispositivo, bid request OpenRTB (una POST con JSON) verso i DSP ed asta istantanea; operazioni ripetute miriadi di volte della durata di meno di 1 secondo. Ed è proprio qui che AdFection trova terreno fertile per insinuarsi senza che l'utente debba fare nulla.

Lo spyware non aspetta che l'utente veda l'annuncio o ci clicchi sopra. Quando il DSP vince l'asta restituisce all'exchange il markup dell'annuncio, che contiene solo un tag script all'apparenza innocuo verso il server NOAS di Discover-Tech. Quando l'annuncio viene renderizzato, anche in background, il tag chiama il NOAS, che restituisce codice solo se il dispositivo è un bersaglio (a tutti gli altri risponde con zero byte): un iframe invisibile 1×1 verso un validatore di Candiru, che controlla il dispositivo e, se è quello giusto, avvia la catena che porta all'exploit e infine al server di comando e controllo. L'exploit sfrutta tipicamente una falla del browser o del motore JavaScript, seguita da una fuga dalla sandbox, che, detta in parola molto molto povere e poco poco tecniche, sfruttano la confusione del software per tentare di costringere il processore ad eseguire codice malevolo.

L'exploit usato in questo caso non è stato catturato da nessuno dei due gruppi di ricerca: quello che segue è uno schema illustrativo di una catena classica.

Tecnicamente avviene che, mentre il dispositivo renderizza la creatività della pubblicità, il codice js ricevuto viene eseguito, e questo avviene senza che l'utente possa accorgersi di qualcosa, perché tutto si svolge in un iframe invisibile e non richiede alcuna interazione.

Uno di questi file, un codice Js, è "truccato", ovvero scritto apposta per riempire porzioni dell'heap con migliaia di copie di un piccolo payload o di oggetti costruiti ad arte, così che certi indirizzi di memoria diventino prevedibili. Questa tecnica ha un nome preciso Heap Sprayng (l'heap è la memoria dinamica del processo, quella in cui il browser alloca oggetti e dati durante l'esecuzione) ed è volta a rendere prevedibile dove si troverà il codice o il dato dell'attaccante. Lo spyware vero e proprio arriva dopo, scaricato come stadio successivo; e poiché i sistemi moderni impediscono di eseguire direttamente i dati dell'heap (DEP/W^X), oggi si spruzzano più spesso oggetti finti o catene ROP che shellcode da eseguire.

Subito dopo avviene l'innesco del trigger, ovvero un componente effettivamente gestito come ad esempio una immagine webp o un font o qualsiasi altro elemento che motore di decodifica possa gestire, solo che è modificato proprio per provocare un Buffer Overflow. Si tratta di una scrittura oltre i limiti di un buffer, che sovrascrive dati adiacenti come un puntatore a funzione, una vtable o un indirizzo di ritorno, senza mandare in crash il processo (con le immagini webp è successo davvero: CVE-2023-4863).

Quando poi il programma esegue una chiamata indiretta o un ritorno, il processore carica nel registro di puntamento all'istruzione successiva (l'instruction pointer) il puntatore corrotto, cioè un valore predefenito dall'attaccante. Grazie alla moltitudine di repliche spruzzate nell'heap, quel valore finirà con alta probabilità per puntare a una tra le migliaia di copie: ed ecco che il codice dell'attaccante prende il controllo e può scaricare lo spyware.

Il contagio avviene quindi durante la fase di caricamento e rendering dei dati, spesso in un elemento invisibile o in background, e l'utente non si accorge di nulla perché non deve interagire in alcun modo con gli elementi grafici: zero-click.

Questo è tecnicamente cosa avviene. Forse vi chiederete: ma non c'è un modo per evitare che il puntatore delle istruzioni possa essere così facilmente manomesso?

La risposta è NI, perchè la protezione di questo registro specifico è stata per decenni una delle sfide più frustranti ed economicamente complessa per l'intera industria dei semiconduttori e dei processori che derivano dalla macchina di Von Neumann. La soluzione più semplice che verrebbe in mente, ovvero quella di sorvegliare il registro a ogni istruzione, sarebbe in effetti insostenibile. Per questo i controlli che si sono affermati non sorvegliano il registro ma validano i puntatori prima che vi vengano caricati, con un costo prestazionale contenuto: Control-Flow Guard di Microsoft (2015), Intel CET con shadow stack e IBT (dal 2020), ARM Pointer Authentication (Apple A12, 2018) e BTI.

Prima ancora sono state adottate tecniche particolari, come ASLR, che randomizza gli indirizzi di base a ogni avvio o caricamento, e DEP/NX, che impedisce di eseguire codice nei dati, ma gli hacker hanno escogitato altri metodi. Le fughe di informazioni servono a scoprire gli indirizzi reali e aggirare ASLR; ROP riusa frammenti di codice legittimo per aggirare DEP.

Insomma è una questione annosa, un vero incubo ingegneristico che negli ultimi anni è stato fortemente mitigato a livello hardware dai produttori di processori (PAC, CET e più di recente il memory tagging ARM MTE), ma non risolto: esistono bypass documentati, come PACMAN nel 2022.

Ma allora perchè adFectnion è riuscito ad agire? Perchè gli exploit di questo livello sono costruiti per aggirare anche queste contromisure, perchè molti dispositivi hanno CPU prive di queste estensioni o software non compilato per usarle (le patch riguardano browser e sistema operativo, non il processore), perchè ci sono altre complessità che vengono sfruttate. E soprattutto, secondo me, perchè ormai la AI è un dato di fatto.

Nel prossimo articolo vedremo più in dettaglio questi meccanismi ed anche come da una pubblicità ad si possa arrivare ad un "target" umano. Qui infatti si apre il tassello che i rapporti hanno appena iniziato a documentare (Citizen Lab annuncia un report dedicato a un attore che chiama DARK CARTOGRAPHER, capace di collegare advertising ID e numeri di telefono) e che in realtà regge tutta l'operazione, perché di uno spyware che non seleziona un targhet non se ne fa niente nessuno, se non per fare danni a caso. Controlium seleziona un dispositivo a partire da un identificatore tecnico, che può essere l'advertising ID iOS o Android, un cookie ID di MyDSP o di Beeswax, oppure l'indirizzo IP, ma l'operatore vuole colpire una persona precisa, per esempio un giornalista, serve un ponte tra l'identità reale e l'identificatore pubblicitario. Senza questo non è un'arma di precisione ma una freccia spuntata.