APT31 e UTA0560 sfruttano il patch gap di Chrome: tre zero-day portano fuori dalla sandbox Windows

🛡️ Executive Summary

• UTA0560 e JungleBamboo/APT31 hanno utilizzato la stessa catena contro Chrome e Windows, ma con infrastrutture e malware finali differenti.
• La catena combina CVE-2026-85046, CVE-2026-87491 e CVE-2026-85880 per passare da V8 al kernel Windows e al processo Chrome.
• Gli aggressori hanno sfruttato il patch gap: alcune correzioni erano già nel codice Chromium ma non ancora distribuite agli utenti Chrome.

Due distinti attori cinesi hanno trasformato il ritardo tra correzione del codice Chromium e distribuzione della patch in Google Chrome in una finestra operativa per attività di spionaggio. UTA0560 e JungleBamboo, gruppo conosciuto anche come APT31, Violet Typhoon e TA412, sono stati osservati da Volexity mentre utilizzavano la stessa catena di exploit contro Chrome e Windows, composta da tre vulnerabilità concatenate. Il passaggio più importante non è soltanto la presenza di nuove zero-day: parte del codice vulnerabile era già stato corretto upstream, ma gli utenti finali non avevano ancora ricevuto l’aggiornamento. È il cosiddetto patch gap, una zona grigia nella quale una falla può essere contemporaneamente un n-day per chi analizza Chromium e uno zero-day per chi utilizza Chrome.

Il patch gap trasforma una correzione pubblica in materiale per costruire l’exploit

La ricerca originale pubblicata da Volexity parte da una campagna individuata il 1° settembre 2026 contro diverse organizzazioni non governative. UTA0560 inviava email di spear phishing con collegamenti a un sito legittimo di un’università statunitense vulnerabile a reflected XSS. La pagina compromessa funzionava soltanto come trampolino: reindirizzava la vittima verso l’infrastruttura dell’attaccante, dove veniva eseguita una catena composta da exploit Chrome e Windows.

Volexity ha successivamente scoperto che JungleBamboo stava usando byte per byte lo stesso shellcode, attraverso domini e infrastruttura propri, per colpire obiettivi differenti. La sovrapposizione è significativa perché CVE-2026-85046 era stata segnalata al progetto Chromium già il 4 agosto e la correzione era entrata nel codice open source, ma non aveva ancora raggiunto la versione stabile di Chrome utilizzata dalle vittime. Il codice pubblico rendeva quindi teoricamente possibile individuare cosa fosse stato corretto, confrontare le revisioni e ricostruire la vulnerabilità prima che gli utenti ricevessero la patch. Volexity ritiene con confidenza media che proprio questo processo di reverse engineering del fix abbia contribuito alla realizzazione della catena.

CVE-2026-85046 apre V8 e CVE-2026-87491 permette di superare la sandbox

Il primo stadio utilizza CVE-2026-85046, type confusion nel motore JavaScript V8. L’exploit ottiene primitive di lettura e scrittura arbitraria nella memoria del processo renderer e prepara il terreno per il secondo passaggio, CVE-2026-87491, vulnerabilità WebAssembly che consente l’uscita dalla sandbox V8. Quest’ultima falla è particolarmente interessante nella cronologia della disclosure: Google l’ha corretta pubblicamente con Chrome 153 soltanto l’8 settembre, confermando contemporaneamente che un exploit era già utilizzato in attacchi reali.

La vulnerabilità era già stata analizzata da Matrice Digitale quando Chrome 153 aveva portato a sette il numero di zero-day corretti dall’inizio del 2026. Nel caso ricostruito da Volexity, però, CVE-2026-87491 non opera isolatamente: viene utilizzata tra la type confusion iniziale e la successiva escalation Windows. È quindi uno dei passaggi di una catena progettata per attraversare progressivamente i confini di sicurezza del browser anziché affidarsi a una singola vulnerabilità capace di fare tutto.

Leggi anche: BlueMoon combina le stesse zero-day Chrome e Windows e passa tra quattro gruppi di spionaggio

CVE-2026-85880 porta l’exploit dal renderer al kernel Windows

Una volta ottenuta la compromissione del renderer Chrome, entra in gioco CVE-2026-85880, vulnerabilità di escalation nel kernel Windows legata a RtlpCreateServerAcl. L’exploit verifica preliminarmente build del sistema, privilegi del processo, integrità, AppContainer, CPU e presenza di hypervisor come VMware, Hyper-V, KVM o Xen. Il modulo kernel viene eseguito soltanto sui sistemi considerati compatibili e punta principalmente a Windows 10 dalla 1809 alla 22H2, Windows Server 2022 e Windows 11 21H2. Dopo la privilege escalation, un terzo shellcode apre il processo principale di Chrome e vi inietta codice, uscendo definitivamente dal contesto ristretto del renderer. Microsoft ha corretto CVE-2026-85880 nel Patch Tuesday dell’8 settembre, ciclo nel quale Windows ha ricevuto complessivamente 966 correzioni e due zero-day già sfruttati. La sequenza mostra perché una falla locale nel kernel possa diventare estremamente potente quando viene concatenata a un exploit browser: l’utente deve soltanto raggiungere la pagina malevola, mentre il browser fornisce automaticamente all’attaccante il primo processo da cui tentare l’escalation.

L’exploit viene eseguito in un Web Worker e può riprovare cinque volte senza chiudere la pagina

La qualità operativa della catena emerge dai meccanismi costruiti attorno agli exploit. Il JavaScript verifica che la vittima utilizzi Chrome su Windows prima di procedere e carica l’exploit all’interno di un iframe invisibile. Il codice vero e proprio viene poi eseguito in un Web Worker, scelta che separa l’exploit dal thread principale della pagina: se un tentativo provoca il crash del renderer, la scheda visibile può rimanere aperta e il bersaglio continua a vedere soltanto l’immagine-esca, nel caso UTA0560 una falsa pagina per donazioni. La catena implementa inoltre un sistema di retry conservato in sessionStorage che può rilanciare automaticamente l’exploit fino a cinque volte in caso di errori recuperabili. Numerosi parametri consentono agli operatori di fermare l’esecuzione dopo singole fasi, forzare il kernel exploit, eseguire dry run o modificare l’URL del payload finale. I commenti interni analizzati da Volexity collocano lo sviluppo tra 27 e 29 agosto, pochi giorni prima delle campagne osservate. Il livello di rifinitura è rilevante perché riduce la fragilità tipica delle exploit chain browser: invece di affidarsi a un unico tentativo, l’attaccante può profilare la macchina, scegliere i passaggi necessari e recuperare automaticamente da alcuni crash.

UTA0560 installa GRIMWEDGE attraverso DLL sideloading e JScript

Dopo l’exploit, le operazioni dei due gruppi divergono. UTA0560 utilizza il parametro exeurl dell’infrastruttura per scaricare un eseguibile che estrae un programma Windows legittimo e una DLL malevola, realizzando una catena di DLL sideloading. La DLL crea un task pianificato chiamato Windows Scheduled System, comunica con il C2 attraverso un percorso costruito sul nome della macchina e scarica un pacchetto MSI che avvia codice JScript. Il payload finale, chiamato da Volexity GRIMWEDGE, viene eseguito in memoria dentro msiexec.exe e offre funzioni per inventario del sistema, enumerazione di file e processi, lettura di file fino a 5 MB, esecuzione di comandi e caricamento di ulteriori payload.

La backdoor è relativamente semplice, ma proprio per questo rappresenta un foothold flessibile: dopo avere speso una catena di tre exploit per raggiungere la macchina, UTA0560 non ha bisogno di inserire immediatamente un framework complesso. Può utilizzare GRIMWEDGE per decidere quali vittime meritino ulteriori attività. Il modello è coerente con altre campagne nelle quali gruppi di spionaggio separano nettamente l’exploit iniziale dagli strumenti successivi, evitando di esporre capacità più costose su ogni bersaglio.

JungleBamboo trasforma invece Chrome in un sensore permanente con LONGTALE

JungleBamboo/APT31 usa la medesima catena di exploit ma sceglie un risultato radicalmente diverso: installare un’estensione Chrome malevola. Il loader SUPERSTOMP modifica il file Secure Preferences, rimuove alcuni hash introdotti dalle protezioni più recenti di Chromium, inserisce l’estensione e rigenera gli HMAC legacy necessari affinché Chrome consideri valido il nuovo stato. Il passaggio sfrutta una compatibilità all’indietro ancora presente nelle release Chrome osservate da Volexity. Una volta riavviato il browser, Chrome migra la configurazione manipolata e finisce per creare i nuovi hash crittografici sulla base dello stato già alterato dall’attaccante. Il payload, LONGTALE, si presenta come una falsa estensione Google Gemini ma opera come piattaforma di sorveglianza: registra tasti e valori inseriti nei form, copia dati incollati, sottrae cookie, localStorage e sessionStorage, cattura screenshot quando compaiono keyword specifiche e invia periodicamente al C2 cronologia, sessioni e dati raccolti. È una strategia coerente con l’aumento delle campagne che trasformano estensioni Chrome ed Edge in strumenti per rubare wallet, credenziali e sessioni e con toolkit come PEEP, progettato per trasformare Chrome ed Edge in backdoor persistenti dopo una compromissione iniziale.

Due gruppi diversi con lo stesso exploit suggeriscono una capacità condivisa o venduta

UTA0560 e JungleBamboo non sembrano due denominazioni della stessa operazione. Le infrastrutture sono differenti, i payload finali sono differenti e Volexity rileva toolchain di compilazione differenti, elemento compatibile con sviluppatori separati. Ciononostante, i due gruppi hanno iniziato a utilizzare nello stesso periodo una catena contenente shellcode identico byte per byte. Volexity valuta quindi con bassa confidenza che l’exploit possa essere stato venduto o fornito a più operatori cinesi e con confidenza media che la brevissima finestra operativa del patch gap abbia favorito il riutilizzo senza modifiche sostanziali. JungleBamboo è il nome utilizzato da Volexity per l’attore conosciuto anche come APT31, Violet Typhoon e TA412, gruppo con una lunga storia di operazioni di cyber spionaggio. Il precedente è rilevante perché APT31 era già stato attribuito all’attacco contro il Parlamento finlandese e continua a mostrare interesse per raccolta di credenziali e sorveglianza più che per monetizzazione criminale immediata.

Continua con:

• UNC3569 sfrutta Sogou e un vecchio Chromium senza sandbox per distribuire GRAYRABBIT
• Chrome 152 corregge CVE-2026-85046 quando l’exploit è già utilizzato negli attacchi

Il vero zero-day è diventato il tempo tra commit e aggiornamento degli utenti

Il caso individuato da Volexity modifica il modo in cui deve essere interpretato il concetto di zero-day nell’ecosistema open source dei browser. CVE-2026-85046 era già stata corretta nel codice Chromium, ma quella correzione non era ancora presente nella versione Chrome utilizzata dalle vittime. Chi osservava il repository poteva quindi potenzialmente comprendere quale componente fosse cambiato prima che milioni di endpoint ricevessero il fix. Da una prospettiva dello sviluppatore si trattava ormai di un n-day. Dal punto di vista dell’utente Chrome continuava invece a essere una vulnerabilità senza patch disponibile. Tra questi due stati nasce il patch gap. Il problema non può essere risolto semplicemente nascondendo indefinitamente le correzioni in un progetto open source, ma diventa sempre più importante ridurre la distanza temporale tra fix upstream, build stabile e rollout effettivo. La ricerca di Volexity evidenzia inoltre un secondo cambiamento: la capacità di ricostruire rapidamente vulnerabilità partendo da diff, commit e patch può essere accelerata dagli strumenti di automazione e dagli LLM applicati alla vulnerability research. Gli attori non devono necessariamente scoprire per primi ogni falla: può bastare riconoscere una correzione interessante e trasformarla in exploit prima che la distribuzione abbia raggiunto gli utenti. Nel caso osservato, questa finestra è stata sufficiente perché almeno due attori cinesi distinti disponessero della stessa catena Chrome-Windows e la utilizzassero nello stesso momento contro obiettivi di spionaggio. Il browser era tecnicamente già stato corretto a monte, ma operativamente restava vulnerabile. Ed è proprio quella distanza, sempre più breve ma ancora sfruttabile, a essere diventata una nuova superficie di attacco.