Every wire, every airwave

Mis à jour le 4 novembre 2026 : données prolongées au 1er novembre. Le retour d'un bloc de scanners le 27 octobre change le verdict de la phase 3 ; détail en fin d'article.

Du 8 au 11 octobre 2026, des drones ukrainiens ont frappé trois datacenters de Yandex, le premier groupe internet de Russie. Kiev a parlé de riposte, Yandex a publié puis retiré des messages d'incident, et un chiffre devenu viral a été lu comme la fin des robots russes. Aucune de ces sources ne dit ce que la frappe a détruit, ce que Yandex a perdu, ni ce qu'elle a changé à la menace qui pèse sur les serveurs du reste du monde. Ce texte est une évaluation des dommages, un BDA, conduite comme en renseignement : une question, des capteurs, une méthode d'inférence, des degrés de confiance, puis les résultats.

La question

Les armées évaluent une frappe en trois temps, que la doctrine américaine du ciblage nomme les trois phases du battle damage assessment : les dégâts physiques infligés à la cible, la fonction que la cible a perdue, puis l'effet sur le système dont elle faisait partie. L'ensemble se rapporte ensuite à l'effet que l'attaquant recherchait¹. Les frappes d'octobre offrent l'occasion de conduire cette analyse sous l'angle des effets numériques d'une attaque cinétique, car Yandex Cloud était connu de la communauté de cybersécurité comme l'un des réseaux d'où partent les sondes automatisées qui balaient le web : avant les frappes, Cloudflare classait comme automatisées 95 % des requêtes parties de Yandex Cloud, sans qu'aucune vienne d'un robot vérifié, c'est-à-dire reconnu par Cloudflare comme un robot légitime, tel celui d'un moteur de recherche, mais de scripts, de sondes de greffons WordPress et de scanners² ; CrowdSec y comptait près de deux mille adresses signalées en trois mois³. La question de fond est la disruption qu'une frappe cinétique inflige à des services offensifs, et les trois phases la découpent en trois questions. Quelles machines ont cessé de fonctionner, et où. Quels services Yandex a perdus, pour combien de temps, et ce que sa redondance a couvert. Et ce que ces destructions ont changé au système que les serveurs du reste du monde subissent chaque nuit, puisqu'une partie de la menace était hébergée dans ce cloud.

Les sources ordinaires ne répondent pas. Volodymyr Zelensky a confirmé la riposte d'une phrase, « Nous avons riposté », en réponse aux frappes russes sur les datacenters ukrainiens⁴. Yandex a tenu une page de statut pendant les frappes, puis l'a supprimée : le 30 octobre, elle n'affichait plus qu'un bandeau annonçant que ses produits clés étaient rétablis⁵. La presse a montré des incendies. Et le chiffre qui a circulé, la chute brutale des robots venus de Russie, mesurait le robot d'indexation du moteur de recherche². Il manquait un instrument qui ait observé ce cloud avant, pendant et après, de l'extérieur, sans dépendre de Yandex ni de Kiev.

Les capteurs

Cet instrument existe, pour une raison étrangère au conflit. CrowdSec, une société française, distribue un logiciel libre, au code source ouvert, que ses utilisateurs installent sur leurs propres serveurs pour s'en protéger. Posté en bordure du serveur, le logiciel analyse les requêtes web qu'il reçoit, les journaux de la machine, serveur web, SSH, pare-feu, et le comportement des robots, et les confronte à des scénarios de détection : une adresse qui essaie des mots de passe en rafale, qui parcourt des chemins d'administration, qui tente une faille connue sur un composant précis. Quand un scénario se déclenche, le serveur bloque l'adresse et la signale à l'éditeur, avec le scénario et l'heure. Chaque installation forme ainsi un capteur, et le réseau de capteurs est vaste : du 24 septembre au 19 octobre, 104 449 d'entre eux ont émis chaque jour sans interruption, et 9 924 voyaient régulièrement des adresses de Yandex Cloud³. CrowdSec agrège ces signalements, en déduit pour chaque adresse un profil, les scénarios qu'elle déclenche, les capteurs qu'elle touche, sa régularité, et une réputation, sur une échelle qui va de sûre, pour les robots et les scanners légitimes, à malveillante, pour les adresses les plus agressives. La détection est pertinente pour ce bilan parce qu'elle est tenue par les cibles : les scanners hébergés chez Yandex Cloud attaquaient ces serveurs chaque nuit, chaque serveur les notait, et ces serveurs ne dépendent pas de Yandex, à l'exception des 135 hébergés chez Yandex Cloud, que ce bilan suit comme un indicateur à part. Une adresse signalée n'est pas pour autant malveillante : des 1 986 adresses de Yandex Cloud recensées par CrowdSec sur quatre-vingt-dix jours, 51 étaient classées malveillantes, 542 suspectes et 1 391 simplement connues.

Le trafic légitime échappe à ces capteurs, sauf quand il déclenche un scénario sans intention de nuire : le robot d'un moteur de recherche qui parcourt un site, le résolveur DNS dont un serveur refuse les requêtes. La réputation classe ces adresses sûres, et leur régularité donne un pouls. On peut en déterminer quatre indicateurs. Le premier est le silence des 135 capteurs que des clients ordinaires de Yandex Cloud avaient installés sur leurs propres machines et qui émettaient au moins cinq jours sur sept au début d'octobre : un capteur qui se tait date sa machine à la minute. Le deuxième est le robot d'indexation du moteur de recherche, qui tourne sur le réseau propre du groupe, celui de Yandex LLC (AS13238 et AS208398), distinct de celui du cloud (AS200350), et dont les noms de machines portent un code, sas, vla ou klg, qui reprend le nom des villes de Sasovo, Vladimir et Kaluga : le seul indicateur qui nomme le site physique d'un datacenter. Le troisième est l'activité de trois pools de résolveurs DNS du même réseau. Le quatrième est le compte des sources d'attaque hébergées dans le cloud, quelques centaines d'adresses par jour, et le détail de ce qu'elles faisaient.

Deux sources indépendantes recoupent ces capteurs. Cloudflare, qui protège une part importante des sites web, mesure le trafic que ces sites reçoivent des réseaux de Yandex, et a publié son analyse le 14 octobre². RIPEstat, l'outil du registre européen des adresses, conserve l'historique des blocs d'adresses annoncés sur l'internet, qui dit si un réseau a disparu du routage⁶. Les messages de la page de statut de Yandex, lus les 20 et 21 octobre avant leur retrait, donnent la version de l'opérateur⁵. La presse, ukrainienne et russe, fournit les heures d'alerte et les dégâts visibles.

La méthode

Les capteurs ne disent pas dans quel site tourne une adresse de Yandex Cloud. Toute la méthode consiste à inférer des sites à partir d'indicateurs qui ne les nomment pas, et à dire à chaque étape ce qui porte l'inférence.

Premier maillon : dater. Un capteur qui se tait n'est pas forcément une machine détruite ; son propriétaire peut l'éteindre ou le déplacer. Mais le silence simultané de dizaines de capteurs, quand le renouvellement ordinaire reste sous 1 %, est un signal, et l'heure du dernier signalement en borne l'heure d'arrêt. Deuxième maillon : localiser sans nom de site. Chez Yandex Cloud, selon sa documentation, une adresse publique réservée appartient à une zone de disponibilité (availability zone, AZ), l'un des compartiments entre lesquels le cloud répartit les machines de ses clients pour qu'une panne reste confinée, et chaque zone a son propre stock d'adresses⁷. Si les capteurs sont rangés par plages d'adresses, et si chaque plage a un sort unique, les plages dessinent les zones. Le contrôle de cette inférence est indépendant : les sources d'attaque hébergées dans les mêmes plages doivent suivre le même calendrier. Troisième maillon : rattacher les zones aux sites. Yandex a nommé la zone de la première nuit ; pour les autres, seul le calendrier des frappes le permet. Quatrième maillon : mesurer l'effet sur la menace, en restreignant le compte aux adresses régulières, pour écarter le renouvellement naturel d'un cloud qui change la moitié de ses adresses en deux semaines, puis en cherchant une reconstitution ou un transfert de charge ailleurs, par réseau et par cible.

Chaque résultat porte un degré de confiance. Élevée, quand deux indicateurs indépendants concordent. Modérée, quand un seul indicateur le porte, avec une limite connue. Faible, quand il repose sur un capteur unique ou sur une coïncidence de calendrier. Les limites sont connues d'avance. La collecte de CrowdSec a eu, la nuit du 7 au 8, un trou de cause interne, sans lien avec Yandex : à partir de 20 h, une part croissante de l'ensemble des capteurs cesse de transmettre, moins de la moitié remontent encore à 1 h, aucun de 7 h à 10 h³. Les signalements de cette nuit sont donc incomplets, et une heure de dernier signal peut y précéder l'arrêt réel d'une machine : ce sont des bornes basses. Cinq capteurs émettent 84 % des signalements sur les scanners à large spectre de Yandex Cloud, un échantillon trop étroit pour en déterminer la géographie des cibles. Le découpage en plages est celui de l'analyste, Yandex ne publiant pas le sien. Matthieu Mazzolini, responsable de l'équipe data de CrowdSec, a calculé ces chiffres du 20 octobre au 2 novembre ; les heures sont celles de Moscou, et la période de référence va du 24 septembre au 6 octobre.

Chronologie

Le 8 octobre à 1 h 31, Yandex Cloud signale des coupures de courant dans la zone ru-central1-b et recommande de basculer la charge vers les autres zones⁵. Cinq minutes plus tôt, à 1 h 26, un bloc de scanners hébergé dans ce cloud cesse d'apparaître dans les signalements des serveurs qu'il attaquait ; à 1 h 33, un second bloc s'arrête à son tour³. Les deux travaillaient d'ordinaire jusqu'à 6 h. Le robot d'indexation cesse d'apparaître à Sasovo après 1 h 01, un intervalle normal à son rythme : aucun relevé ne date la panne avant l'alerte de l'opérateur. À 15 h 19, Yandex attribue la panne à un incendie consécutif à une attaque de drone sur son datacenter de Sasovo, dans la région de Riazan, qu'il a entièrement arrêté.

Le 9, des drones frappent le datacenter de Kaluga, le plus grand de Yandex en Russie selon Militarnyi, un média ukrainien spécialisé dans les questions militaires⁸, et partiellement hors service selon le quotidien économique russe Kommersant⁹. Les relevés n'y montrent aucune rupture : le robot d'indexation du site apparaît dans cinq des six heures de la matinée, à son rythme habituel.

La nuit du 10 au 11 est la mieux mesurée, la collecte étant complète. De 3 h 30 à 4 h 07, 25 capteurs installés sur des machines de Yandex Cloud cessent d'émettre ; les plus réguliers, qui signalent d'ordinaire à une à trois minutes d'intervalle, se taisent à 3 h 47, 3 h 50 et 3 h 56. L'alerte aux drones tombe sur la région de Vladimir à 3 h 51⁸, et Yandex ouvre un incident à 4 h⁵. Une seconde vague, de 4 h 28 à 4 h 50, éteint six capteurs, dont le plus précis, qui signalait toutes les vingt secondes, à 4 h 47. Un pool de résolveurs DNS de Yandex, ces serveurs qui traduisent pour ses utilisateurs les noms de sites en adresses, se tait à son tour : ses dernières adresses sont vues entre 4 h 56 et 5 h 05³. À 6 h 08, Yandex annonce que l'exploitation du datacenter de Vladimir est entièrement suspendue, que la configuration qui lui reste est instable et que sa plateforme passe en mode d'urgence⁵. Pendant ces quatre nuits, les blocs d'adresses du cloud et du moteur de recherche restent annoncés sur l'internet, à une exception près, un sous-bloc du cloud retiré le 11 au matin et revenu le 22⁶ : le réseau a tenu, et les machines se sont éteintes derrière lui.

Phase 1 : les dégâts physiques

Des 135 capteurs hébergés chez Yandex Cloud, 30 se taisent la nuit de Sasovo et 49 celle de Vladimir : 79, soit 59 %, quand le renouvellement ordinaire des capteurs réguliers reste sous 1 % sur une durée équivalente. Au 1er novembre, aucun des 30 de Sasovo n'est revenu ; cinq des 49 de Vladimir sont revenus du 24 au 27 octobre, après treize à dix-sept jours de silence, tous avec leur adresse, et l'un d'eux s'est de nouveau tu le 27. Un capteur garde son identifiant quand il change d'adresse : quatre des 135 ont ainsi changé d'hébergeur en octobre, aucun des 79 ; seule une réinstallation, qui crée un nouvel identifiant, échapperait à ce contrôle³.

Rangés par blocs de 65 536 adresses, les /16 des ingénieurs réseau, ces capteurs ne se distinguent pas : les trois plus gros blocs, qui en portent 90, mélangent les deux nuits. Le tri apparaît au /19, une plage huit fois plus étroite. Des 25 plages qui comptent au moins deux capteurs, 16 ont un sort uniforme, une fois écartés les capteurs éteints à d'autres dates : six meurent avec Sasovo, six avec Vladimir, quatre survivent. Le bloc 158.160.0.0/16 en donne l'image la plus nette, car ses plages alternent : la première et la troisième s'éteignent avec Sasovo, la deuxième et la quatrième avec Vladimir, et les quatre de la moitié haute tournent encore. Les sources d'attaque hébergées dans ces plages suivent le même calendrier : dans les six plages de la nuit de Sasovo, elles passent de 23 adresses signalées par jour à 5 dès les 9 et 10 octobre, puis à 3 ; dans les six de Vladimir, elles se maintiennent à 30 jusqu'au 10, puis tombent à moins de 2, et ne remontent qu'à 3 la dernière semaine d'octobre ; dans les quatre survivantes, elles passent de 9,5 à 14 la semaine du 19 au 25 octobre, puis reviennent à 10.

Un stock d'adresses propre à chaque zone donne des plages à sort unique, ce qu'on observe ; il donne aussi le moyen de suivre une machine sans savoir où elle se trouve, puisqu'une machine revenue avec la même adresse a été remise en service dans sa zone d'origine. Deux groupes de plages ont donc cessé de fonctionner, à trois jours d'intervalle, et ni l'un ni l'autre n'a repris au 1er novembre, leurs sources d'attaque restant à 3 adresses par jour, contre 23 et 30. Les cinq capteurs revenus avec leur adresse montrent que quelques machines tournent de nouveau dans leur zone, sans que la zone retrouve sa capacité. Kaluga, frappé entre les deux, ne laisse aucune trace dans les relevés.

Verdict de phase : deux zones de disponibilité hors service ; à trois semaines, aucun retour mesurable dans la première, quelques machines remises en service dans la seconde, sans reprise de sa capacité ; une frappe sans effet mesurable. Confiance élevée sur l'extinction des deux groupes de plages, portée par deux indicateurs indépendants, les capteurs et les sources d'attaque ; modérée sur le nombre de zones, le découpage étant celui de l'analyse ; faible sur l'attribution aux sites, qui tient au calendrier, sauf pour Sasovo, que Yandex a nommé.

Phase 2 : les dégâts fonctionnels

Yandex a absorbé la perte de Sasovo en sept heures. À 4 h 55, il prévient que la création de machines, de grappes Kubernetes et de bases de données peut échouer dans les autres zones ; à 8 h 26, la charge a basculé, les autres zones fonctionnent normalement, la création de ressources peut rester limitée ; à 18 h 25, il écarte toute reprise de la zone à court terme. Le 9, il annonce un accord avec trois concurrents, Selectel, K2Cloud et VK Cloud, pour accueillir ses clients en priorité sous un mot de code, CloudBro ; le 10, il passe les quotas de calcul et de disque en gestion manuelle pour le week-end. La perte de Vladimir, trois jours après, n'a pas été absorbée : configuration instable, plateforme en mode d'urgence, quotas supplémentaires suspendus, puis, le 13, la gratuité de tous les services du 8 au 31 octobre pour les clients existants. Le 16 au soir, la plateforme fonctionnait toujours en mode limité⁵. La redondance entre zones suppose des pannes indépendantes ; une campagne de frappes les rend corrélées, et la deuxième est tombée sur un système qui avait déjà consommé sa marge pour absorber la première.

Le moteur de recherche a perdu davantage que le cloud. Son robot d'indexation est à zéro à Sasovo depuis le 8, à Vladimir depuis le 11. À Kaluga, où la frappe du 9 ne l'avait pas interrompu, il s'arrête la nuit de Vladimir, après 3 h 04 et avant 5 h ; les machines du site reparaissent depuis le 12, mais le robot n'y donne plus que 23 signalements par jour jusqu'au 25 octobre, contre 209 auparavant, avant de remonter à 123 du 30 octobre au 1er novembre. Les machines de YandexBot qui ne portent pas de code de site passent de 1 187 signalements par jour à 157 du 12 au 25 octobre, puis à 595 à la fin du mois. Sur l'ensemble du réseau propre du groupe, les adresses signalées baissent de 80 % du 11 au 14 octobre ; à la fin du mois, elles n'ont retrouvé que 42 % de leur niveau, 539 adresses par jour contre 1 293³. Cloudflare mesure au creux du 11 un trafic de ce réseau à 99 % sous son niveau habituel, et une baisse de 44 % de son trafic vers les sites de presse².

Des trois pools de résolveurs DNS du groupe visibles dans les relevés, deux sont éteints, l'un depuis la nuit de Sasovo, l'autre depuis celle de Vladimir ; le troisième met en service 30 % d'adresses de plus ; ses signalements, stables jusqu'au 25 octobre, augmentent de 80 % la dernière semaine du mois, relevés par plus de capteurs³. La panne a gagné les clients. Selon Verstka, un média russe indépendant relayé par Meduza, des tribunaux de commerce de plusieurs régions ont reporté ou interrompu des dizaines d'audiences du 8 au 14 octobre, leur système électronique, Moy Arbitr, subissant ce que son prestataire a appelé une panne massive dans un datacenter de Yandex Cloud ; le 16, dossiers et décisions restaient inaccessibles¹⁰. Le 29 octobre, en publiant un chiffre d'affaires trimestriel de 411 milliards de roubles, en hausse de 12 %, Yandex a retiré ses prévisions pour 2026, invoquant des facteurs externes, apparus après les attaques d'octobre, qui rendent difficile l'évaluation de ses résultats pour le reste de l'année¹¹. Selon Kommersant, le matériel de remplacement peut demander jusqu'à six mois de délai⁹.

Verdict de phase : une zone perdue a été couverte par la redondance, deux ne l'ont pas été ; indexation, résolution DNS et cloud dégradés pendant au moins trois semaines, l'indexation ne reprenant que partiellement à la fin d'octobre, pertes reportées sur les clients et sur les prévisions du groupe. Confiance élevée, portée par trois sources indépendantes, les capteurs, Cloudflare et les messages de l'opérateur ; modérée sur Kaluga, dont l'arrêt n'est daté qu'à deux heures près.

Phase 3 : le système visé

Vu des serveurs attaqués, Yandex Cloud était une source mineure. Avant les frappes, 348 de ses adresses étaient signalées chaque jour, tandis que les réseaux des opérateurs d'accès russes en fournissaient plus de dix-sept mille ; dans le recensement de CrowdSec sur quatre-vingt-dix jours, ses 1 986 adresses pesaient 0,016 % des 12,5 millions d'adresses signalées. Du 11 au 14 octobre, il n'en fournit plus que 87 par jour, 75 % de moins. Or ce chiffre compte des adresses signalées, dont une faible part est malveillante ; et la perte des capteurs hébergés ne l'explique pas, puisque la baisse reste de 74 % avec les seuls capteurs qui ont émis chaque jour. Du 15 au 19, le compte remonte à 132, presque entièrement grâce à un bloc revenu ; le reste du cloud stagne à 33 adresses par jour, contre 256. Le compte atteint 222 la dernière semaine d'octobre, 36 % sous la référence, surtout grâce au retour d'un second bloc, le 27. Hors des quatre blocs suivis à part, les deux d'une même opération de scan et deux blocs à passage hebdomadaire, la masse diffuse des sources reste à 28 adresses par jour contre 120, 77 % de moins, sans remontée depuis la mi-octobre³.

Ce cloud change beaucoup d'adresses : l'été, d'une fenêtre de treize jours à la suivante, la moitié environ des siennes ne revenaient pas. Des 1 081 adresses signalées pendant la période de référence, 776 ne reparaissent pas du 11 au 23 octobre, 72 % contre 53 % d'ordinaire sur une fenêtre égale : les frappes expliquent environ 200 de ces disparitions³. Restreint aux 304 adresses régulières, signalées au moins cinq jours sur dix à la fin de septembre, le compte devient net : 145 s'éteignent du 7 au 11, dont 107 dans un seul bloc, et 120 tournent toujours au 25 octobre. Les 145 correspondaient à des machines installées de longue date, avec cinquante jours d'activité en médiane sur les quatre-vingt-dix précédents, et 113 d'entre elles étaient des scanners à large spectre, qui déclenchaient au moins cinquante scénarios de détection en treize jours. En médiane, chacune en déclenchait 127 ; ensemble, elles tentaient 558 failles référencées, en tête celles de PHPUnit, de Confluence, de F5 BIG-IP, d'ownCloud, de GLPI, de Jira et de ThinkPHP, forçaient des accès SSH et des pages protégées, et sondaient les écrans de connexion de ColdFusion, de GlobalProtect, de Tomcat ou de Kibana. La réputation les rangeait dans le bruit de fond, avec un score médian de 7 sur 10 : des balayages automatiques, sans victime choisie. Celles qui tournent encore ont le même profil : 140 scénarios par adresse en médiane, 479 failles, les mêmes en tête, Log4Shell en plus. À leur dernier signalement, 2 des 145 adresses éteintes étaient classées malveillantes, contre 20 des adresses toujours actives, dont 17 dans un seul bloc revenu après les frappes. La frappe a trié par plage d'adresses, sans distinguer les machines malveillantes des autres. Le bloc qui portait 107 des 145 adresses éteintes, et 106 des 113 scanners, est revenu le 27 octobre ; au 1er novembre, 48 adresses régulières restent éteintes, dont 17 scanners à large spectre³.

Son effet déborde pourtant les machines éteintes, et deux cas le montrent. Le premier est une opération de scan qui tournait sur deux blocs d'adresses, 130.193.60.0/24 et 213.165.192.0/24. Avant les frappes, tout indique une seule opération : les deux blocs visaient les mêmes capteurs, 98 % des couples capteur et scénario touchés par le second l'étaient aussi par le premier, leurs volumes horaires montaient et descendaient ensemble, avec une corrélation de 0,90 sur deux semaines, et tous deux travaillaient de 20 h à 6 h. Après les frappes, leur trajectoire se lit en trois temps. La nuit de Sasovo, ils s'arrêtent à sept minutes d'écart. Les trois nuits suivantes, ils repartent ensemble au ralenti, avec des reprises à la même minute, 22 h 05 les 9 et 10, et un arrêt à la même minute, 23 h 57 le 9. Après la nuit de Vladimir, ils divergent : le second retrouve son niveau à partir de la nuit du 15 au 16, avec 108 de ses 117 anciennes adresses, tandis que le premier bloc se tait près de dix-sept jours. Or une adresse ne quitte pas sa zone : revenu avec les siennes, le second bloc tournait dans une zone qui a survécu aux deux frappes, et il s'est pourtant arrêté la nuit où une autre zone mourait. Le bloc 130.193.60.0/24 revient le 27 octobre à 19 h 35, lui aussi avec ses anciennes adresses, le même capteur principal et les mêmes scénarios en tête, à environ 70 % de son activité d'avant ; les deux blocs travaillent de nouveau ensemble, avec une corrélation horaire de 0,72, désormais de 18 h à 6 h³.

Le second cas est un balayage de masse dans le bloc 62.84.0.0/16 : trois à huit adresses y touchaient chaque jour de 400 à 700 capteurs environ. Les 9 et 10 octobre, après Sasovo, des adresses y tournent toujours, quatre puis trois, mais elles n'atteignent plus que 14 et 24 capteurs ; le bloc s'éteint ensuite avec les plages de Vladimir, encore 72 capteurs touchés le 11, 3 le 12, plus rien ou presque depuis³. Ces machines vivaient dans une zone que Sasovo n'avait pas touchée, et elles ont perdu en une nuit l'essentiel de leur portée. Dans les deux cas, une infrastructure d'attaque hérite des dépendances de zone du cloud qui l'héberge.

Les routines hebdomadaires montrent la précision de ces relevés. Un bloc de 128 adresses passait chaque mercredi soir, entre 20 h et 21 h, depuis le 5 août : dix mercredis de suite, toujours les mêmes adresses. Le 14 octobre, il ne passe pas, alors que les deux capteurs qui le voient tournent ; le 21, il revient, avec les mêmes 128 adresses, entre 20 h 02 et 20 h 10. Un autre, qui passe le samedi entre minuit et deux heures, ne s'est jamais interrompu.

Aucune reconstitution n'apparaît ailleurs. Du 11 au 19 octobre, les autres hébergeurs russes restent à leur niveau : Selectel à 250 adresses signalées par jour contre 230, dans sa fourchette habituelle, Radist à 8 contre 8, Timeweb, Beget, VK et Aeza ensemble à 616 contre 616. Sur les 1 549 couples capteur et scénario que visaient les adresses disparues, aucun autre réseau ne progresse, et sur l'ensemble de la Russie, Yandex excepté, le compte reste dans sa fourchette habituelle³. Cloudflare, qui relie des robots entre eux par l'empreinte de leurs connexions chiffrées, a bien suivi des robots visant un site de jeux d'argent qui ont quitté Yandex Cloud dès le 8 pour Radist et Selectel² ; mais CrowdSec n'a pas cette empreinte, et quelques déménagements de ce genre lui échapperaient. Ce qui avait un opérateur attentif a bougé dès le premier jour ; l'opération installée depuis des semaines a attendu, puis repris sur place avec ses propres adresses ; la masse diffuse ne s'est reconstituée ni ailleurs ni sur place, du moins sous une forme visible. « Kill one, spawn many » avait mesuré, après les saisies d'infrastructure criminelle de cette année, une reconstitution en heures ou en semaines, le démantèlement retirant surtout la visibilité aux défenseurs qui n'y ont pas pris part¹² : l'opération revenue le 27 octobre s'inscrit dans ces délais, la masse diffuse non.

Quant aux cibles de ces scanners, un seul indice tient. Sur un même capteur, en Russie, 86 % des scanners à large spectre de Yandex Cloud qui l'atteignent sondent l'écran d'authentification de 1C-Bitrix, un logiciel de sites web répandu en Russie, contre 0,2 % des scanners des grands clouds mondiaux. C'est le seul signe d'un outillage tourné vers le web russe, qui repose sur un capteur³.

Verdict de phase : la frappe a atteint une source mineure du système d'attaque, triée par l'adresse et non par la menace ; elle a paralysé au passage des opérations qui ne tournaient pas dans les zones détruites ; à trois semaines, elle a retiré durablement la masse diffuse, et seulement suspendu, dix-sept jours, l'opération la mieux installée. Confiance élevée sur l'ampleur, sur le profil des sources éteintes et sur le retour de l'opération ; modérée sur l'absence de reconstitution de la masse diffuse, que la méthode de CrowdSec ne peut pas exclure pour des robots déménagés avec de nouvelles adresses ; faible sur le ciblage du web russe, porté par un capteur.

L'effet recherché

Kiev a présenté ces frappes comme une riposte : depuis la fin de septembre, la Russie frappe des datacenters ukrainiens, ce que son ministère de la Défense appelle une « détox numérique forcée »⁴. L'effet recherché, tel qu'il est dit, est donc la réciprocité, et il est atteint : trois datacenters frappés, deux zones de cloud hors service. Le récit qui a suivi allait plus loin, des fermes à robots russes mises hors ligne. Cloudflare l'a examiné : la chute du trafic automatisé venu de Yandex était d'abord celle de son moteur de recherche, dont 99,5 % des requêtes sont automatisées et 93,6 % des requêtes de robots vérifiées, celles d'un moteur qui indexe le web ; sur les points d'entrée d'un réseau social où l'on publie, répond et like, le trafic de robots d'origine russe a baissé de 5,7 % pendant la semaine des frappes, alors que celui des robots du monde entier montait de 1,1 %².

Bilan

Recommandation

Un BDA se termine par une recommandation. Celle-ci s'adresse au défenseur, puisque ces serveurs mesurent ce qu'il reçoit. Pour un défenseur, la menace du 12 octobre ressemble à celle du 6. Les scanners éteints tiraient des failles connues depuis des années : neuf des dix plus fréquentes figurent au catalogue des failles activement exploitées de la CISA, l'agence fédérale américaine de cybersécurité, qui les y a inscrites entre novembre 2021 et novembre 2024¹³. Ceux qui tournent encore, chez Yandex Cloud ou ailleurs, tirent les mêmes, et seuls le correctif ou l'architecture ferment ces failles.

La seconde recommandation vaut pour tout client d'un cloud. Une zone de disponibilité est un compartiment défini par le fournisseur, et ce que les zones partagent décide de la résilience réelle. Dès la première nuit, Yandex prévenait que la création de ressources pouvait échouer dans les zones intactes ; le 9, il indiquait que des plans de contrôle Kubernetes, le logiciel qui pilote ces grappes de machines, pouvaient être déplacés hors de la zone b⁵ ; et le robot d'indexation de Kaluga, que sa propre frappe n'avait pas interrompu, a cessé avec Vladimir. Trois questions sont à poser à un fournisseur : la distance entre ses zones, ce qu'elles ont en commun, ce qu'il fait quand il en perd deux. Yandex a répondu à la dernière le 11 au matin : recourir à tout autre plan de reprise.

Ce que je ne sais pas

Je ne sais pas où se trouve chaque zone. Yandex a lié la zone ru-central1-b à Sasovo ; pour les autres, je ne dispose que du calendrier des frappes, et je ne connais aucun document de Yandex qui définisse les codes sas, vla et klg.

Je ne sais pas si les premières machines de Vladimir se sont arrêtées avant l'impact. Trois capteurs réguliers se taisent à 3 h 47, 3 h 50 et 3 h 56, l'alerte publique tombe à 3 h 51, et je ne connais aucune heure d'impact ; je n'ai pas non plus de seconde mesure indépendante, à la minute, pour recouper ces heures. J'ignore aussi pourquoi, de 3 h 30 à 4 h, les capteurs hébergés chez Yandex Cloud actifs à chaque minute sont plus nombreux que d'habitude, douze en moyenne contre huit.

Je ne sais pas pourquoi le robot d'indexation de Kaluga s'arrête avec Vladimir, ni pourquoi il remonte à la fin d'octobre : un pilotage centralisé, une sortie réseau commune ou une suspension volontaire en rendraient compte, et les relevés ne les départagent pas. Je ne connais pas non plus le mécanisme qui a arrêté avec Sasovo des scanners qui tournaient ailleurs, ni ce qui a tenu l'un des deux blocs à l'arrêt dix-sept jours. Une dépendance logée dans la zone b, pilotage ou stockage, suffirait ; le message de Yandex sur les plans de contrôle Kubernetes montre qu'une partie des grappes était pilotée depuis cette zone, sans dire lesquelles.

Je ne sais pas si l'infrastructure d'attaque s'est déplacée à l'intérieur de Yandex Cloud. Dans la moitié haute de 158.160.0.0/16, dont les adresses touchent d'ordinaire 6 à 20 capteurs par jour, elles en touchent 115 le 13 octobre, 584 le 14, 158 le 17 et 47 le 24, le comportement d'un balayage de masse apparu après les frappes. Les pics du 13 et du 14 viennent surtout d'un balayage SSH, comme celui de 62.84.0.0/16, ceux du 17 et du 24 d'un balayage web, et tout retombe ensuite³ : deux jours de balayage SSH ailleurs dans le même cloud peuvent être la trace d'une relocalisation, sans que je sache s'il s'agit des mêmes opérateurs.

Je ne sais pas si la zone de Vladimir revient. Du 22 au 30 octobre, les signaux s'accumulent : le sous-bloc retiré du routage le 11 réapparaît le 22, cinq capteurs reviennent du 24 au 27 avec leur adresse, le bloc 130.193.60.0/24 reprend le 27, le robot d'indexation de Kaluga remonte, et Yandex affiche le 30 que ses produits clés sont rétablis⁵. Mais le robot d'indexation de Vladimir, deux pools de résolveurs et 74 des 79 capteurs restent muets, et les sources d'attaque des plages de Vladimir ne dépassent pas 3 adresses par jour, contre 30 : des machines remises en service, sans que la zone soit rétablie, et rien ne relie le sous-bloc à Vladimir hormis la date de son retrait. Je ne sais pas non plus pourquoi 51.250.112.0/20 et 84.201.0.0/16 refusent de se trier, même découpés plus finement, dans quel état sont les supercalculateurs que Kommersant situe à Sasovo et à Vladimir⁹, ni qui opérait ces scanners.

L'archive des autres

Les messages de 1 h 31, de 8 h 26 et de 6 h 08 ne sont plus publics. Il reste les relevés de serveurs ordinaires, installés par leurs propriétaires pour se défendre, qui ont noté chaque nuit qui les attaquait et à quelle heure il s'est tu. Quand un opérateur retire son archive, celle que d'autres ont tenue, pour d'autres raisons, prend sa place. En quatre nuits, la frappe a obtenu ce qu'une saisie obtient rarement : des machines qui, pour l'essentiel, ne reviennent pas. Dès le lendemain, le reste du monde recevait pourtant les mêmes sondes, sur les mêmes failles, depuis les réseaux qui les envoyaient déjà.

En miroir

Rien de ce que ce bilan établit ne vient de Yandex. Tout vient de capteurs indirects, placés hors de son contrôle : des serveurs tiers qui notent leurs agresseurs, un intermédiaire qui mesure le trafic qu'il reçoit, un registre qui garde l'historique du routage, et des sources ouvertes. La démonstration faite ici sur la base de CrowdSec peut l'être à partir de n'importe quelle source de capteurs pertinents, la télémétrie d'un éditeur de sécurité, les journaux d'un hébergeur, les relevés d'un moteur de recherche, et chacune donne à celui qui la tient un niveau d'information que l'organisation observée ne soupçonne pas. « L'IA invisible » décrivait la face consentie de cette exposition, les cent millions d'événements par jour qu'une organisation confie à sa plateforme de détection¹⁴ ; ce bilan en montre la face subie, ce que les capteurs d'autrui et les sources ouvertes disent d'un système sans y avoir accès.

Ce qui se déduit de Yandex se déduit en miroir de tout système. Les heures de travail d'une équipe, le calendrier d'un passage hebdomadaire, la zone où tourne une machine, la dépendance qui lie un service à un autre, la marge de redondance qui reste après une première perte : tout cela se lit de l'extérieur, par ceux qui tiennent les capteurs, directs ou indirects, que ce système touche. Le défenseur qui veut savoir ce que son propre système raconte peut appliquer la grille de ce bilan : inventorier les capteurs qui le voient, demander à ceux qui les tiennent ce qu'ils en déduisent, et raisonner en phases, indicateurs et degrés de confiance. Cette grille est celle d'un état-major, et elle s'applique ici sans forçage parce que le numérique est un champ de bataille, où les frappes et les saisies produisent des effets qui se mesurent avec les mêmes instruments que les attaques. Penser sa défense comme on évalue une frappe, à partir de ce que l'adversaire et ses capteurs voient, est la leçon de ces quatre nuits.

Mise à jour du 4 novembre 2026 : données CrowdSec prolongées jusqu'au 1er novembre (retour de cinq capteurs et du premier bloc de l'opération de scan, reprise partielle du robot d'indexation de Kaluga, part des disparitions d'adresses imputable aux frappes corrigée), précisions après relecture de CrowdSec, figures mises à jour.

Merci à Matthieu Mazzolini, responsable de l'équipe data de CrowdSec, qui a calculé et relu ces chiffres, et à Philippe Humeau, cofondateur et directeur général de CrowdSec, qui a ouvert ces données à l'enquête.

Hors-série, en marge d'une série sur les failles de la cybersécurité occidentale. Article de la série cité ici :

• Article 20 : Kill one, spawn many

Tribune citée : « L'IA invisible : le paradoxe de la cybersécurité moderne » (2 octobre 2025).

Sources

¹ Joint Chiefs of Staff, Joint Publication 3-60, « Joint Targeting », 31 janvier 2013, appendice D, « The Targeting Assessment Process » : le battle damage assessment comporte trois phases, physical damage assessment, functional damage assessment et target system assessment ; avec le munitions effectiveness assessment et la reattack recommendation, il forme le combat assessment. Version de 2018 partiellement déclassifiée en 2021. https://www.justsecurity.org/wp-content/uploads/2015/06/Joint_Chiefs-Joint_Targeting_20130131.pdf ; https://www.esd.whs.mil/Portals/54/Documents/FOID/Reading%20Room/Joint_Staff/21-F-0520_JP_3-60_9-28-2018.pdf

² Marina Elmore et Lai Yi Ohlsen, « Yandex outage: Data shows that instead of going dark, malicious bots went on the move », blog de Cloudflare, 14 octobre 2026 : référence du 1er au 6 octobre, période des frappes du 7 au 13 ; avant les frappes, environ 95 % des requêtes de Yandex Cloud (AS200350) classées automatisées, aucune vérifiée, scripts se déclarant Python, Go ou JavaScript, sondes de greffons WordPress et scanners, 0,01 % des requêtes de robots mondiales ; trafic de l'AS13238 à 99 % sous son niveau habituel au creux du 11 ; 99,5 % de ses requêtes classées automatisées et 93,6 % de ses requêtes de robots vérifiées ; trafic des réseaux de Yandex vers les sites de presse en baisse de 44 % ; trafic de robots de Yandex Cloud en baisse d'environ 40 % ; robots visant un compte de jeux d'argent passés de Yandex Cloud à Radist et à Selectel après le 8 octobre ; trafic de robots d'origine russe vers les points d'entrée d'un réseau social (publier, répondre, liker) en baisse de 5,7 %, quand le trafic de robots du monde entier vers les mêmes points d'entrée progresse de 1,1 % ; le billet examine les affirmations selon lesquelles des fermes à robots et des opérations d'influence russes auraient été mises hors ligne. https://blog.cloudflare.com/yandex-outage/

³ CrowdSec, données calculées pour cet article par Matthieu Mazzolini entre le 20 octobre et le 2 novembre 2026, à partir des signalements de son réseau de capteurs, arrêtées au 1er novembre à 24 h. Conventions : heures de Moscou (UTC+3) ; référence, moyenne du 24 septembre au 6 octobre ; Yandex Cloud, AS200350 ; réseau propre du groupe Yandex, AS13238 et AS208398 ; comptes d'adresses distinctes signalées par jour (IPv4 pour Yandex Cloud ; le robot d'indexation tourne en partie en IPv6) ; capteurs hébergés, ceux dont l'adresse est dans l'AS200350 et qui ont émis au moins cinq jours sur sept du 1er au 7 octobre ; adresses régulières, signalées au moins cinq jours sur dix du 26 septembre au 5 octobre ; capteurs permanents, ceux qui ont émis chaque jour du 24 septembre au 19 octobre ; scanners à large spectre, adresses déclenchant au moins cinquante scénarios en treize jours. Les comptes journaliers de Yandex Cloud (348, 87, 132 et 222 adresses par jour ; masse diffuse, 120 et 28) et les définitions d'adresses régulières, de capteurs permanents et de scanners à large spectre comptent les jours en UTC ; le reste est en heure de Moscou. Trou de collecte du 7 octobre à 20 h au 8 à 10 h, de cause interne. Masse diffuse : adresses de Yandex Cloud hors des blocs 130.193.60.0/24 et 213.165.192.0/24, ceux de l'opération de scan, et des blocs à passage hebdomadaire 185.206.167.0/24 et 194.247.51.0/24. Disparitions d'adresses comparées à fenêtre égale, du 11 au 23 octobre. Capteurs revenus : premier signalement depuis une adresse utilisée avant le silence ; heures de silence de la nuit du 10 au 11 tirées de la liste des 49 capteurs figée au 22 octobre, revenus ou non. Balayages SSH et web : capteurs touchés par type de scénario. Plages de /19 : découpage de l'analyste, groupes figés au 22 octobre. Recensement des adresses signalées sur quatre-vingt-dix jours dans Internet Map, outil de CrowdSec en version de test, mise à jour du 17 juillet au 14 octobre : 12 548 373 adresses IPv4, dont 1 986 de Yandex Cloud (1 391 connues, 542 suspectes, 51 malveillantes, 2 sûres). Première lecture publique de ces données par CrowdSec : vidéo publiée sur YouTube le 16 octobre 2026, reprise le même jour sur LinkedIn par Thibault Koechlin, directeur technique de la société. https://youtube.com/shorts/GJqUkh4Dwcw ; https://www.linkedin.com/posts/thibault-koechlin-3061a226_drones-hit-three-yandex-datacenters-between-ugcPost-7516831850137436160-fCvF/

⁴ Meduza, 8 octobre 2026 [presse] : déclaration de Volodymyr Zelensky aux journalistes, « We hit back », en réponse aux frappes russes sur les datacenters ukrainiens, que le ministère russe de la Défense qualifie de « forced digital detox » ; datacenters d'au moins huit entreprises ukrainiennes endommagés ou détruits depuis la fin septembre. https://meduza.io/en/news/2026/10/08/russia-called-its-strikes-on-ukrainian-data-centers-a-forced-digital-detox-zelensky-says-kyiv-has-answered-by-hitting-a-data-center-belonging-to-russian-tech-giant-yandex

⁵ Yandex Cloud, page de statut, chronologie et pages d'incident lues les 20 et 21 octobre 2026, heures converties en heure de Moscou. Incident « Power failure in the ru-central-b availability zone » (sic, pour la zone ru-central1-b) : messages du 8 octobre à 1 h 31 (coupures de courant, bascule recommandée), 4 h 55 (création de ressources perturbée dans les autres zones), 8 h 26 (bascule terminée), 15 h 19 (incendie consécutif à une attaque de drone sur le datacenter de Sasovo, entièrement arrêté), 18 h 25 (pas de reprise à court terme) ; du 9 à 10 h 38 (accord avec Selectel, K2Cloud et VK Cloud, mot de code « CloudBro ») et 15 h 42 (plans de contrôle Kubernetes transférables hors de la zone b) ; du 10 à 9 h (quotas en gestion manuelle). Incident « Unavailability of Yandex Cloud zones », ouvert le 11 à 4 h : messages du 11 à 6 h 08 (attaque de drone, exploitation du datacenter de Vladimir suspendue, configuration restante « unstable », mode d'urgence) et 11 h 14 (quotas supplémentaires suspendus), du 13 à 12 h 05 (gratuité du 8 au 31 octobre) et du 16 à 20 h 19 (mode limité). Le 30 octobre, la page n'affiche plus que le bandeau « Yandex Cloud has restored the operation of its key products » et un renvoi vers la console. https://status.yandex.cloud/en/timeline ; https://status.yandex.cloud/en/incidents/2136

⁶ RIPEstat, historique de routage de l'AS200350, de l'AS13238 et de l'AS208398 du 1er au 20 octobre 2026, et du préfixe 213.165.200.0/21 du 1er septembre au 30 octobre, consulté le 30 octobre : préfixes annoncés sans interruption du 7 au 12 octobre, à l'exception de 213.165.200.0/21 (AS200350), vu au relevé du 11 octobre à 0 h UTC, absent à celui de 8 h UTC et revenu au relevé du 22 octobre à 8 h UTC, ses adresses restant couvertes par 213.165.192.0/19. Les relevés étant espacés de huit heures, le retrait se situe entre 3 h et 11 h, heure de Moscou. L'outil écarte les routes vues par moins de dix pairs. https://stat.ripe.net/AS200350 ; https://stat.ripe.net/213.165.200.0/21

⁷ Documentation de Yandex Cloud : une adresse publique réservée ne peut pas être transférée dans une autre zone de disponibilité, chaque zone ayant son propre stock d'adresses ; une machine virtuelle ne peut recevoir qu'une adresse de sa zone. La documentation renvoie les cas particuliers vers le support. https://yandex.cloud/en/docs/troubleshooting/vpc/how-to/transferring-ip-to-a-different-zone ; https://yandex.cloud/en/docs/compute/operations/vm-control/vm-attach-public-ip

⁸ Militarnyi, « Drones Hit Third Yandex Data Center in Four Days, Sparking Fire », 11 octobre 2026 [presse] : Sasovo frappé le 8, Kaluga le 9, présenté comme le plus grand datacenter de Yandex en Russie, Vladimir dans la nuit du 10 au 11 ; alerte aux drones dans la région de Vladimir à 3 h 51, défense antiaérienne en action à 4 h 24. https://militarnyi.com/en/news/drones-hit-third-yandex-data-center-in-four-days-sparking-fire/

⁹ Kommersant, « В наших стойках выбыло », 11 octobre 2026, édition du 12 [presse] : datacenter de Kaluga partiellement hors service ; supercalculateurs de Yandex hébergés à Sasovo et à Vladimir ; délais de livraison du matériel de remplacement allant jusqu'à six mois, selon une source de marché citée par le journal. https://www.kommersant.ru/doc/9024163

¹⁰ Meduza, d'après Verstka, 16 octobre 2026 [presse] : audiences reportées ou interrompues du 8 au 14 octobre dans des tribunaux d'arbitrage de plusieurs régions ; le prestataire de Moy Arbitr, PravoTech, fait état d'une panne massive dans un datacenter de Yandex Cloud ; dossiers et décisions encore inaccessibles le 16. https://meduza.io/en/news/2026/10/16/ukrainian-strikes-on-yandex-data-centers-disrupted-russian-court-operations

¹¹ Reuters, Gleb Stolyarov, « Russia's Yandex Q3 revenue up 12%, withdraws 2026 forecast after attacks », 29 octobre 2026 [presse] : chiffre d'affaires du troisième trimestre de 411 milliards de roubles, en hausse de 12 % ; prévisions 2026 retirées, Yandex invoquant des « additional external factors » apparus après les attaques d'octobre ; reprise des prévisions envisagée à partir du trimestre suivant. The Moscow Times, 29 octobre 2026 [presse]. Communiqué de résultats de Yandex à citer en source primaire avant publication. https://uk.finance.yahoo.com/news/russias-yandex-q3-revenue-12-061151281.html ; https://www.themoscowtimes.com/2026/10/29/yandex-suspends-2026-guidance-after-data-centers-come-under-fire-a94120

¹² Voir dans cette série : « Kill one, spawn many » (après les saisies d'infrastructure criminelle de 2026, reconstitution en heures pour les serveurs de commande de Kimwolf, en quelques semaines pour Tycoon 2FA ; perte de visibilité pour les défenseurs qui n'ont pas pris part au démantèlement).

¹³ CISA, Known Exploited Vulnerabilities Catalog, version 2026.10.29 : CVE-2017-9841 (PHPUnit), CVE-2022-26134, CVE-2023-22515 et CVE-2023-22518 (Confluence), CVE-2020-5902 (F5 BIG-IP), CVE-2023-49103 (ownCloud), CVE-2022-35914 (GLPI), CVE-2021-26086 (Jira) et CVE-2018-20062 (ThinkPHP) inscrites entre le 3 novembre 2021 et le 12 novembre 2024 ; CVE-2024-12847 (routeurs Netgear) absente du catalogue. https://www.cisa.gov/known-exploited-vulnerabilities-catalog ; https://github.com/cisagov/kev-data

¹⁴ Franck Rouxel, « L'IA invisible : le paradoxe de la cybersécurité moderne », klaerenn.fr, 2 octobre 2025 : cent millions d'événements par jour transmis par une organisation à sa plateforme de détection, cartographie opérationnelle, vulnérabilités et relations d'affaires externalisées vers des éditeurs qui en agrègent l'intelligence. https://www.klaerenn.fr/lia-invisible-le-paradoxe-de-la-cybersecurite-moderne/