BeyondTrust Remote Support CVE-2026-102764: zero-day cinese, root per sei settimane

Un apparato di supporto remoto privilegiato è l'unica macchina del parco che dovrebbe custodire le chiavi: media le sessioni amministrative verso ogni altro sistema e conserva le credenziali per farlo. Il 15 ottobre 2026 BeyondTrust ha divulgato CVE-2026-102764, una falla critica in BeyondTrust Remote Support (ex Bomgar) che un gruppo di cyber-spionaggio di matrice cinese sfruttava come zero-day da fine agosto — circa sei settimane di accesso non autenticato proprio a quella macchina, prima che venisse pubblicato un numero di CVE.

Notizia in evoluzione — pubblicata alle 09:38 (07:38 UTC) del 16 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-102764
Prodotto / versioni colpite	BeyondTrust Remote Support (ex Bomgar), tutte le versioni supportate fino alla 26.2.3
Corretta in	Patch BT26-05; i tenant SaaS aggiornati automaticamente nella settimana dell'8 ottobre 2026. Gli apparati self-hosted devono applicare la patch BT26-05 manualmente; le build sotto la release supportata corrente vanno prima aggiornate
CVSS	9.3 CRITICAL · CVSS 4.0 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H (assegnato dal vendor, rispecchiato da NVD)
Sfruttata attivamente	Sì — sfruttata come zero-day da fine agosto 2026; attribuita da Google Threat Intelligence Group / Mandiant ad Armory Castle (ex UNC5221), sospetto attore di matrice cinese
CISA KEV	Non presente (catalogo versione 2026.10.15)
PoC pubblico	Nessuno al 2026-10-16; GTIG ha pubblicato IOC e regole YARA, non un exploit
Advisory ufficiale	BeyondTrust BT26-05 (beyondtrust.com/blog/entry/bt26-05) e KB0024066

Cosa è successo

BeyondTrust descrive CVE-2026-102764 come una debolezza nella messaggistica interna: alcuni componenti dell'apparato "non validavano adeguatamente l'origine dei messaggi" ricevuti, cosa che in certe condizioni consente a un attaccante di eseguire operazioni su file sull'apparato (NVD, CWE-290). In pratica significa che un attaccante remoto non autenticato può scrivere file sulla macchina — e su un apparato web, un file controllato dall'attaccante nella web root è una web shell.

Google Threat Intelligence Group e Mandiant hanno pubblicato l'analisi dell'incidente lo stesso giorno, attribuendo l'attività ad Armory Castle, sospetto gruppo di matrice cinese già tracciato come UNC5221 e noto per bruciare zero-day sui dispositivi di perimetro prima che arrivino le patch. BeyondTrust ha aggiornato i tenant SaaS nella settimana dell'8 ottobre e ha divulgato pubblicamente il 15 ottobre; i clienti self-hosted devono agire a mano. Shadowserver traccia oltre 1.400 istanze Remote Support esposte su internet, e l'advisory non dice quante siano aggiornate.

Chi è esposto e come verificare la versione di BeyondTrust Remote Support

Qualsiasi apparato Remote Support self-hosted in versione 26.2.3 o precedente raggiungibile da internet durante la finestra di sfruttamento rientra nel perimetro. La stringa di versione è nel footer della console di amministrazione /login e nella pagina di aggiornamento dell'apparato. Ma la verifica di versione dice soltanto se puoi essere sfruttato d'ora in avanti — non dice nulla su se lo sei già stato tra fine agosto e il giorno della patch. Per una macchina che media sessioni privilegiate sono due domande molto diverse, e solo a una risponde un numero.

Come Armory Castle ha trasformato una scrittura su file in sei settimane di root sull'apparato

La catena documentata da GTIG è un classico playbook da dispositivo di perimetro, da leggere come modello più che come la brutta giornata di un vendor:

1. Accesso iniziale (T1190). Richieste POST verso un percorso di staging, /app_84304470%2Ephp. Circa undici minuti dopo, una web shell PHP compare sotto la web root dell'account di servizio del sito.
2. Web shell (T1505.003). SAWFLY (mangoapi.php) è una web shell PHP offuscata con trasporto Base32 e cifratura RC4. Senza il parametro _c94mfe risponde con un HTTP 404: a una scansione superficiale sembra una URL morta.
3. Escalation dei privilegi (T1548.001). L'attore ha copiato /bin/sh in /usr/bin/dbus-authd, ne ha impostato il proprietario a root e attivato il bit SUID — una backdoor root camuffata da demone di sistema.
4. Accesso alle credenziali (T1555). Da root, ha eseguito l'utility bt-secrets dell'apparato contro il vault dell'account di servizio e poi il vault globale, cancellando infine bt-secrets.log.
5. Persistenza (T1548.003). Uno script di avvio, zz-root-persist, ha aggiunto una voce sudoers NOPASSWD al template sudoers dell'apparato e ricostruito il file sudoers attivo: la modifica sopravvive al riavvio e al reset di configurazione.
6. Movimento laterale (T1021, T1098). Login su /login con credenziali amministrative compromesse, elevazione dei permessi Jump Item e Team da "No Access" ad "Administrator", sessioni di supporto remoto verso i sistemi a valle ed esfiltrazione di documenti interni.
7. Tunneling (T1572). BARECLAW, un tunneler SOCKS5-su-WebSocket personalizzato (ingredi_ws), in ascolto su 127.0.0.1:19800; una regola HAProxy iniettata instradava il percorso /uidchanarge verso di esso, esponendo il listener locale attraverso il front-end dell'apparato stesso.

"Qualsiasi apparato che fosse raggiungibile da internet su una versione vulnerabile durante la finestra di sfruttamento va considerato potenzialmente compromesso finché non sia stato esaminato." — Mandiant

La parte silenziosa di quella catena è dal passo 4 in poi. L'attaccante ha cancellato i log dell'apparato in ambito sistema, web, PHP e autenticazione. Mandiant è netto sulla conseguenza: i clienti non possono verificare il filesystem dell'host dell'apparato, la persistenza a livello host sopravvive a riavvio e reset, quindi una macchina compromessa non può essere creduta quando dice di non esserlo.

Remediation

1. Sono colpito? Verifica la versione di Remote Support nel footer della console /login; 26.2.3 o precedente è vulnerabile. Poi stabilisci la finestra di esposizione: l'apparato è stato raggiungibile da internet in qualche momento da fine agosto? Conserva subito i log di firewall e reverse proxy esterni — sono fuori dalla macchina e l'attaccante non ha potuto cancellarli.
2. Patch — applica BT26-05. I tenant SaaS sono stati aggiornati nella settimana dell'8 ottobre; gli apparati self-hosted devono applicare la patch BT26-05 manualmente, e le build sotto la release supportata corrente vanno prima aggiornate. La patch chiude la falla; non rimuove l'esposizione pregressa.
3. Non puoi applicare la patch subito? Controlli compensativi. Togli l'interfaccia di amministrazione e l'apparato dall'internet aperto — limita /login e gli endpoint client a IP di gestione noti su firewall o reverse proxy. Una regola WAF che blocca le richieste verso percorsi .php sconosciuti e scarta gli upgrade WebSocket verso percorsi non standard (es. /uidchanarge) fa guadagnare tempo, ma è un laccio emostatico, non una cura.
4. Hunting della compromissione. Mappa gli indicatori GTIG sulla tua telemetria. Sull'host: file .php inattesi sotto la web root (mangoapi.php, SHA-256 dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb), un /usr/bin/dbus-authd con SUID, lo script di avvio zz-root-persist, aggiunte sudoers NOPASSWD, accessi al vault via bt-secrets con un bt-secrets.log mancante e un listener BARECLAW (ingredi_ws, SHA-256 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462) su TCP 19800. Nei log: eventi user_changed che elevano ruoli Jump Item o Team ad Administrator, login su /login da spazi di indirizzamento residenziali o VPN, richieste a percorsi .php sconosciuti e upgrade WebSocket da sorgenti inattese. GTIG ha pubblicato le regole YARA G_Hunting_Webshell_SAWFLY_1 e G_Hunting_Backdoor_BARECLAW_1. Attenzione all'asimmetria: ogni indicatore lato host sta su una macchina di cui l'attaccante aveva root e i cui log ha cancellato.
5. Eradica e verifica. La raccomandazione di Mandiant è ricostruire, non pulire: fai prima uno snapshot dell'apparato (con memoria) per le evidenze, poi ridistribuisci da un'immagine pulita e completamente aggiornata, ripristinando solo un backup di configurazione precedente alla finestra di esposizione ed emettendo un nuovo certificato TLS. Ruota le credenziali solo dopo la patch o la ricostruzione, in ordine di dipendenza — ruotarle mentre l'attaccante controlla ancora la macchina significa consegnargli i nuovi segreti. Poi conferma che l'apparato sia pulito con le stesse evidenze con cui lo hai trovato sporco.

Rilevare la prossima breccia su apparato mentre sta accadendo

I passi 4 e 5 sono l'ammissione onesta che qui il rilevamento basato su host ha fallito per costruzione: l'unica macchina che l'attaccante possedeva per intero è quella a cui chiedevi di riferire su se stessa. Ciò che l'attaccante non ha potuto cancellare è il traffico. BARECLAW è un tunnel SOCKS5 su WebSocket verso un listener locale; il movimento laterale è un apparato di accesso privilegiato che improvvisamente apre sessioni remote verso i sistemi a valle e trasferisce documenti interni verso l'esterno. Sul filo entrambi sono anomalie rispetto alla baseline dell'apparato — una macchina che normalmente media sessioni in ingresso ora sostiene tunnel in uscita ed esfiltrazione — a prescindere da ciò che i log dell'apparato dicono, o non dicono più.

È il caso per cui è nata l'AI Traffic Analysis di Zero Hunt. È un modello di deep learning proprietario con quattro teste di inferenza parallele — traffico sospetto, classificazione del malware, identificazione del tipo di attacco e fingerprinting applicativo — addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'apparato a velocità multi-gigabit. Quando la telemetria di un host compromesso è inutile perché l'intruso ha root e ha cancellato i log, la rete è l'unico testimone che non è mai stato sotto il suo controllo — e vede il tunnel e il fan-out laterale mentre accadono, non nel digest SIEM del mattino dopo.

L'altra metà della risposta è non aspettare sei settimane che sia qualcun altro a trovare lo zero-day nel tuo apparato di perimetro. Zero Hunt è un red team autonomo basato su AI che gira on-premise sui propri modelli, con un umano nel loop per ogni azione che conta: uno swarm di 10 agenti fa il fingerprinting di un dispositivo esposto come Remote Support e, in modalità black-box di default, scrive una proof-of-concept per-target per stabilire se il tuo deployment è raggiungibile — la stessa domanda a cui la tabella delle versioni non sa rispondere, e quella a cui Armory Castle ha risposto per le sue vittime a fine agosto. Quando arriva una fix, l'AI Remediation Advisor la classifica per sfruttabilità reale e la ri-verifica con la stessa prova che ha dimostrato il problema. Per chi valuta quanto di tutto questo tenere in casa su un apparato sovrano invece che su un servizio cloud, la nostra guida all'acquisto di una piattaforma di pentest on-premise illustra i compromessi — la stessa logica di residenza del dato che rende un apparato di accesso privilegiato degno di essere difeso in primo luogo.

Cosa non si sa ancora

• Il numero esatto della versione corretta. L'advisory indica la patch BT26-05 e l'intervallo colpito ≤26.2.3; un singolo numero di build corretta non era confermabile da fonti primarie pubbliche al momento della pubblicazione.
• Il numero totale di apparati compromessi. GTIG ha documentato la tecnica su intrusioni osservate; il conteggio completo delle vittime non è pubblico, e la cifra di 1.400+ esposti da Shadowserver è esposizione, non compromissione confermata.
• Lo stato CISA KEV. Alla versione di catalogo 2026.10.15 il CVE non è presente; dato lo sfruttamento nation-state attivo di software molto diffuso, un inserimento nella KEV non sorprenderebbe. Aggiorneremo questo post se arriva.
• Se lo sfruttamento si sia allargato oltre Armory Castle ora che la falla è pubblica. Mandiant avverte che la storia del gruppo è fatta di sfruttamento ampio e opportunistico, e la divulgazione pubblica di norma allarga il campo.