La vulnerabilità di BeyondTrust Remote Support trasforma uno strumento di supporto in una via d’attacco

BeyondTrust affronta un’urgente crisi di patching dopo che gli attaccanti hanno sfruttato una grave falla di Remote Support settimane prima della sua divulgazione pubblica. La vulnerabilità di BeyondTrust Remote Support, tracciata come CVE-2026-102764, ha un punteggio CVSS di 9.3. Colpisce Remote Support versione 26.2.3 e precedenti.

CISA ha aggiunto la vulnerabilità al proprio catalogo Known Exploited Vulnerabilities il 16 ottobre 2026. L’azione conferma prove credibili di sfruttamento nel mondo reale, anziché un rischio di sicurezza teorico. CISA esorta gli operatori delle appliance self-hosted interessate ad applicare immediatamente la patch BT26-05-RS.

Il problema centrale va oltre l’installazione di un singolo aggiornamento. Le appliance Remote Support gestiscono l’accesso privilegiato a sistemi interni, credenziali e sessioni amministrative. Mandiant ha rilevato che gli attaccanti hanno usato un’appliance compromessa per stabilire persistenza, ottenere privilegi root e raggiungere endpoint a valle.

Ciò rende il patching l’inizio della risposta, non la sua conclusione. Un’organizzazione può chiudere la vulnerabilità originale lasciando però intatti gli account, gli impianti malevoli o le credenziali rubate dell’attaccante.

CISA colloca la vulnerabilità di BeyondTrust Remote Support in una tempistica di emergenza

L’avviso di CISA trasforma CVE-2026-102764 da una decisione di patching ordinaria in una priorità attiva di risposta agli incidenti.

BeyondTrust ha divulgato pubblicamente la vulnerabilità il 15 ottobre. CISA l’ha aggiunta al catalogo Known Exploited Vulnerabilities il giorno successivo, sulla base di evidenze di attacchi attivi.

L’avviso sul patching dell’agenzia si concentra sulle appliance Remote Support self-hosted. Questi sistemi richiedono un’azione diretta del cliente, a meno che gli aggiornamenti automatici non abbiano già installato la correzione.

Sono interessate Remote Support 26.2.3 e versioni precedenti. Le installazioni supportate che eseguono versioni dalla 24.3.1 alla 26.2.3 possono ricevere la patch BT26-05-RS. I clienti che utilizzano una release più vecchia devono effettuare l’upgrade prima di applicarla.

BeyondTrust afferma di aver applicato la patch a tutti gli ambienti Remote Support software-as-a-service entro il 9 ottobre. La distinzione è importante perché i sistemi self-hosted possono rimanere esposti finché ciascun operatore non completa il proprio processo di aggiornamento.

Il catalogo Known Exploited Vulnerabilities di CISA, comunemente chiamato KEV, identifica falle che gli attaccanti hanno sfruttato al di fuori degli ambienti di ricerca. Le agenzie civili federali devono correggere le vulnerabilità catalogate entro le scadenze assegnate, ai sensi della Binding Operational Directive 22-01.

Per CVE-2026-102764, la scadenza federale era il 19 ottobre, appena tre giorni dopo l’inclusione nel catalogo. Questo periodo ristretto riflette sia la gravità della vulnerabilità sia le conseguenze della compromissione di un’appliance di accesso remoto privilegiato.

Le organizzazioni esterne al governo federale non sono vincolate da tale direttiva. Tuttavia, CISA raccomanda a ogni organizzazione di usare il catalogo per stabilire le priorità nella gestione delle vulnerabilità.

L’avviso del fornitore classifica la falla come una convalida impropria dell’origine in un componente di messaggistica interno. In termini pratici, l’appliance non verificava la provenienza di determinati messaggi.

Nelle giuste condizioni, un attaccante remoto può abusare di questa debolezza per eseguire operazioni sui file senza autenticazione né interazione dell’utente. Mandiant afferma che upload arbitrari di file possono portare al controllo a livello host.

Questo percorso spiega perché le normali finestre di manutenzione siano inappropriate in questo caso. Un attaccante remoto non autenticato non ha bisogno di credenziali valide, di una vittima di phishing o di una sessione di supporto esistente per iniziare lo sfruttamento.

CISA richiede inoltre un triage forense per i sistemi federali interessati. Il requisito riconosce un limite cruciale del patching: installare software corretto non rivela se un attaccante sia entrato prima dell’aggiornamento.

Le organizzazioni dovrebbero anzitutto confermare l’esatta versione di Remote Support e lo stato della patch. Dovrebbero inoltre determinare quando l’appliance è stata raggiungibile da internet e conservare i log relativi all’intero periodo di esposizione.

L’attacco è iniziato prima che i difensori avessero una patch

L’intervallo pericoloso è iniziato a fine agosto, circa sei settimane prima che la divulgazione pubblica offrisse a ogni difensore un percorso chiaro di correzione.

Mandiant ha identificato lo sfruttamento da parte di ARMORY CASTLE, un gruppo di spionaggio sospettato di legami con la Cina e precedentemente tracciato come UNC5221. L’indagine colloca l’attività zero-day osservata al 29 agosto 2026.

Uno zero-day è una vulnerabilità sfruttata prima che le organizzazioni interessate dispongano di una correzione pubblicamente disponibile. Questa tempistica ha dato all’attaccante un vantaggio che nessun programma di gestione delle patch avrebbe potuto eliminare in anticipo.

BeyondTrust afferma che l’attore ha compromesso un’istanza Remote Support ospitata dall’azienda e un’appliance self-hosted il 29 agosto. Al momento della pubblicazione, l’azienda non ha segnalato prove di ulteriori attività avversarie dopo questi due casi noti.

Questa cifra descrive incidenti confermati, non il numero massimo di sistemi interessati. Altre compromissioni potrebbero non disporre di prove conservate, specialmente quando un attaccante può eliminare i log dall’appliance.

Il processo di scoperta mostra anche quanto facilmente i segnali d’allarme possano frammentarsi. BeyondTrust ha avviato una caccia alle minacce correlata dopo che il 27 settembre è diventato pubblico uno sfruttamento che coinvolgeva un altro fornitore di sicurezza.

Il 28 settembre, il team di cyber defense di BeyondTrust ha identificato evidenze nel proprio ambiente ospitato. L’azienda afferma di aver contenuto quell’istanza entro 27 minuti dal primo rilevamento.

Il suo team di sicurezza del prodotto ha riprodotto il metodo di accesso quella sera, mentre il reparto engineering ha iniziato a sviluppare una correzione. Mandiant ha condiviso i risultati dell’indagine sul cliente self-hosted il 30 settembre.

BeyondTrust ha rilasciato la patch ai clienti hosted e self-hosted l’8 ottobre. Afferma che i suoi ambienti Remote Support SaaS avevano ricevuto la correzione entro il 9 ottobre.

La divulgazione pubblica coordinata è seguita il 15 ottobre. Questo calendario ha dato ai clienti una breve opportunità per applicare la patch prima che la reportistica tecnica accrescesse la consapevolezza della vulnerabilità.

Tuttavia, la divulgazione pubblica crea una seconda corsa. Gli attaccanti possono usare un avviso, una patch e il comportamento del prodotto per studiare la falla, anche quando un fornitore trattiene istruzioni dettagliate sullo sfruttamento.

BeyondTrust ha trattenuto dettagli tecnici sullo sfruttamento mentre i clienti aggiornano i propri sistemi. Tuttavia, la descrizione pubblica dell’azienda identifica comunque il componente vulnerabile e il confine di sicurezza che ha fallito.

ARMORY CASTLE ha già preso di mira dispositivi edge di Citrix e Ivanti. I dispositivi edge si collocano tra reti esterne e risorse interne sensibili, rendendoli punti di accesso attraenti per le operazioni di spionaggio.

Google Threat Intelligence Group prevede che l’attore continui a sfruttare vulnerabilità zero-day in prodotti di questo tipo. La sua valutazione si basa su campagne ripetute, strumenti specializzati e una conoscenza dettagliata delle piattaforme prese di mira.

Il gruppo è inoltre passato dall’uso selettivo degli zero-day a uno sfruttamento più ampio dopo che vulnerabilità precedenti sono divenute pubbliche. Questa storia rende ogni appliance Remote Support ancora priva di patch più esposta dopo la divulgazione.

I primi incidenti forniscono quindi un avvertimento, non un rassicurante limite massimo. I difensori devono presumere che altri gruppi possano sviluppare metodi di sfruttamento indipendenti dopo aver studiato le evidenze pubbliche.

L’accesso ai file è diventato controllo root e movimento laterale

Questo attacco è stato rilevante perché una falla nelle operazioni sui file è diventata un percorso dall’internet pubblico al controllo privilegiato sui sistemi connessi.

La capacità iniziale della vulnerabilità sembra più limitata dell’intrusione che ne è derivata. BeyondTrust descrive operazioni non autorizzate sui file, mentre Mandiant ha osservato gli attaccanti trasformare tale accesso in un punto d’appoggio amministrativo persistente.

Secondo l’analisi dell’incidente, ARMORY CASTLE ha caricato una webshell PHP personalizzata chiamata SAWFLY. Una webshell è uno script lato server che consente a un attaccante di impartire comandi tramite richieste web.

Gli investigatori hanno rilevato che SAWFLY utilizzava comunicazioni di comando e controllo crittografate e restituiva una falsa risposta 404 quando le richieste non contenevano il parametro previsto. Questo comportamento l’ha aiutata a evitare la scansione automatizzata di base.

L’attaccante ha creato SAWFLY circa 11 minuti dopo la prima richiesta osservata associata allo sfruttamento. Inizialmente veniva eseguita tramite un account di servizio con privilegi inferiori sull’appliance.

ARMORY CASTLE ha poi copiato una shell di sistema e le ha assegnato permessi Set User ID. SUID è un permesso Unix che consente a un programma di essere eseguito con i privilegi del suo proprietario anziché con quelli del chiamante.

Poiché la shell copiata apparteneva a root, la modifica ha creato un percorso verso l’esecuzione a livello root. Questo accesso ha posto il sistema operativo, la configurazione e i segreti archiviati dell’appliance alla portata dell’attaccante.

Mandiant ha osservato tentativi di usare un’utilità proprietaria di BeyondTrust per estrarre credenziali dal database dei segreti dell’appliance. L’attore ha provato diversi formati di comando cercando dati del vault specifici degli account e globali.

Gli investigatori hanno inoltre trovato uno script di avvio che concedeva all’account di servizio privilegi root senza password. Lo script modificava un modello di configurazione e ricostruiva il file dei permessi attivi.

Questo progetto era importante perché un semplice riavvio non lo avrebbe rimosso. Mandiant afferma che la persistenza poteva sopravvivere anche a un ripristino della configurazione, compromettendo due comuni presupposti di recupero.

Gli attaccanti non si sono fermati al controllo dell’appliance. Hanno usato credenziali di amministratore compromesse per entrare nel portale amministrativo di Remote Support.

Hanno modificato i permessi di Jump Item e Team da “No Access” a “Administrator”. I Jump Item rappresentano sistemi o dispositivi resi disponibili per l’accesso remoto tramite la piattaforma BeyondTrust.

Questa modifica dei permessi ha creato un accesso dall’aspetto autorizzato agli endpoint a valle. L’attaccante poteva avviare sessioni remote attraverso gli stessi flussi di lavoro normalmente usati dal personale di supporto fidato.

Mandiant ha osservato una sessione verso un endpoint interno e l’uso della funzione di trasferimento file di Remote Support. L’attore ha scaricato documenti sensibili, comprese informazioni sull’inventario software, dall’ambiente desktop di un utente.

Il gruppo ha inoltre distribuito BARECLAW, uno strumento di tunneling personalizzato che ha creato un proxy SOCKS5 sul traffico WebSocket. Un proxy SOCKS5 inoltra connessioni di rete e può fornire accesso oltre l’host inizialmente compromesso.

L’attaccante ha modificato la configurazione HAProxy dell’appliance per esporre BARECLAW tramite un percorso di richieste accessibile da internet. HAProxy è il reverse proxy che instrada il traffico in ingresso dell’appliance verso i servizi interni.

Questa configurazione ha nascosto il tunneler dietro un servizio pubblico previsto. Ha inoltre fornito un percorso per raggiungere altre destinazioni di rete attraverso l’appliance compromessa.

La vulnerabilità di BeyondTrust Remote Support ha quindi creato più di un problema isolato dell’appliance. Ha trasformato un punto di controllo di supporto affidabile in una piattaforma per furto di credenziali, persistenza e movimento laterale.

Il patching non rimuove un attaccante già presente

Un aggiornamento riuscito blocca nuovi sfruttamenti, ma non revoca le credenziali rubate né cancella la persistenza creata prima dell’installazione.

Questa distinzione è il compromesso centrale dell’articolo. Le organizzazioni necessitano di un patching rapido per chiudere il punto di ingresso, ma la velocità non può sostituire l’indagine richiesta dopo una possibile esposizione.

Per le distribuzioni self-hosted supportate, gli amministratori dovrebbero installare BT26-05-RS tramite l'interfaccia dell'appliance. Dovrebbero confermare l'installazione anziché presumere che gli aggiornamenti automatici siano stati completati correttamente.

I sistemi precedenti alla versione 24.3.1 richiedono un aggiornamento prima di poter ricevere la patch. L'aggiornamento risolve la falla solo dopo l'applicazione del successivo aggiornamento di sicurezza.

Un'appliance vulnerabile raggiungibile da internet durante la finestra di sfruttamento dovrebbe essere sottoposta a ulteriori verifiche. Mandiant raccomanda di considerare tali sistemi potenzialmente compromessi finché un'analisi non dimostri il contrario.

La conservazione delle prove dovrebbe precedere il riavvio o la ricostruzione di un sistema sospetto. Ove le procedure operative lo consentano, le appliance virtuali dovrebbero essere acquisite con dati di memoria e disco.

Gli operatori di appliance hardware dovrebbero coordinare la conservazione delle prove con il supporto BeyondTrust. I clienti non possono ispezionare in autonomia ogni porzione protetta del file system host dell'appliance.

I log esterni diventano particolarmente importanti perché gli investigatori hanno osservato un'ampia cancellazione dei log. Durante l'intrusione, l'attaccante ha rimosso registri di sistema, applicazioni, server web e strumenti per le credenziali.

I team di sicurezza dovrebbero esaminare dati di firewall, web application firewall, reverse proxy, identità, endpoint e gestione delle informazioni e degli eventi di sicurezza. Un SIEM raccoglie e correla centralmente gli eventi di sicurezza provenienti da più sistemi.

BeyondTrust raccomanda di inviare il syslog dell'appliance e gli eventi di sessione a un SIEM esterno quasi in tempo reale. I record esterni restano disponibili quando un attaccante elimina le prove locali.

Tra i comportamenti utili da rilevare figurano accessi amministrativi da indirizzi VPN residenziali o commerciali sconosciuti. I difensori dovrebbero inoltre indagare script inattesi nelle directory web e shell avviate da account di servizi web.

Le modifiche alle autorizzazioni meritano particolare attenzione, soprattutto quelle relative a Jump Items, Teams, account API o policy di sessione. Ogni modifica dovrebbe corrispondere a una richiesta approvata e a un amministratore noto.

Anche un'interruzione nell'inoltro dei log esterni può essere significativa. BeyondTrust evidenzia in particolare le interruzioni che iniziano e terminano all'interno di una singola sessione amministrativa.

Hash di file noti e regole YARA possono supportare le attività di hunting, ma non possono fornire una garanzia completa. Le regole YARA identificano file o contenuti in memoria tramite pattern e condizioni definiti.

BeyondTrust afferma che l'attore ha modificato infrastruttura e strumenti tra le diverse vittime. Un'organizzazione che non rilevi nessuno degli indicatori pubblicati non ha dimostrato che la propria appliance sia rimasta pulita.

Una compromissione confermata o non risolta può giustificare la ricostruzione a partire da un'immagine nuova e completamente aggiornata. La pulizia di singoli file è meno affidabile quando un attaccante ha ottenuto privilegi root e modificato i meccanismi di persistenza.

La rotazione delle credenziali deve seguire il contenimento o la ricostruzione. Ruotare i segreti mentre un attaccante controlla ancora l'appliance può esporre immediatamente le credenziali sostitutive.

L'ambito della rotazione dovrebbe includere amministratori dell'appliance, account Remote Support, segreti API, account di bind della directory e credenziali di accesso privilegiato integrate. Dovrebbe inoltre coprire le credenziali immesse durante le sessioni di supporto interessate.

I team devono esaminare gli endpoint a valle raggiunti tramite l'appliance. I report di sessione e le cronologie dei trasferimenti di file possono mostrare a quali sistemi l'attaccante ha avuto accesso e quali informazioni ne sono uscite.

Una valutazione tecnica raccomanda analogamente la mitigazione d'emergenza e un'indagine su eventuali compromissioni precedenti. Avverte che la sola applicazione della patch non rimuove la persistenza già instaurata.

L'accesso remoto self-hosted comporta un diverso onere di sicurezza

L'incidente evidenzia una fondamentale divisione operativa: i servizi ospitati possono ricevere una correzione centralizzata, mentre le appliance self-hosted dipendono da migliaia di decisioni locali.

BeyondTrust afferma che i suoi clienti SaaS hanno ricevuto la mitigazione prima della divulgazione pubblica. I clienti self-hosted devono verificare versioni, percorsi di aggiornamento, impostazioni degli aggiornamenti automatici e stato effettivo della patch.

L'hosting autonomo può offrire controllo diretto su dati, rete e manutenzione. Trasferisce però al cliente una maggiore responsabilità per mitigazione rapida, monitoraggio, conservazione delle prove e ripristino.

Questa responsabilità diventa difficile quando una piattaforma di accesso remoto supporta operazioni essenziali. Isolare l'appliance può interrompere il lavoro dell'help desk, il supporto dei fornitori e l'amministrazione remota in tutta l'organizzazione.

Gli attaccanti beneficiano di questa esitazione. Ogni ora spesa a negoziare tempi di inattività può preservare la loro opportunità di sfruttare un sistema esposto a internet.

Il team di sicurezza necessita quindi di un piano operativo prima della prossima emergenza. Tale piano dovrebbe identificare chi può autorizzare l'isolamento, come prosegue il supporto e dove verranno archiviati i dati forensi.

Le appliance di accesso remoto creano inoltre un rischio concentrato perché collegano intenzionalmente utenti esterni a sistemi interni. Possono archiviare credenziali, iniettare segreti, mantenere agenti sugli endpoint e mediare sessioni privilegiate.

Compromettere una piattaforma di questo tipo può aggirare i controlli implementati altrove. La sessione dannosa può transitare attraverso un prodotto approvato e utilizzare autorizzazioni associate a un amministratore legittimo.

Questo schema non è esclusivo di BeyondTrust. Secondo i ricercatori sulle minacce di Google, ARMORY CASTLE ha in precedenza sfruttato vulnerabilità di Citrix NetScaler e Ivanti Connect Secure.

Questi prodotti differiscono per progettazione e finalità, ma condividono una posizione strategica al confine della rete. Elaborano accessi fidati restando al contempo raggiungibili da reti esterne.

Questa combinazione ha reso i sistemi edge un bersaglio ricorrente per operazioni di spionaggio e criminali. Gli strumenti tradizionali per endpoint possono avere visibilità limitata sulle appliance irrobustite con accesso host ristretto.

Il caso BeyondTrust aggiunge un'altra sfida. Un attaccante può utilizzare le funzionalità native del prodotto per sessioni remote e trasferimenti di file dopo aver ottenuto il controllo amministrativo.

L'attività generata tramite funzioni native può assomigliare a un legittimo lavoro di supporto. Il rilevamento deve pertanto considerare identità, tempistica, reti di origine, modifiche delle autorizzazioni e ticket di assistenza associati.

Le organizzazioni dovrebbero limitare le interfacce amministrative a reti affidabili o indirizzi approvati. L'esposizione pubblica dovrebbe essere limitata ai servizi specifici necessari a clienti e personale di supporto.

Anche l'accesso alla rete in uscita merita controlli. Un'appliance di supporto remoto dovrebbe raggiungere solo i servizi necessari per aggiornamenti, licenze, logging, directory e integrazioni.

Il filtraggio in uscita con criterio di negazione predefinita può limitare il tunneling e il traffico di comando e controllo. Crea inoltre avvisi utili quando l'appliance contatta una destinazione inattesa.

L'accesso amministrativo dovrebbe richiedere, ove supportata, l'autenticazione multifattore resistente al phishing. Gli account locali dovrebbero essere ridotti al minimo, con qualsiasi account di emergenza protetto e monitorato.

Questi controlli non sostituiscono BT26-05-RS. Riducono il raggio d'impatto quando una vulnerabilità aggira completamente il primo livello di autenticazione.

Anche i clienti Privileged Remote Access devono prestare attenzione. BeyondTrust afferma che PRA condivide codice interessato, sebbene i suoi test non abbiano identificato un percorso di sfruttamento funzionante in quel prodotto.

L'azienda ha rilasciato una patch precauzionale per PRA e consigliato ai clienti self-hosted di installarla. Si tratta di una raccomandazione basata sul rischio, non della conferma che gli attacchi osservati abbiano compromesso PRA tramite CVE-2026-102764.

Una chiara delimitazione dell'ambito è importante durante una risposta urgente. I team non dovrebbero descrivere come fatto accertato uno sfruttamento di PRA non verificato, ma non dovrebbero ignorare il codice vulnerabile condiviso.

Cosa dovrebbero monitorare i difensori dopo CVE-2026-102764

Il prossimo banco di prova è stabilire se l'adozione della patch supererà lo sfruttamento più ampio e se le indagini scopriranno intrusioni nascoste prima della divulgazione.

Il primo segnale è lo stato della patch delle appliance Remote Support self-hosted. I team di sicurezza dovrebbero monitorare l'installazione verificata, non soltanto richieste di modifica approvate o manutenzioni programmate.

Una popolazione esposta in diminuzione ridurrebbe le opportunità per gli attaccanti che copiano la campagna originale. La continua visibilità su internet di sistemi privi di patch rafforzerebbe le aspettative di sfruttamento opportunistico.

Il secondo segnale è l'emergere di nuovi comportamenti degli attaccanti. Mandiant ha documentato SAWFLY, BARECLAW, manipolazione delle autorizzazioni, cancellazione dei log e abuso delle sessioni di supporto.

Altri gruppi non devono riutilizzare quegli stessi strumenti. Nuove webshell, percorsi di richiesta, account o metodi di tunneling dimostrerebbero che lo sfruttamento è andato oltre un unico operatore noto.

I difensori dovrebbero quindi cercare sequenze comportamentali anziché esclusivamente indicatori esatti. La creazione inattesa di file seguita da modifiche dei privilegi e sessioni amministrative è un segnale più durevole di un singolo nome file.

Il terzo segnale è ciò che le revisioni forensi rivelano sul periodo precedente alla divulgazione. Ulteriori casi risalenti ad agosto o settembre amplierebbero la finestra di esposizione nota e la popolazione interessata.

Queste prove potrebbero emergere lentamente. I log dell'appliance possono essere incompleti e l'accesso a valle può confondersi con la normale attività di supporto.

Le organizzazioni dovrebbero conservare i record pertinenti mentre le indagini proseguono. Brevi periodi di conservazione dei log possono cancellare le prove necessarie per distinguere un tentativo di exploit da una completa intrusione nella rete.

L'incidente solleva anche interrogativi sul triage automatizzato degli avvisi. BeyondTrust ha riferito che i suoi sensori hanno rilevato una sospetta escalation dei privilegi, ma un sistema di terze parti ha chiuso gli avvisi come falsi positivi.

I team di sicurezza dovrebbero conservare e riesaminare periodicamente gli avvisi respinti dai sistemi automatizzati. Un giudizio a bassa confidenza non dovrebbe rimuovere permanentemente un comportamento insolito dell'appliance dall'ambito del threat hunting.

Il catalogo KEV rimane un importante segnale di prioritizzazione, ma l'inclusione nel catalogo non dovrebbe avviare il cronometro. Prove confermate dal fornitore o dalla risposta agli incidenti possono giustificare un'azione prima che CISA pubblichi una voce.

Lo stesso principio si applica dopo l'applicazione della patch. Una scansione delle vulnerabilità con esito positivo conferma software corretto, non un ambiente pulito.

Per le organizzazioni che gestiscono BeyondTrust Remote Support, l'azione immediata è chiara: verificare la patch BT26-05-RS e documentarne il risultato. Le installazioni più vecchie devono essere aggiornate prima di ricevere la correzione.

Successivamente, occorre stabilire se l'appliance fosse raggiungibile dall'esterno mentre era vulnerabile. Conservare i log esterni, esaminare le modifiche amministrative e tracciare ogni sessione di supporto sospetta fino ai sistemi a valle.

Se non è possibile escludere una compromissione, coinvolgere il supporto BeyondTrust e un team di risposta agli incidenti. Ricostruire le appliance dubbie, ruotare le credenziali esposte e ispezionare gli endpoint raggiunti tramite esse.

La vulnerabilità di BeyondTrust Remote Support è in definitiva un test di due velocità di risposta. Una chiude la falla, mentre l'altra scopre ciò che è accaduto prima della chiusura.

Le organizzazioni che svolgono soltanto il primo compito restano esposte alle conseguenze del secondo. Il vostro team sta verificando una patch o dimostrando che un sistema di accesso fidato è rimasto affidabile?