Beget, un attacco wiper cancella il cloud russo: persi dati VPS, S3 e Kubernetes

🛡️ Executive Summary

• Beget subisce un attacco distruttivo nella notte tra il 1° e il 2 novembre 2026. Gli aggressori raggiungono il sistema centrale di gestione dell’infrastruttura e avviano script che cancellano i dati dei server.
• La società conferma la perdita dei dati dell’infrastruttura cloud, comprendente VPS, S3 e Kubernetes. I backup binari dei VPS sono completamente perduti, mentre quelli basati sui file permetterebbero il recupero per circa metà degli utenti VPS.
• Il ripristino richiede controlli manuali su oltre 1.000 server. Al 9 novembre risultano recuperati il 60% dell’hosting condiviso e il 40% dei server dedicati gestiti dal provider. Beget non segnala evidenze di esfiltrazione.

Beget, uno dei principali fornitori russi di hosting, cloud e registrazione di domini, è costretto a ricostruire parte della propria infrastruttura dopo un attacco informatico distruttivo che ha cancellato i dati dei servizi VPS, S3 e Kubernetes. L’incidente è avvenuto nella notte tra il 1° e il 2 novembre 2026, quando un aggressore è riuscito a raggiungere il livello centrale di gestione dell’architettura del provider, avviando script destinati ad azzerare le informazioni conservate sui server. La società, che serve complessivamente oltre 200.000 clienti, ha isolato rapidamente i sistemi per contenere la propagazione, ma non è riuscita a impedire perdite estese nei servizi cloud. Il dato più grave riguarda i backup: le copie binarie dei VPS sono state completamente distrutte, mentre il recupero attraverso backup dei file risulta possibile soltanto per una parte degli utenti. L’attacco mette in evidenza il rischio rappresentato dalla compromissione delle infrastrutture di amministrazione centralizzata, capaci di trasformare un singolo accesso privilegiato in un’interruzione estesa dei servizi.

Beget compromessa attraverso il livello centrale di gestione

Nella comunicazione ufficiale pubblicata il 3 novembre, Beget ha confermato che gli aggressori hanno ottenuto accesso al perimetro amministrativo dell’intera architettura, avviando successivamente script di cancellazione dei dati. Il provider non ha comunicato il vettore iniziale dell’intrusione, l’identità degli attaccanti o il malware utilizzato. Le informazioni disponibili permettono quindi di descrivere un’operazione distruttiva, ma non di attribuirla a un gruppo specifico. La risposta immediata è consistita nella disconnessione dei server dalla rete, una misura necessaria per interrompere le attività ostili ma sufficiente, da sola, a provocare indisponibilità diffuse. Il problema era aggravato dal livello di accesso ottenuto: un aggressore che controlla i sistemi di gestione può intervenire contemporaneamente su molte risorse, superando il perimetro della singola macchina virtuale o del singolo account cliente. Beget ha spiegato di considerare potenzialmente compromessa ogni componente coinvolta e di avere avviato una revisione completa delle configurazioni. Il ripristino non consiste quindi nella semplice riaccensione dei server, ma richiede la verifica dell’assenza di vulnerabilità residue, script nascosti e possibili meccanismi di accesso persistente.

VPS, S3 e Kubernetes perdono i dati: i backup non bastano

La conseguenza più grave è la perdita dichiarata dei dati dell’infrastruttura cloud, comprendente server virtuali VPS, archiviazione a oggetti S3 e ambienti Kubernetes. Sono andate perdute anche configurazioni relative a CDN e indirizzamenti IP, elementi necessari al corretto funzionamento dei servizi ospitati. La società distingue però il destino delle diverse tipologie di backup. Le copie binarie dei VPS, utilizzate per ripristinare immagini complete delle macchine virtuali, risultano interamente perdute. Una parte dei backup basati sui file è invece sopravvissuta. La valutazione del 6 novembre indica che tali copie dovrebbero permettere il recupero dei dati per circa metà degli utenti VPS, senza garantire il ripristino degli altri ambienti.

La differenza è sostanziale. Un backup dei file può consentire di recuperare documenti, codice e determinati dati applicativi, ma non equivale necessariamente alla ricostruzione completa di un sistema operativo, delle sue configurazioni, dei servizi e delle dipendenze originarie. Anche quando una copia esiste, Beget deve associarla correttamente al cliente e verificare l’integrità dell’ambiente nel quale sarà ripristinata. Il caso dimostra perché l’esistenza di un backup non coincide automaticamente con la capacità di recupero. È un problema già emerso nelle campagne di SafePay contro le infrastrutture di backup, dove gli aggressori cercano di neutralizzare le copie di sicurezza prima di completare le operazioni malevole.

Oltre 1.000 server da controllare e servizi ancora in ripristino

La ricostruzione interessa un’infrastruttura articolata, nella quale i diversi servizi hanno subito conseguenze differenti. Nella comunicazione del 3 novembre, Beget dichiarava già ripristinati i server dedicati amministrati direttamente dai clienti e nuovamente disponibili alcune funzionalità DNS. La società segnalava inoltre il recupero dell’80% dell’infrastruttura di posta elettronica e interventi per evitare la disattivazione dei domini russi in scadenza. Al 9 novembre 2026, secondo gli aggiornamenti riportati da BleepingComputer, il recupero raggiunge il 60% dell’hosting condiviso e il 40% dei server dedicati gestiti direttamente dal provider. Le percentuali non descrivono quindi la stessa categoria di servizio e non devono essere applicate indistintamente all’intera clientela. Le verifiche coinvolgono oltre 1.000 server, ciascuno dei quali richiede controlli manuali prima della riattivazione. Beget ha mobilitato il personale tecnico e il reparto DevOps in modalità di emergenza, collaborando con società di cybersecurity e autorità competenti. Non è stata comunicata una data definitiva per il ritorno alla piena operatività.

Un attacco distruttivo senza evidenze di furto dei dati

Un elemento rilevante riguarda la finalità osservata dell’operazione. Beget sostiene che le indagini condotte finora non abbiano individuato tentativi di scaricare i dati degli utenti né attività di manipolazione dei loro contenuti precedenti alla cancellazione. La valutazione del provider è quindi quella di un attacco orientato prevalentemente alla distruzione, piuttosto che alla sottrazione di informazioni per un’estorsione successiva. Questa distinzione separa il caso dai ransomware tradizionali, nei quali gli operatori cercano spesso di cifrare i sistemi e sottrarre documenti per ottenere un pagamento. Negli attacchi di tipo wiper, invece, l’obiettivo principale è rendere indisponibili o irrecuperabili le informazioni. L’assenza di evidenze di esfiltrazione non dimostra tuttavia che nessun dato sia stato consultato: il perimetro dell’indagine resta quello dichiarato dalla società. Il precedente delle campagne distruttive contro aziende russe attraverso Exchange e VPN mostra come cancellazione, sabotaggio e compromissione delle infrastrutture amministrative possano produrre conseguenze molto diverse dalla normale estorsione ransomware. Nel caso Beget non esistono però elementi pubblici sufficienti per attribuire l’azione a gruppi hacktivisti, servizi di intelligence o organizzazioni già note.

Il vero bersaglio è il controllo amministrativo del cloud

L’incidente richiama un rischio strutturale del cloud computing: la concentrazione delle funzioni di gestione può amplificare enormemente gli effetti di una compromissione. Hypervisor, piattaforme di orchestrazione, storage e sistemi di backup dipendono da livelli amministrativi che devono disporre di privilegi elevati. Se questi privilegi vengono sottratti o abusati, la separazione logica fra i clienti non impedisce necessariamente operazioni distruttive avviate dall’infrastruttura centrale. Un precedente significativo è rappresentato da JADEPUFFER, l’attore che ha utilizzato identità applicative compromesse per cancellare risorse Microsoft Azure. In quell’incidente, la possibilità di eliminare storage e risorse applicative dipendeva dai permessi associati alle identità utilizzate. Non esiste una prova di collegamento con Beget, ma la vulnerabilità architetturale è comparabile: chi ottiene autorizzazioni sufficienti può trasformare normali funzioni amministrative in strumenti distruttivi.

Le contromisure richiedono separazione dei privilegi, credenziali dedicate, protezioni contro la cancellazione e backup isolati dal medesimo dominio amministrativo. Le copie immutabili e quelle conservate in ambienti indipendenti riducono il rischio che un singolo accesso comprometta contemporaneamente produzione e ripristino. Occorre inoltre verificare periodicamente che quelle copie siano effettivamente utilizzabili. Beget ha raccomandato ai clienti di cambiare password, chiavi di accesso e altre credenziali eventualmente conservate sui server. È una precauzione coerente con l’incertezza sull’estensione dell’accesso ottenuto dall’attaccante, anche in assenza di riscontri pubblici sull’esfiltrazione. La lezione dell’incidente non riguarda soltanto il malware wiper, ma la resilienza del fornitore cloud. Quando vengono colpiti contemporaneamente amministrazione, dati e meccanismi di recupero, la continuità operativa dei clienti dipende dalla capacità del provider di ricostruire infrastrutture fidate e dalla disponibilità di copie di sicurezza realmente indipendenti.