La partie la plus dangereuse de l’attaque s’est produite des mois avant que quiconque ne s’en rende compte

Le 29 décembre 2025, alors que la Pologne était déjà en proie à des tempêtes de neige et à des températures négatives juste avant le Nouvel An, une cyberattaque coordonnée a frappé plus de 30 parcs éoliens et solaires ainsi qu’une centrale thermique et électrique fournissant du chauffage à près d’un demi-million de personnes. Le Premier ministre Donald Tusk l’a ensuite qualifié d’acte de sabotage russe avec un objectif clair : provoquer une panne de courant en plein hiver. 

Au moment où l’attaque a commencé, le groupe derrière elle était silencieusement à l’intérieur de l’usine de la CHP depuis des mois. 

Ce détail, documenté dans l’analyse technique publiée par CERT Polska en janvier 2026, est la partie de cette histoire qui mérite le plus d’attention. La phase destructrice du 29 décembre n’était pas un coup de force opportuniste. Ce fut l’aboutissement d’une infiltration patiente soutenue durant laquelle les attaquants ont collecté des données opérationnelles, augmenté les privilèges et cartographié minutieusement les systèmes de la centrale pour savoir exactement où frapper. Lorsqu’ils ont finalement déclenché le logiciel malveillant essuie-glace, le logiciel n’a pas été conçu pour extorquer mais pour anéantir définitivement les données, corrompre le firmware et bloquer les dispositifs industriels ; Il a été bloqué à la dernière minute par le logiciel de détection de terminaison. Dans les sous-stations d’énergie renouvelable à travers la Pologne, il n’y avait pas de défense de dernière minute. Les contrôleurs RTU, les relais de protection et les ordinateurs HMI ont été mis hors ligne un par un ; Le firmware a été corrompu, les fichiers système supprimés, et les opérateurs à travers le pays ont perdu la visibilité et le contrôle à distance des installations qu’ils géraient sans interruption pendant des années. L’électricité continuait de se produire, mais la capacité de surveiller, d’ajuster ou de réagir depuis l’extérieur de la clôture avait disparu. 

CERT Polska a attribué les attaques aux clusters Static Tundra, Berserk Bear et Ghost Blizzard, qu’il a évalués comme liés au FSB russe. Dragos et ESET, dans des analyses distinctes, ont attribué cette activité avec une confiance modérée à Sandworm, le groupe lié au GRU responsable des attaques contre les infrastructures électriques ukrainiennes depuis 2015. L’attribution exacte importe moins que la réalité technique qu’elle met en avant : un acteur sophistiqué, bien doté de ressources, avec une connaissance démontrée des systèmes de contrôle industriel, des mois d’accès sans perturbation aux infrastructures critiques, et la capacité de provoquer des conséquences physiques à grande échelle. 

La CISA a émis une alerte mondiale en février 2026, amplifiant le rapport CERT Polska. Le point d’entrée sur chaque site concerné était constant : des dispositifs VPN FortiGate connectés à Internet configurés sans authentification multi-facteurs et des identifiants réutilisés sur plus de 30 emplacements. Les assaillants n’avaient pas besoin de faire quoi que ce soit de particulièrement malin une fois à l’intérieur. L’architecture en place, commune à de nombreux environnements OT distribués, créait une ouverture qui pouvait être exploitée avec peu de sophistication. 

Le problème d’accès qui revient sans cesse 

L’indice X-Force Threat Intelligence d’IBM 2026 indique la fabrication comme l’industrie la plus attaquée au monde pour la cinquième année consécutive, représentant 27,7 % de toutes les cyberattaques. Le coût moyen d’une violation dans le secteur industriel a augmenté de 18 % en glissement annuel en 2024 pour atteindre 5,56 millions de dollars, selon le rapport Cost of a Data Breach d’IBM 2024. Le temps moyen pour identifier une violation dans un environnement d’OT est de 199 jours. En Pologne, les assaillants sont restés présents bien plus longtemps avant d’être détectés. 

Dans les incidents d’heures supplémentaires, le schéma dans la manière dont les attaquants obtiennent et maintiennent l’accès est cohérent. Ils entrent par une infrastructure de connectivité à distance, généralement via des voies d’accès par des fournisseurs ou des tiers établies pour des raisons opérationnelles légitimes mais sans les contrôles nécessaires pour les rendre auditables ou contenues. Ils se déplacent latéralement sur des semaines ou des mois, en travaillant à travers l’escalade des privilèges et la réutilisation de titres. Dans des environnements où les réseaux informatiques et OT ne sont pas correctement segmentés, ce mouvement finit par atteindre la technologie opérationnelle. Les dégâts, lorsqu’ils surviennent, dépendent non seulement de la sophistication de l’attaquant, mais aussi du degré de liberté de mouvement que l’environnement leur a involontairement accordé. 

Y remédier ne nécessite pas une refonte de sécurité longue et perturbatrice dont les opérateurs OT s’inquiètent légitimement. Rien de tout cela n’est simple à mettre en œuvre dans des environnements où la disponibilité est non négociable, où les actifs ont des décennies d’existence et où les équipes de sécurité travaillent souvent avec des ressources limitées. Les contrôles qui auraient changé l’issue en Pologne sont spécifiques et bien compris. Chaque session à distance vers un environnement OT devrait nécessiter une approbation explicite de l’équipe OT avant son ouverture, et chaque action dans cette session devrait être enregistrée dans un enregistrement inviolable. La réutilisation des diplômes entre sites est courante dans les environnements d’OT distribuée, en partie parce que la rotation systématique à grande échelle, sans perturber les opérations continues, est réellement difficile, mais c’est aussi la condition la plus exploitable pour la portée latérale, et l’accès centralisé aux identifiants est la manière la plus directe de réduire cette exposition. La frontière IT/OT doit être appliquée au niveau du réseau plutôt que supposée, de sorte qu’un compte d’entreprise compromis ne puisse pas accéder à l’infrastructure opérationnelle sans franchir un point de contrôle surveillé. Et lorsqu’un problème survient, l’organisation doit pouvoir mettre fin simultanément à tous les accès externes, suspendre les comptes individuels et maintenir la production interne en marche. En même temps, la menace est isolée, ne devant pas avoir à choisir entre confinement et continuité. 

Rien de tout cela n’est théorique. La centrale polonaise de la CHP disposait d’une protection de fin d’arrivée qui arrêtait l’essuie-glace au dernier moment. Si l’organisation avait également eu une visibilité sur des mois de déplacements latéraux via ses comptes privilégiés, l’attaque n’aurait pas atteint ce stade. L’architecture de gestion des accès qui sous-tend ce type de visibilité est la même que celle que NIS2 exige désormais pour les entités essentielles en Europe : contrôles d’accès documentés, authentification multi-facteurs, gouvernance de la chaîne d’approvisionnement et processus testés de gestion des incidents, les instances dirigeantes étant personnellement responsables des échecs et amendes pouvant atteindre 10 millions d’euros, soit 2 % du chiffre d’affaires annuel mondial. 

Construire la résilience avant d’en avoir besoin 

Il existe une tendance dans la sécurité en OT à considérer la résilience comme un élément à considérer uniquement après l’échec de la prévention. L’incident de la Pologne constitue un argument solide contre ce cadrage. Les assaillants étaient à l’intérieur bien avant la phase destructrice. La prévention, au sens de les empêcher totalement d’entrer, avait déjà échoué au moment où quelqu’un savait qu’il y avait un problème. Ce qui déterminait le résultat, c’était de savoir si l’organisation disposait des contrôles nécessaires pour détecter les mouvements latéraux, limiter les dégâts et se rétablir rapidement ; Sur ce point, la situation était mitigée. L’essuie-glace était coincé ; les sous-stations renouvelables ne l’étaient pas. 

Les organisations qui prennent au sérieux l’affaire polonaise se poseront deux questions. Premièrement, ont-ils une véritable visibilité sur qui détient un accès privilégié à leur environnement OT, ce que ces comptes peuvent atteindre, et si un accès de ces accès est actuellement anormal ? Deuxièmement, si quelque chose était déjà dans le réseau aujourd’hui, quels contrôles existent pour le détecter, le contenir et répondre sans mettre hors service les systèmes dont dépend l’entreprise ? 

L’assaillant en Pologne a opéré sans être détecté pendant des mois. La question pratique qui s’ensuit n’est pas de savoir si quelque chose de similaire pourrait se produire ailleurs. C’est de savoir si les contrôles existent pour que cela ait moins d’importance quand c’est le cas.