Retour technique sur la chaîne d’attaque reproduite aux UECC 2026 à partir de l’incident énergétique polonais de décembre 2025

Le 10 septembre, à l’occasion des UECC organisées par Hexatrust à Station F, j’ai participé à l’atelier « Cybersécurité OT : de la menace à la défense, démonstrations en conditions réelles », animé par Olivier Morel. Hexatrust présentait également à cette occasion son livre blanc « Cybersécurité des systèmes industriels – Édition 2026 », réalisé par le groupe de travail Cyber OT piloté par Olivier Morel. Hexatrust résumait d’ailleurs assez bien l’esprit de la session : attaquer, comprendre, puis défendre.

Pour la démonstration, j’avais choisi de reprendre une partie du chemin d’attaque documenté par CERT Polska après les incidents ayant visé le secteur énergétique polonais le 29 décembre 2025. Le cas était particulièrement intéressant parce qu’il ne reposait pas sur le scénario habituel d’un attaquant entrant directement depuis Internet dans un réseau OT. L’accès à la centrale s’est construit progressivement, en utilisant plusieurs équipements et plusieurs réseaux qui avaient chacun une fonction légitime.

Ce choix permettait aussi de présenter aux participants un cas réel et documenté. Nous entendons souvent, en cyber OT, qu’il existe encore peu de cas complets de compromission publiquement documentés. Et lorsque nous utilisons nos outils de simulation en formation ou en démonstration, une question revient régulièrement : jusqu’où le scénario présenté est-il crédible par rapport à ce qui peut réellement se produire sur une installation industrielle ?

Reprendre un incident récent, documenté et suffisamment détaillé permettait donc de répondre directement à cette question. Cela donnait également un intérêt supplémentaire à la démonstration : ne pas montrer uniquement ce qu’il est techniquement possible de faire dans un environnement de simulation, mais expliquer comment des mécanismes comparables ont réellement été utilisés dans une attaque.

Ce choix avait aussi un autre intérêt. Lors des UECC, plusieurs interventions ont rappelé assez directement que la cybersécurité ne pouvait plus être traitée comme un sujet secondaire ou uniquement réglementaire. Le ton a d’ailleurs changé ces derniers mois : les incidents se multiplient, les capacités offensives progressent et le retard accumulé dans certains environnements industriels devient difficile à ignorer.

Sur ce point, je partage assez largement le constat. Au fil des audits réalisés sur différents sites industriels, j’ai déjà rencontré plusieurs des mécanismes que l’on retrouve dans ce cas : équipements « multi-homed », accès distants insuffisamment maîtrisés, réseaux considérés comme « privés » donc implicitement de confiance, services d’administration exposés sur plusieurs interfaces, chemins de communication qui n’apparaissent pas clairement dans l’architecture théorique.

Cela ne signifie évidemment pas que ces sites étaient sur le point de subir la même attaque. Mais cela montre que les conditions techniques qui rendent ce type de chemin possible ne sont pas théoriques. Elles existent déjà dans des environnements de production réels, parfois depuis longtemps.

C’est aussi pour cela qu’il me semble utile de regarder ce type d’incident sans dramatiser, mais sans le minimiser non plus. L’enjeu n’est pas de prédire la prochaine attaque. Il est de vérifier si nos architectures offriraient aujourd’hui les mêmes possibilités à un attaquant.

Mais avant d’aller plus loin, je voudrais donner deux éléments de contexte utiles permettant de mieux comprendre ce qu’il s’est passé.

Le DSO – Distribution System Operator – est le gestionnaire du réseau de distribution électrique. Il doit notamment pouvoir superviser certains équipements distants, récupérer des mesures et, selon les architectures, envoyer certaines commandes nécessaires à l’exploitation du réseau.

Pour relier ces équipements répartis sur plusieurs sites, il peut s’appuyer sur un private APN, c’est-à-dire un réseau mobile privé fourni par un opérateur télécom. Les équipements équipés de cartes SIM dédiées rejoignent alors un environnement IP privé plutôt que l’Internet public.

Dans le cas étudié, ce réseau privé permettait au DSO de communiquer avec ses équipements distants. Mais certains clients du même APN pouvaient également communiquer entre eux, créant ainsi un chemin transverse entre plusieurs sites industriels.

Le chemin reconstitué par CERT Polska peut être résumé ainsi :

accès VPN → routeur Teltonika → private APN → WAGO PFC200 → réseau OT → SCADA / PLC

Le rapport complémentaire publié en août 2026 indique que l’attaque contre cette centrale de cogénération a provoqué l’arrêt d’une turbine vapeur et du système de traitement d’eau, interrompant temporairement la cogénération. Les opérateurs ont pu réagir suffisamment vite pour éviter une interruption de la fourniture de chaleur aux usagers. CERT Polska précise également qu’à sa connaissance, il s’agissait du premier cas réel documenté dans lequel un private APN avait été utilisé comme vecteur d’accès vers un réseau OT.

Ce cas est intéressant moins par son caractère spectaculaire que par ce qu’il nous oblige à regarder : les chemins réels de communication.

La confiance implicite dans le private APN, une faiblesse majeure

Le private APN utilisé dans cette architecture avait une fonction parfaitement légitime. Il permettait au gestionnaire du réseau de distribution de communiquer avec des équipements distants installés sur différents sites de production.

Ce type de réseau privé opérateur est courant. Il permet à des équipements munis de cartes SIM spécifiques de rejoindre un environnement IP privé sans être directement exposés à Internet. Dans un contexte industriel, cela peut être une manière propre de transporter de la télémétrie, des commandes ou des flux de téléconduite entre des sites géographiquement dispersés.

Dans l’architecture analysée, le service private APN permettait également à certains équipements clients de communiquer entre eux. Cette possibilité ne répondait pas au besoin fonctionnel principal du réseau, qui était de relier les équipements distants au système du DSO. Elle résultait plutôt d’un cloisonnement insuffisant entre les différents clients du service.

Un site de production n’avait en effet pas besoin, pour assurer cette fonction, de pouvoir communiquer arbitrairement avec un autre site. Cette connectivité latérale a pourtant fourni à l’attaquant un nouveau chemin de déplacement. CERT Polska recommande à ce titre d’isoler les clients les uns des autres au sein de ce type de réseau privé.

Pas de route ne veut pas dire pas de chemin

C’est probablement l’enseignement le plus intéressant de ce cas.

Lorsqu’on analyse une architecture réseau, il est tentant de regarder les tables de routage et de conclure rapidement qu’un équipement d’un réseau A ne peut pas joindre un équipement d’un réseau B parce qu’aucune route directe n’existe entre les deux. Mais ce raisonnement est insuffisant.

Un équipement disposant de plusieurs interfaces réseau peut terminer une connexion d’un côté et en initier une nouvelle de l’autre. Il n’a pas besoin d’agir comme un routeur IP pour devenir un pivot.

C’est exactement ce que permettent des fonctions de proxy, de port forwarding ou de TCP forwarding SSH.

Dans le cas analysé, le Teltonika a pu servir de premier point de rebond vers le private APN. Le WAGO PFC200 a ensuite joué un rôle comparable entre ce réseau privé et l’environnement OT de la centrale. Deux frontières distinctes, deux équipements capables de joindre les deux côtés, deux pivots.

D’un point de vue réseau, il faut donc distinguer plusieurs mécanismes que l’on mélange encore trop souvent : routage, NAT/PAT, proxy, tunnel, forwarding applicatif et accès d’administration.

Le premier peut être absent alors que les suivants permettent malgré tout de construire un chemin. Lors de nos audits, nous ne cherchons donc pas seulement à répondre à la question :

« Existe-t-il une route entre A et B ? » mais : « Existe-t-il un équipement capable de terminer une communication dans A et d’en initier une autre vers B ? »

La différence peut paraître subtile. Elle ne l’est pas. C’est pourtant un point que nous devons régulièrement expliquer en audit. L’absence de route directe donne souvent un fort sentiment de sécurité, au point que certains constats peuvent être perçus comme excessifs. Mais si un équipement intermédiaire peut relayer, proxifier ou réémettre une communication, le chemin existe malgré tout, même sans routage classique de bout en bout.

Les équipements frontières sont souvent plus importants qu’ils n’en ont l’air

Le Teltonika puis le WAGO ne sont pas simplement des équipements intermédiaires, ils voient plusieurs mondes.

Le routeur cellulaire se trouve entre le réseau local du premier site et le private APN. Le WAGO dispose lui aussi d’une connectivité cellulaire vers ce réseau, mais également de communications vers le SCADA et des équipements industriels de la centrale.

Ces équipements deviennent de fait des points de translation entre plusieurs zones de confiance.

On retrouve la même problématique avec beaucoup d’équipements OT : RTU, gateways protocolaires, serveurs de maintenance, jump servers, stations d’ingénierie ou équipements disposant d’une interface de management séparée.

Ils peuvent être classés dans une zone précise sur un schéma tout en étant techniquement capables d’en relier plusieurs.

C’est pour cela qu’une analyse d’architecture OT doit s’intéresser non seulement à la fonction nominale d’un équipement, mais également à ses capacités : interfaces actives, services disponibles, routage, forwarding, règles locales de firewall, comptes d’administration et réseaux qu’il est capable de joindre.

Le zoning reste indispensable. Mais un zoning qui ignore les capacités des équipements frontières peut donner une impression de cloisonnement très éloignée de la réalité.

Phase 2 de l’attaque, l’OT

Après le deuxième pivot, l’attaquant arrive dans un environnement où la nature des recherches change.

CERT Polska observe notamment des activités de découverte visant HTTP, VNC, S7 et Modbus. On ne cherche plus seulement des systèmes accessibles ; on commence à identifier des équipements et des protocoles industriels.

Le but n’est plus seulement d’atteindre un réseau OT, mais d’acquérir une capacité d’action sur le procédé.

Pour cela, l’attaquant cherche à comprendre ce qui s’y trouve, à identifier les équipements qui présentent un intérêt, à connaître leurs fonctions, les protocoles qu’ils utilisent et les commandes capables de modifier leur comportement.

C’est là que se situe la différence entre compromettre une infrastructure informatique et acquérir une capacité d’action sur un procédé.

Un automate peut d’ailleurs exécuter parfaitement une commande qui lui est adressée. D’un point de vue protocolaire, rien n’est nécessairement anormal. Le caractère malveillant vient de l’intention, de l’origine ou du contexte de l’action.

Cette distinction change également la manière de détecter une attaque OT. Chercher uniquement une signature malware ou un paquet malformé est insuffisant lorsque l’adversaire utilise des fonctions légitimes du système.

Ce que nous avons reproduit aux UECC

La démonstration présentée aux UECC reprenait cette logique générale sans prétendre reproduire chaque détail du rapport CERT Polska.

L’objectif était surtout de rendre le chemin visible.

Nous avons rejoué une séquence guidée : découverte du premier environnement, accès au routeur, création de tunnels SSH, traversée du réseau intermédiaire, second pivot, reconnaissance industrielle puis action sur le PLC avec un effet immédiatement visible sur l’IHM du procédé simulé.

En une vingtaine de minutes, il fallait évidemment simplifier une investigation qui s’est déroulée sur plusieurs mois. Mais le but n’était pas de raconter chaque commande utilisée par l’attaquant. Il était de montrer physiquement ce qu’un schéma d’attaque décrit parfois trop abstraitement : une succession de décisions techniques, chacune rendue possible par une capacité de l’architecture.

C’est aussi ce qui rend ce type de simulation intéressant en sensibilisation OT. Tant que l’on montre une kill chain sous forme de cases et de flèches, le raisonnement reste facilement théorique. Dès qu’un équipement devient effectivement un pivot, que le tunnel apparaît puis que le PLC change d’état, la relation entre architecture réseau et conséquence industrielle devient beaucoup plus concrète.

Comment casser cette chaîne ?

Le retour que nous avons eu après la session était simple : nous avions beaucoup parlé de l’attaque et moins de la défense.

C’est vrai. Mais répondre à cette question uniquement par « segmenter », « mettre du MFA » et « déployer une défense en profondeur » serait un peu court.

Le cas polonais montre justement que la défense doit être pensée au même niveau de détail que le chemin d’attaque.

Il n’existe évidemment pas une mesure unique qui aurait suffi à bloquer toute cette chaîne.

En pratique, la sécurité d’un système industriel se construit sur plusieurs étapes : comprendre les risques et les fonctions critiques, traduire ces besoins dans l’architecture, configurer et durcir les systèmes, organiser les accès, mettre en place les capacités de détection et, enfin, vérifier que les mesures prévues sont réellement appliquées et efficaces.

C’est ainsi que nous abordons généralement les projets chez Adamante Cyber, qu’il s’agisse d’accompagner un projet EPC dès sa conception ou d’auditer une installation existante. L’analyse de risque donne la direction ; l’architecture et les configurations matérialisent les mesures ; les audits et les essais permettent ensuite de vérifier ce qui existe réellement sur le terrain.

Commencer par la fonction et les flux nécessaires

La première mesure de sécurité intervient avant même de choisir un firewall. Il faut commencer par déterminer quelles fonctions ont réellement besoin de communiquer, dans quel sens et pour quelles opérations.

Une remontée de télémétrie n’implique pas nécessairement que l’équipement distant puisse être administré depuis le même réseau. Une téléconduite ne justifie pas non plus qu’un client du private APN puisse dialoguer avec n’importe quel autre client.

Le bon raisonnement est donc fonctionnel.

Qui doit initier la communication ? Vers quel équipement ? Avec quel protocole ? Pour quelle fonction industrielle ? Et avec quelle conséquence si cette capacité est détournée ?

Lorsque cela est possible, on peut également privilégier des architectures qui limitent naturellement les directions de communication : publication de données, collecte initiée depuis une zone maîtrisée, relais applicatifs ou dispositifs unidirectionnels sur certains flux.

Mais il faut rester pragmatique. Dans une architecture DSO, certaines commandes doivent effectivement descendre vers le site. On ne peut pas transformer artificiellement toutes les communications en flux sortants.

La bonne question reste : quelle capacité est indispensable à la fonction, et quelle capacité ne l’est pas ?

Concevoir les frontières avant de les sécuriser

Une architecture cyber OT solide commence par la définition des zones, des niveaux de confiance et des points de passage nécessaires.

Les interfaces avec les DSO, OEM, mainteneurs, opérateurs télécoms ou systèmes de supervision externes doivent être considérées dès la conception comme de véritables frontières de sécurité.

Cela permet ensuite de décider où doivent se trouver les passerelles, quels équipements peuvent disposer de plusieurs interfaces, quels flux doivent passer obligatoirement par un point de contrôle et quels flux d’administration doivent utiliser une architecture séparée.

Nos retours d’expérience sur des architectures de centrale montrent d’ailleurs que le zoning doit suivre les fonctions, les niveaux de confiance et les conséquences, pas uniquement la topologie physique.

Une fois le système installé, corriger une mauvaise frontière devient souvent beaucoup plus compliqué.

Traiter les équipements multi-homed comme des points sensibles

Un équipement disposant de plusieurs interfaces réseau doit être analysé comme une passerelle potentielle, même s’il n’a jamais été conçu comme tel.

Il faut donc examiner son comportement sur chaque interface : services d’administration exposés, règles locales de firewall, routage, forwarding IP ou applicatif, proxy, comptes, protocoles disponibles et capacité à initier des connexions.

Dans le cas étudié, désactiver une route n’aurait pas nécessairement suffi si le service SSH restait capable d’effectuer du TCP forwarding.

Ce type de vérification doit être explicite dans les revues d’architecture et dans les audits de configuration.

Le hardening doit réduire des capacités concrètes

Supprimer un compte par défaut, désactiver une interface Web inutile, restreindre SSH ou couper un service non utilisé ne doit pas être considéré uniquement comme une conformité à une baseline.

Chaque mesure retire une capacité exploitable. C’est une manière beaucoup plus utile de prioriser le durcissement qui, en OT, peut être long et délicat à mettre en place sans impacter les opérations. Comme les autres mesures de sécurité, il gagne surtout à être relié au risque et aux chemins que l’on cherche à réduire.

Lors d’un audit, vérifier plusieurs centaines de paramètres est parfois nécessaire, mais cela ne doit pas empêcher de traiter en premier ce qui ouvre réellement des chemins importants : segmentation, routage, filtrage, accès distants, comptes privilégiés, protocoles hérités et services de prise en main à distance.

Séparer l’architecture fonctionnelle de l’architecture d’administration

Une architecture fonctionnelle très bien segmentée peut être contournée en quelques minutes par une mauvaise architecture d’administration.

Les accès opérateur, les accès d’ingénierie et les accès de maintenance doivent donc être traités séparément.

Cela signifie notamment : comptes individuels, privilèges adaptés, authentification forte lorsqu’elle est techniquement supportée, postes ou bastions d’administration dédiés, journalisation des accès, origine des connexions maîtrisée et suppression des chemins d’administration inutiles.

Une station d’ingénierie ou un routeur n’a aucune raison d’être administrable depuis chacun des réseaux auxquels il est fonctionnellement connecté.

Dans un private APN, cela signifie aussi vérifier avec l’opérateur les mécanismes disponibles : isolation inter-clients, filtrage, adressage, groupes fermés, règles d’accès aux interfaces de management.

« Réseau privé » n’est pas synonyme de « réseau de confiance ».

La cyberdéfense doit regarder les changements de capacité

Le cas est également intéressant du point de vue de la détection. Un antivirus n’aurait pas nécessairement vu le problème.

En revanche, plusieurs comportements étaient potentiellement significatifs : activation d’un service SSH sur une interface qui ne l’utilisait pas auparavant, accès à une interface d’administration depuis un segment inhabituel, scan S7 ou Modbus sur un réseau de téléconduite, communication latérale nouvelle entre deux clients d’un APN ou modification de configuration d’un équipement frontière.

La cyberdéfense OT prend tout son sens lorsqu’elle connaît le comportement attendu de l’architecture.

Les sondes réseau passives, les logs des équipements, les événements de configuration et les informations remontées vers un SIEM peuvent alors être corrélés autour de scénarios précis issus de l’analyse de risque.

Mais définir des use cases de détection sur le papier ne suffit pas. Il faut aussi vérifier qu’ils fonctionnent lorsque les comportements attendus apparaissent réellement sur le réseau.

C’est l’un des usages de MimetICS, notre environnement de simulation OT. La plateforme permet de reproduire des architectures et des comportements industriels, puis de générer des scénarios connus : apparition d’un nouvel équipement, scan de protocoles industriels, modification de commandes Modbus ou S7, changement de configuration, perte de disponibilité ou mouvement entre plusieurs zones.

Sur un projet mené avec un opérateur industriel, nous avons ainsi connecté l’environnement de simulation à son SOC afin de tester les use cases de détection avec de vrais événements issus d’un environnement OT simulé. L’objectif n’était pas seulement de vérifier qu’une sonde générait une alerte, mais de tester toute la chaîne : visibilité du trafic, remontée des événements, corrélation, qualification du cas d’usage et capacité du SOC à comprendre ce qui se passait côté procédé.

Cette étape est importante. Une règle SIEM peut être correctement écrite et ne jamais recevoir l’information dont elle a besoin. Une sonde peut détecter un changement sans que celui-ci soit correctement contextualisé. À l’inverse, certains événements purement techniques prennent beaucoup de sens lorsqu’on connaît la fonction industrielle concernée.

Tester la cyberdéfense revient donc, là encore, à confronter le modèle à la réalité.

Auditer les chemins réels, pas seulement les schémas

Un HLD propre ne garantit pas une architecture réelle propre.

Il faut confronter les documents aux configurations, aux équipements présents, aux routes, VLAN, ACL, interfaces multiples, services actifs et solutions de maintenance réellement utilisées.

Les observations terrain et les collectes passives sont particulièrement utiles pour reconstruire cette architecture réelle. Dans nos audits OT, nous rapprochons généralement plusieurs sources : documentation d’architecture, configurations réseau et sécurité, inventaires, observations sur site et, lorsque cela est pertinent, analyse passive des communications.

L’objectif n’est pas uniquement de rechercher des écarts à un référentiel. Il est d’abord de comprendre les chemins réellement disponibles et de vérifier que les mécanismes de sécurité prévus jouent effectivement leur rôle.

Lorsque les conditions le permettent, une validation technique contrôlée peut également avoir du sens.

Pas pour « pentester l’usine » par principe, mais pour vérifier qu’un chemin déclaré impossible est effectivement impossible.

La présence d’un firewall n’est jamais une preuve suffisante. La vraie question reste : existe-t-il un autre chemin qui ne passe pas par lui ?

Et pendant la conception ?

Toutes ces mesures peuvent être appliquées à une installation existante. Mais le meilleur moment pour corriger un chemin d’attaque reste celui où il n’existe pas encore.

Lorsqu’on intervient dès la conception, les questions cyber peuvent être posées comme de véritables questions d’ingénierie : quelles fonctions doivent communiquer, quels systèmes doivent être séparés, quelles interfaces sont nécessaires, où placer les points de passage, comment administrer les équipements et comment superviser les changements futurs.

La cybersécurité ne devient plus une couche ajoutée après le design : elle participe au design.

Chez Adamante Cyber, nous intervenons aussi dans ce cadre, aussi bien sur des projets neufs que sur des environnements brownfield. Dans ce type de projet, les contraintes cyber doivent être intégrées sans perdre de vue les contraintes industrielles, les interfaces existantes, les dépendances fournisseurs et les impératifs d’exploitation.

Nous formalisons généralement cette démarche dans un plan de cybersécurité projet. L’analyse de risque alimente les choix d’architecture ; les zones et conduits définissent les frontières ; les flux, les accès d’administration, le durcissement, la journalisation et les exigences de continuité sont ensuite traduits dans les spécifications et suivis pendant l’intégration.

Mais ce document n’a d’intérêt que si les exigences se retrouvent ensuite dans les configurations, les documents fournisseurs et les essais. Les FAT, SAT et phases de mise en service sont donc aussi des moments de validation cyber : on vérifie que les mesures prévues ont réellement été livrées et qu’elles restent compatibles avec le fonctionnement industriel.

Sur une installation existante, l’audit sert à identifier les écarts et les chemins inattendus. Sur un projet neuf, les revues et essais permettent d’éviter qu’ils arrivent en production.

Intervenir suffisamment tôt permet surtout de traiter ces sujets au moment où l’architecture peut encore évoluer facilement. Une fois l’installation en service, les mêmes corrections restent possibles, mais elles deviennent souvent plus complexes, plus coûteuses et plus contraintes par l’exploitation.

Cela demande aussi de faire travailler ensemble plusieurs acteurs qui voient chacun une partie de l’architecture : exploitant, automaticien, intégrateur, OEM, fournisseur télécom, DSO, IT, RSSI.

Un attaquant ne respecte pas ces frontières organisationnelles. Il suit le chemin qui fonctionne.

Conclusion

L’incident polonais ne démontre pas qu’un private APN serait dangereux par nature, pas plus qu’il ne démontre que SSH ou les équipements multi-homés devraient être bannis des architectures industrielles.

Il montre quelque chose de beaucoup plus utile.

Une attaque se construit à partir des capacités réellement disponibles dans le système, y compris celles qui n’avaient pas été prévues pour cet usage.

La défense doit donc raisonner de la même façon : comprendre les conséquences que l’on veut éviter, concevoir les flux nécessaires, supprimer les capacités inutiles, maîtriser les équipements frontières, durcir les fonctions d’administration, détecter les changements significatifs et vérifier que l’architecture réelle correspond toujours à celle que l’on croit avoir conçue.

Un schéma d’architecture précis reste indispensable.

Mais il ne raconte jamais toute l’histoire.

Vincent Seruch
Président – Adamante Cyber

Sources principales

• CERT Polska, Energy Sector Incident Report – 29 December 2025, publié le 30 janvier 2026. Rapport initial concernant les attaques coordonnées contre les fermes renouvelables, une entreprise industrielle et une grande centrale de cogénération.
  Rapport initial CERT Polska – PDF
• CERT Polska, Follow-Up Report of the December 2025 Energy Sector Incident, publié le 8 août 2026. Rapport complémentaire.
  Rapport complémentaire CERT Polska