À deux heures du matin, des individus malveillants ont pris le contrôle d'un grand hébergeur. À 02h30, ils ont lancé un programme de destruction de données. À 02h55, les serveurs ont été déconnectés du réseau. Vingt-cinq minutes auront suffi pour plonger des milliers de sites et de services dans le chaos.
Dans la nuit du 2 novembre 2026, l'hébergeur russe Beget a subi une cyberattaque d'une violence destructrice.
Il ne s'agissait pas d'une attaque DDoS classique visant à surcharger les serveurs de requêtes, ni d'un ransomware traditionnel chiffrant les fichiers pour extorquer une rançon.
Les attaquants ont pénétré le plan de contrôle (Control Plane) de l'infrastructure avant d'exécuter un logiciel malveillant conçu pour supprimer les données.
Beget a officiellement confirmé ce scénario.
Chronique de vingt-cinq minutes
Selon la chronologie publiée par l'entreprise :
- 02h00 — Début présumé de l'attaque et compromission des serveurs de gestion.
- 02h30 — Lancement du programme de suppression des données.
- 02h40 — Détection de l'accès non autorisé.
- 02h55 — Déconnexion des serveurs du réseau pour endiguer la propagation de l'attaque.
À 03h00, l'enquête et les opérations de restauration ont débuté.
À ce stade, les dégâts étaient déjà considérables.
L'incident a touché l'hébergement mutualisé, les serveurs cloud, les solutions de stockage, ainsi que les infrastructures DNS et de messagerie.
Parmi les services affectés figure le service d'autopartage BelkaCar. Des perturbations d'accès au portail d'information « Chestny Znak » ont également été constatées, bien que le système de traçage lui-même ait continué de fonctionner, selon son opérateur.
Beget dessert plus de 200 000 clients. Selon une étude de marché menée en octobre, environ 14,7 % des domaines en .RU étaient liés à l'entreprise (y compris les domaines de parking et les redirections).
Cela ne signifie pas qu'un site russe sur sept s'est arrêté, mais cela illustre l'ampleur de la dépendance des projets internet envers un unique fournisseur.
Comment détruire un cloud en 25 minutes ?
Imaginez un immense entrepôt doté de milliers de pièces.
Chaque pièce dispose de sa propre porte et de sa propre serrure. Mais il existe quelque part un panneau de contrôle centralisé permettant d'ouvrir, de fermer ou de réaménager l'ensemble du complexe en un instant.
Dans une infrastructure serveur, ce rôle est joué par le Control Plane (le plan de contrôle).
C'est par son intermédiaire que les systèmes automatisés peuvent créer des machines virtuelles, allouer des disques, modifier des paramètres réseau, gérer les stockages et supprimer des ressources.
Si un attaquant obtient des privilèges suffisants, il n'a pas besoin de pirater chaque machine virtuelle une par une.
Il peut agir sur l'infrastructure de manière centralisée.
Par ailleurs, l'anéantissement de volumes massifs de données ne nécessite pas toujours d'écraser physiquement chaque octet.
Selon l'architecture du stockage, il suffit parfois de supprimer des disques virtuels, d'altérer des métadonnées critiques ou de détruire les informations indispensables à l'accès aux données.
Le système ne parvient plus à lire le contenu, quand bien même les supports physiques continuent d'exister.
Il s'agit là d'une explication technique d'un mécanisme possible, et non du mode opératoire officiel des attaquants de Beget. L'entreprise n'a pas encore divulgué les outils spécifiques ni la méthode d'intrusion initiale.
La perte la plus critique : les sauvegardes
Le 3 novembre, Beget a annoncé la perte de données au sein de son infrastructure cloud VPS, S3 et Kubernetes.
Les copies de sauvegarde binaires des VPS ont également été anéanties.
En revanche, les sauvegardes de fichiers ont été préservées, ouvrant la voie à une restauration partielle.
La nuance est fondamentale.
Une copie binaire de serveur virtuel permet de restaurer l'image complète d'une machine. Une copie de fichiers ne contient que des éléments isolés, sans garantir la restitution de l'arborescence des disques, de l'état des services en cours d'exécution ni des configurations requises.
Par conséquent, disposer d'une archive de fichiers ne signifie pas pour autant qu'un serveur peut être remis sur pied en un seul clic.
Le 5 novembre, Beget a indiqué qu'une grande partie des sauvegardes de fichiers VPS avait survécu et que leur restitution aux clients était en préparation.
C'est précisément ici que réside le véritable défi technique.
Si les données de production et le système de sauvegarde dépendent du même plan de contrôle, la compromission de ce dernier peut détruire simultanément l'original et la voie de recours.
Avoir trois copies sur trois disques ne sauvera rien si ces trois copies peuvent être effacées avec les mêmes privilèges administratifs.
Un million de changements de routage : que s'est-il passé sur le réseau ?
L'attaque a révélé un autre symptôme inhabituel.
D'après le journal Kommersant, s'appuyant sur des données RIPEstat, près d'un million de modifications d'annonces de routage ont été observées dans les réseaux de Beget en l'espace d'une heure. À titre de comparatif, le record précédent sur 90 jours n'excédait pas 20 000.
Il s'agit d'une anomalie colossale.
Le protocole BGP permet aux réseaux autonomes d'échanger des informations sur les routes Internet disponibles.
Des variations brusques de routage peuvent accompagner la déconnexion de nœuds réseau, une reconfiguration d'urgence ou des dysfonctionnements de routeurs.
Les attaquants ont-ils pu cibler les équipements réseau ? Théoriquement, oui.
Les ingénieurs ont-ils eux-mêmes provoqué cette flambée de routes en tentant d'isoler l'infrastructure ? Ce scénario est également plausible.
Cependant, les données rendues publiques ne permettent pas encore d'en identifier la cause.
Cette anomalie BGP mérite une étude approfondie ; l'attribuer hâtivement aux agissements des pirates serait prématuré.
Et si la cause venait de la vulnérabilité PHP d'octobre ?
En octobre, nous avions déjà analysé des failles critiques touchant des logiciels serveurs et des passerelles d'IA.
Une question légitime se pose : les attaquants ont-ils emprunté une voie similaire pour s'introduire chez Beget ?
Les points d'entrée potentiels sont multiples : panneaux d'administration, jetons dérobés, services vulnérables, postes de travail de collaborateurs ou systèmes d'accès à distance.
Cependant, Beget n'a pas révélé le vecteur d'attaque initial.
Il est donc impossible, à l'heure actuelle, de lier la destruction de l'infrastructure en novembre à une vulnérabilité PHP spécifique.
Le principal fait avéré est tout autre : les assaillants ont accédé au pilotage de l'infrastructure. Par quel moyen ? Cela reste à déterminer.
Comment protéger son propre serveur contre une telle catastrophe ?
Un petit projet n'a pas nécessairement besoin de trois centres de données et d'un budget pharaonique.
Il requiert une architecture conçue pour empêcher qu'un seul incident ne anéantisse tout.
Premièrement : des sauvegardes indépendantes.
Bases de données, configurations, clés de restauration et fichiers doivent être sauvegardés régulièrement en dehors du périmètre de l'hébergeur principal.
Deuxièmement : la protection anti-suppression.
Pour les archives, il est judésieux d'utiliser des espaces de stockage dotés d'un verrouillage d'objet (Object Lock) et d'un mode immuable. Par exemple, le mode de conformité S3 Object Lock interdit la suppression d'une version protégée jusqu'à l'expiration de la période de rétention définie, y compris par l'administrateur du compte.
Toutefois, cette protection exige un paramétrage rigoureux et ne remplace ni des identifiants distincts ni un contrôle strict des accès.
Troisièmement : une gestion indépendante des DNS.
Si le site web, les e-mails, les DNS et les sauvegardes sont hébergés chez le même prestataire, une panne chez ce dernier peut paralyser l'intégralité du projet.
La possibilité de rediriger rapidement un domaine vers une plateforme de secours doit demeurer accessible indépendamment du serveur principal.
Quatrièmement : une restauration éprouvée.
Une archive que l'on n'a jamais testée n'est qu'un simple espoir.
Il est indispensable de déployer régulièrement un serveur de test à partir d'une sauvegarde pour vérifier que les applications démarrent, que les bases de données s'ouvrent et que les services essentiels fonctionnent.
Cinquièmement : la limitation des privilèges administratifs.
La suppression en masse de l'infrastructure ne doit jamais dépendre d'un unique jeton ou d'un seul compte utilisateur. Les opérations critiques exigent un cloisonnement des pouvoirs, une validation indépendante et un mécanisme de verrouillage d'urgence.
Pourquoi cela concerne-t-il chaque propriétaire de VPN ou de service d'IA ?
Imaginez que vous opériez un serveur VPN comptant des centaines de clients.
Il héberge des configurations, des clés d'accès, des paramètres de routage et des données de facturation.
Une attaque destructrice frappe l'infrastructure du fournisseur, et le serveur disparaît.
Si la sauvegarde se trouve sur ce même serveur, la possibilité de rétablir rapidement l'activité s'envole également.
Pour une passerelle d'IA, la situation est identique : la perte des configurations, des secrets, de la base utilisateurs et de l'historique des paiements peut stopper net l'ensemble du service.
Par conséquent, l'indépendance ne se résume pas au choix d'un autre fournisseur cloud.
La véritable indépendance commence par la capacité à quitter son hébergeur actuel avec ses propres données et à reprendre son activité sans son intervention.
Que s'est-il passé après l'attaque ?
La phase de restauration de Beget s'est étalée sur plusieurs jours.
Au 5 novembre, l'entreprise annonçait le rétablissement de 60 % de son offre d'hébergement mutualisé et de 40 % de ses serveurs dédiés sous administration propre.
Pour les clients des services touchés, les prélèvements et facturations ont été suspendus pendant la durée de l'interruption.
L'entreprise a poursuivi l'audit de ses serveurs et la réhabilitation des sauvegardes.
Il s'agit d'un travail de titan : après la compromission du plan de contrôle, il est impossible de simplement réactiver le matériel sans s'assurer au préalable que le code malveillant et les accès frauduleux ont été totalement éradiqués.
Conclusion
Dans nos précédentes enquêtes au sujet de « Glass Bridge », nous avions analysé les vulnérabilités Linux, les failles des passerelles d'IA et la compromission de mises à jour logicielles officielles.
Beget illustre un degré de menace supérieur.
Parfois, un attaquant n'a pas besoin de cibler un serveur spécifique.
Il lui suffit de s'emparer du système dont dépendent des milliers d'autres machines.
Vingt-cinq minutes suffisent pour anéantir une infrastructure bâtie au fil des ans.
Dès lors, la question primordiale pour tout propriétaire de business numérique ne devrait plus être « mon hébergeur est-il populaire ? ».
Mais bien une interrogation beaucoup plus concrète :
« Pourrai-je restaurer l'intégralité de mon projet demain si cet hébergeur venait à disparaître aujourd'hui ? »
Si la réponse est incertaine, le moment est venu de procéder à un audit. Tant qu'il ne s'agit que d'un exercice de simulation, et non d'une véritable catastrophe.
Glass Bridge | 6 novembre 2026
Sources
- Beget — Chronologie officielle de la cyberattaque et de la restauration : https://beget.ru/ru/security
- Beget Official — Annonces concernant la perte de données cloud et l'intégrité des sauvegardes de fichiers : https://t.me/s/beget_official
- Kommersant, 2 novembre 2026 — Ampleur de la panne et anomalies BGP : https://www.kommersant.ru/doc/9079245
- AWS — Documentation sur S3 Object Lock : https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html