BeyondTrust ha reso pubblica la CVE-2026-102764, una vulnerabilità critica (CVSS 4.0: 9.3) in Remote Support, il prodotto di assistenza remota e accesso privilegiato molto diffuso in aziende e MSP. L'aspetto più importante non è il punteggio, ma la cronologia: la falla è stata sfruttata come zero-day dalla fine di agosto, mentre la patch è del 8 ottobre e la divulgazione del 15-16 ottobre. Per quasi sei settimane gli attaccanti hanno avuto un vantaggio che nessun aggiornamento programmato poteva colmare.

Cosa è successo

La falla è un problema di validazione dell'origine (CWE-290) in un componente interno di messaggistica di Remote Support. Un attaccante remoto e non autenticato può eseguire operazioni sui file e, come hanno mostrato gli attacchi osservati, arrivare ai privilegi di root sull'appliance. Sono interessate le versioni fino alla 26.2.3 incluse. L'istanza SaaS è stata aggiornata automaticamente (Mandiant indica il 9 ottobre); per le installazioni self-hosted serve la patch BT26-05-RS. Privileged Remote Access condivide il codice vulnerabile: BeyondTrust non ha trovato un percorso di sfruttamento, ma raccomanda la patch preventiva.

Google Threat Intelligence Group e Mandiant attribuiscono l'attività a Armory Castle (in precedenza UNC5221), un gruppo sospettato di spionaggio con base in Cina, attivo almeno dal 2023 e noto per colpire dispositivi perimetrali. Secondo la cronologia di BeyondTrust, il primo sfruttamento risale al 29 agosto 2026 contro un'istanza ospitata e un'appliance self-hosted; circa undici minuti dopo è comparsa nella web root una web shell PHP chiamata SAWFLY. L'intrusione è stata scoperta il 28 settembre: gli avvisi della piattaforma di rilevamento erano stati inizialmente chiusi come falsi positivi, un dettaglio che ricorda quanto sia fragile la fase di triage.

Dopo l'ingresso, i report descrivono una catena coerente: elevazione a root, persistenza con una voce sudo senza password, tentativi di estrarre il vault delle credenziali con lo strumento bt-secrets, cancellazione di oltre una dozzina di log, innalzamento dei permessi di Jump Item e Team di un account amministrativo e, infine, un tunnel SOCKS5 chiamato BARECLAW con modifiche alla configurazione HAProxy per instradare il traffico. Al 15 ottobre non risultava confermato uno sfruttamento di massa, e le informazioni tecniche complete sono ancora trattenute da BeyondTrust per dare tempo ai clienti di aggiornare. Non è chiaro, dalle fonti, se la CVE sia già nel catalogo CISA KEV.

Cosa significa per le aziende italiane

Gli strumenti di assistenza remota sono un bersaglio ideale perché per costruzione hanno ciò che l'attaccante cerca: accesso privilegiato a molti sistemi interni e un archivio di credenziali. Prendere il controllo dell'appliance non significa compromettere un solo server, ma ereditare le "chiavi" verso decine di endpoint, server e reti dei clienti.

Per le realtà italiane il rischio ha due volti. Il primo riguarda le aziende e gli enti che gestiscono in proprio Remote Support on-premises: spesso l'appliance è esposta su Internet per permettere agli operatori di collegarsi, e viene aggiornata con i tempi dei cicli di manutenzione, non con quelli di un zero-day. Il secondo riguarda gli MSP e i fornitori di assistenza che usano BeyondTrust per accedere ai sistemi dei clienti: una compromissione del fornitore diventa una compromissione dei clienti, con la stessa dinamica vista nel caso ConnectWise di questi giorni.

Un messaggio utile da consulente: applicare la patch non basta. BeyondTrust stessa avverte che l'aggiornamento non rimedia a una compromissione già avvenuta. Chi aveva un'appliance raggiungibile da Internet con versione vulnerabile dal 29 agosto in poi deve trattarla come potenzialmente compromessa finché non dimostra il contrario. In termini pratici significa conservare le prove, verificare e ricostruire, non solo riavviare.

Profilo normativo

Per i soggetti NIS2 la gestione delle vulnerabilità e la sicurezza della catena di fornitura sono misure di gestione del rischio, e un'intrusione in uno strumento di accesso privilegiato può costituire un incidente significativo con obblighi di notifica al CSIRT Italia. Se tra i sistemi raggiunti dall'attaccante ci sono dati personali, entra in gioco anche la valutazione di una violazione ai sensi dell'art. 33 GDPR (notifica al Garante entro 72 ore da quando se ne ha conoscenza, quando il rischio non è improbabile). La valutazione va fatta con il proprio DPO o con un legale.

Cosa fare subito

  • Identificare tutte le istanze di BeyondTrust Remote Support e Privileged Remote Access, anche quelle dimenticate o gestite da terzi, e verificare versione ed esposizione.
  • Applicare la patch BT26-05-RS sulle installazioni dalla versione 24.3.1 alla 26.2.3; le versioni più vecchie vanno prima portate a una release supportata. Le istanze SaaS sono già aggiornate.
  • Limitare l'accesso alle interfacce /login e /appliance a reti attendibili, restringere il traffico in uscita e inoltrare i log fuori dall'appliance.
  • Eseguire una verifica di compromissione per le appliance esposte nel periodo di sfruttamento: file PHP sconosciuti nelle directory web (per esempio mangoapi.php o app_84304470%2Ephp), il binario ingredi_ws, voci sudoers inattese, modifiche alla configurazione HAProxy, sessioni privilegiate da indirizzi residenziali o VPN, buchi nei log inoltrati.
  • Fare uno snapshot prima di riavviare le appliance sospette, poi ricostruirle da un'immagine pulita e già aggiornata.
  • Ruotare le credenziali dopo la bonifica e non prima: account amministrativi, segreti API, materiale SAML, credenziali del vault e delle integrazioni, credenziali delle sessioni di supporto.
  • Rivedere i permessi di Jump Item e Team per cercare innalzamenti anomali.

I riferimenti tecnici completi, incluse le regole YARA di Mandiant, sono consultabili nelle fonti indicate.