Attacco zero-day a Chrome: APT31 sfrutta il patch gap, Google corre in 48 ore

Il 1° settembre 2026 attori minaccia legati alla Cina hanno lanciato campagne di spear-phishing contro organizzazioni non governative sfruttando una catena di tre vulnerabilità — due in Chrome, una in Windows — che Google non aveva ancora corretto nella release stabile del browser. UTA0560 e il cluster JungleBamboo (attribuito ad APT31) hanno sfruttato il cosiddetto patch gap: il ritardo tra la pubblicazione di una fix nel codice sorgente aperto di Chromium e la sua distribuzione agli utenti attraverso Chrome stable.

Il patch gap: quando la trasparenza diventa arma

Il 4 agosto 2026 il ricercatore Salvatore Gulizia ha segnalato a Chromium CVE-2026-85046, una confusione di tipo nel motore V8. La correzione è entrata nel repository pubblico del progetto, ma Google non ha rilasciato immediatamente una versione stable di Chrome. Ne è nato un intervallo di esposizione — il patch gap — durante il quale il codice della fix era visibile a chiunque, mentre gli utenti rimanevano vulnerabili.

Volexity, la società di threat intelligence che ha analizzato la campagna UTA0560, ha documentato questa condizione con precisione: la vulnerabilità era "nota e corretta a monte, rendendola un N-day a livello di sorgente Chromium, ma non esisteva un rilascio di patch per gli utenti Google Chrome". Il 1° settembre 2026, quando le email di spear-phishing hanno iniziato a colpire le ONG, Chrome stable non conteneva ancora la correzione. Google ha distribuito la versione 152.0.7977.82/.83 solo il 3 settembre, due giorni dopo l'inizio dell'attacco.

Questa dinamica trasforma un principio architetturale — la trasparenza open source — in un vettore di intelligence per gli aggressori. Il codice sorgente di Chromium permette di analizzare il diff delle correzioni, ricostruire la vulnerabilità originaria e sviluppare exploit funzionanti prima che la maggior parte degli utenti riceva la protezione.

La catena tecnica: dal browser al kernel Windows

L'exploit kit BlueMoon utilizzato nelle campagne documentate da Volexity e Proofpoint concatenava tre fasi distinte. CVE-2026-85046 forniva l'accesso iniziale attraverso una confusione di tipo nel motore JavaScript V8 di Chrome. Da lì, CVE-2026-87491 — un out-of-bounds write nel componente WebAssembly con CVSS 8.8 secondo il record NVD — permetteva l'escape dalla sandbox del browser. La terza fase, CVE-2026-85880, sfruttava un heap-based buffer overflow nel sottosistema Windows ALPC (Advanced Local Procedure Call) per elevare i privilegi fino a SYSTEM, completando la compromissione della macchina target.

Secondo l'advisory ufficiale Microsoft, CVE-2026-85880 ha un punteggio CVSS 3.1 di 7.8 ed è stato rilevato in exploitation attiva. La transizione dal processo del browser al kernel Windows rappresenta il passaggio critico che trasforma una compromissione web in controllo completo dell'endpoint.

Il kit di exploit presentava caratteristiche operative sofisticate: 13 parametri URL per test, breakpoint, telemetria e rollout controllati; un meccanismo di retry automatico con cinque tentativi per gestire fallimenti recuperabili nel Web Worker di exploit. Proofpoint ha notato inoltre pattern insoliti nel codice JavaScript — logging diagnostico esteso, commenti verbose, riferimenti ripetuti a v8CTF — che suggeriscono possibile assistenza da modelli di linguaggio nello sviluppo, o almeno una struttura progettata per aggirare i guardrail degli LLM.

Due attori, stesso codice: condivisione o mercato?

Le campagne di UTA0560 e JungleBamboo hanno condiviso shellcode identico byte per byte, secondo quanto documentato da Volexity e ripreso da SecurityAffairs. Questa sovrapposizione tecnica indica che gli exploit non sono stati sviluppati indipendentemente: Volexity valuta con bassa confidenza che il codice sia stato venduto, con confidenza media che sia frutto di uno sviluppatore condiviso.

UTA0560 ha distribuito GRIMWEDGE, un backdoor JScript che risiede in memoria attraverso msiexec.exe e si connette al server di comando e controllo ocr.opusaccel[.]top. Il payload è compatto — meno di 250 righe — e implementa comandi per elenco processi, esecuzione, upload suddiviso in chunk e valutazione di codice arbitrario tramite eval(). Volexity ha sottolineato esplicitamente che "il codice non ha persistenza, movimento laterale o meccanismo di esfiltrazione integrati oltre ai comandi di lettura file e upload". La mancanza di funzionalità avanzate suggerisce un design minimale, forse per ridurre l'impronta rilevabile o per operare in ambienti dove l'accesso iniziale è sufficiente al ruolo assegnato.

JungleBamboo ha seguito una traiettoria diversa post-exploitation: ha impiegato SUPERSTOMP per installare LONGTALE, un'estensione Chrome che si spacciava per Google Gemini (ID: ckiknalbeplpcpofpnabcnhjcegckfei). LONGTALE cattura screenshot attivati da parole chiave specifiche, ruba credenziali e monitora sessioni. Anche in questo caso Volexity ha notato una limitazione significativa: "LONGTALE manca persino di un comando base di esecuzione remota di codice che permetterebbe all'attore di condurre attività di post-exploitation aggiuntive". Entrambi i payload sono funzionalmente circoscritti, quasi modulari nella loro specializzazione.

L'estensione che resiste al riavvio: GhostChrome-X

La tecnica GhostChrome-X, documentata in dettaglio da SecurityAffairs, permette a LONGTALE di sopravvivere alla chiusura e riapertura di Chrome nonostante i meccanismi di integrità delle estensioni introdotti da Google. SUPERSTOMP rimuove gli hash crittografici delle estensioni installate e forja valori HMAC legacy, ingannando i controlli che dovrebbero bloccare estensioni modificate o non autorizzate.

Questa tecnica è apparsa pubblicamente il 6 agosto 2026 su un repository GitHub popolare, secondo quanto riportato dalle fonti. La sua adozione operativa a settembre indica un ciclo di sviluppo-adozione rapido, tipico di ambienti dove la ricerca open source viene immediatamente weaponizzata. La persistenza dell'estensione nel profilo utente — non nel sistema operativo — la rende invisibile a molti strumenti di protezione endpoint focalizzati su indicatori di compromissione a livello di macchina.

Cosa fare adesso

Le organizzazioni che gestiscono endpoint Windows con Chrome devono verificare l'aggiornamento alla versione 152.0.7977.82 o successiva, rilasciata il 3 settembre 2026, che corregge CVE-2026-85046. CISA ha aggiunto questa vulnerabilità al catalogo KEV il 4 settembre con scadenza federale per le agenzie governative statunitensi fissata al 18 settembre 2026; le stesse fonti indicano che anche CVE-2026-85880 e CVE-2026-87491 sono state incluse nel catalogo con relative scadenze.

La ricerca di indicatori di compromissione deve includere il dominio ocr.opusaccel[.]top associato a GRIMWEDGE e l'ID estensione ckiknalbeplpcpofpnabcnhjcegckfei di LONGTALE. Gli hash SHA-256 delle varianti campionate sono disponibili nei report di GBHackers e nelle analisi di Volexity.

La verifica delle estensioni Chrome installate nel profilo utente è prioritaria: GhostChrome-X modifica i file di stato delle estensioni nel percorso del profilo, non nel registro di sistema o nelle directory di installazione centralizzate. Un controllo che confronti le estensioni attive con l'inventario approvato dall'organizzazione può rilevare anomalie.

Le organizzazioni esposte a rischio di spear-phishing — in particolare ONG e istituti di ricerca politica — devono valutare la segmentazione dell'accesso web: la catena di exploit richiede l'interazione con un link malevolo in Chrome su Windows, quindi l'isolamento della navigazione web da sistemi contenenti dati sensibili riduce la superficie di esposizione al vettore primario.

"Le vulnerabilità patch-gap presentano un rischio ancora maggiore, poiché creano una finestra temporale aggiuntiva per gli attori minaccia che conducono campagne di exploitation" — Volexity (via SecurityAffairs)

Quattro gruppi, una settimana, stesso kit

La portata dell'operazione supera i due cluster iniziali. Proofpoint ha identificato quattro gruppi distinti che utilizzavano BlueMoon in una finestra compressa: APT31 (JungleBamboo) dal 28 agosto, UNK_LateNight e UNK_DoubleCheck il 2 settembre, UNK_QuietRacket il 3 settembre. Questa concentrazione temporale di attori diversi attorno allo stesso toolkit solleva interrogativi sulla struttura del mercato di exploit che li alimenta — mercato che, secondo Proofpoint, l'intelligenza artificiale potrebbe rendere accessibile a un pubblico più ampio: "Questo può riflettere un costo ridotto e una barriera all'ingresso più bassa per questa classe di capacità, poiché gli agenti AI abilitano sempre più lo sviluppo di exploit da parte degli attori minaccia".

La valutazione di Proofpoint include tuttavia un margine di incertezza: non è chiaro se l'AI sia stata effettivamente impiegata nello sviluppo o se le caratteristiche linguistiche osservate siano tecniche di framing per aggirare i guardrail dei modelli di linguaggio. Il dossier non risolve questa ambiguità.

Un modello di attacco che si ripeterà

Il patch gap di Chromium non è un incidente isolato ma una condizione strutturale. Il modello di sviluppo open source del browser più diffuso al mondo pubblica le correzioni in tempo reale, mentre il canale stable — quello utilizzato dalla stragrande maggioranza degli utenti enterprise — segue cicli di rilascio più conservativi. Questa asincronia crea finestre di vulnerabilità misurabili in giorni o settimane, durante le quali gli aggressori con capacità di reverse engineering possono ricostruire la falla originaria e costruire exploit funzionanti.

La campagna del settembre 2026 dimostra che attori statali o statalmente affini stanno sistematicamente sfruttando questa finestra. La domanda che resta aperta — e che il dossier non risolve — è se altri gruppi adotteranno questa TTP come standard operativo o se il patch gap rimarrà principalmente nelle mani di attori con risorse per la ricerca rapida su commit pubblici.

L'indicatore più preoccupante non è tecnico ma organizzativo: la condivisione di exploit identici tra cluster diversi, la compressione dei tempi tra apparizione di una tecnica pubblica e suo impiego operativo, la presenza di quattro gruppi attorno allo stesso kit in sette giorni. Questi elementi suggeriscono un ecosistema di sviluppo e distribuzione che sta maturando più rapidamente delle difese organizzative tradizionali.

Fonti

• https://thehackernews.com/2026/09/china-linked-hackers-exploit-chrome.html
• https://blog.talosintelligence.com/clickfix-moves-into-the-browser/
• https://securityonline.info/chrome-zero-day-exploit-chain/
• https://thomasharris6.wordpress.com/2026/09/15/china-linked-hackers-exploit-chrome-windows-zero-day-chain-to-deploy-grimwedge/
• https://securityaffairs.com/199104/apt/one-exploit-chain-two-espionage-campaigns-chrome-and-windows-under-fire.html
• https://gbhackers.com/china-linked-hackers-chain-chrome-zero-day/
• https://cyberpress.org/chinese-hackers-chain-chrome-and-windows-zero-days/
• https://nvd.nist.gov/vuln/detail/cve-2026-87491
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-85880
• https://github.com/asaurusrex/Silent_Chrome/commit/814fa9c2b75f95b8140ea6d460877772a2d4d507
• https://thehackernews.com/2026/09/four-spy-groups-used-same-chrome-and.html
• https://thehackernews.com/2026/09/google-releases-chrome-update-to-patch.html