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, lors des UECC 2026 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. L’événement accompagnait notamment la publication du livre blanc « Cybersécurité des systèmes industriels, édition 2026 » du GT Cyber OT d’Hexatrust.

Pour la démonstration, j’avais choisi de reprendre une partie du chemin d’attaque documenté par CERT Polska après les incidents ayant touché le secteur énergétique polonais le 29 décembre 2025. Le choix était intéressant parce qu’on y retrouve plusieurs situations que nous rencontrons régulièrement en audit : des équipements raccordés à plusieurs réseaux, des accès distants, des réseaux privés considérés comme implicitement sûrs, des services d’administration accessibles sur plusieurs interfaces et des chemins de communication qui n’apparaissent pas forcément dans le schéma d’architecture.

Un équipement multi-homed correctement durci peut par exemple sembler peu inquiétant. IP forwarding désactivé, filtrage actif, aucune route entre deux réseaux : sur le papier, il ne route rien. Pourtant, s’il peut recevoir une connexion d’un côté et en ouvrir une autre de l’autre, il peut encore devenir un pivot. C’est précisément ce mécanisme que je voulais montrer.

La simulation permettait aussi de partir d’un incident réel et documenté, puis de suivre le chemin jusqu’à son effet sur un procédé industriel simulé. C’est plus parlant qu’une succession de cases sur une kill chain.

Le chemin d’accès

Deux éléments de contexte sont utiles. Le DSO, Distribution System Operator, est le gestionnaire du réseau de distribution électrique. Il doit pouvoir communiquer avec des équipements répartis sur différents sites, récupérer des informations et, selon les architectures, transmettre certaines commandes nécessaires à l’exploitation.

Pour assurer cette communication, il peut utiliser un private APN, c’est-à-dire un réseau mobile privé fourni par un opérateur télécom. Les équipements disposant d’une carte SIM dédiée rejoignent alors un environnement IP privé au lieu d’être directement exposés à Internet.

Dans le cas analysé par CERT Polska, certains clients de ce réseau pouvaient également communiquer entre eux. Le besoin principal était pourtant de permettre au DSO de joindre les équipements distants. Un site de production n’avait pas nécessairement besoin de communiquer avec un autre site utilisant le même APN. Cette connectivité latérale a néanmoins créé un chemin supplémentaire.

Le chemin reconstitué peut être résumé ainsi :

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

Le rapport complémentaire publié par CERT Polska en août 2026 indique que l’attaque contre la centrale de cogénération a provoqué l’arrêt d’une turbine vapeur et du système de traitement d’eau. Les opérateurs ont pu réagir suffisamment vite pour éviter une interruption de la fourniture de chaleur. CERT Polska indique é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.

Pas de route ne veut pas dire pas de chemin

Le rapport décrit le chemin d’attaque, mais n’explique pas en détail le mécanisme qui rend le pivot possible malgré l’absence de route directe. C’est un point que nous rencontrons régulièrement en audit et que je voulais illustrer pendant la démonstration.

Quand on analyse une architecture réseau, on commence naturellement par regarder le routage : un équipement du réseau A peut-il joindre le réseau B ? Y a-t-il une route ? Un firewall autorise-t-il le flux ? Ces questions sont nécessaires, mais elles ne suffisent pas.

Un équipement disposant de deux interfaces réseau n’a pas besoin de router des paquets entre elles pour permettre à un attaquant de passer d’un réseau à l’autre. Il suffit parfois qu’il puisse terminer une connexion sur une interface et en initier une nouvelle sur l’autre.

Le cas du TCP forwarding SSH

SSH ne sert pas uniquement à obtenir un terminal distant. Il peut également transporter des connexions TCP. Dans un forwarding local classique, une session SSH est établie vers une machine intermédiaire. Un port local est ensuite associé, à travers ce tunnel, à une adresse et à un port accessibles depuis la machine distante.

L’équipement intermédiaire ne route pas nécessairement les paquets entre ses interfaces. Il reçoit la connexion SSH, puis le processus SSH ouvre lui-même une nouvelle connexion TCP vers la cible. C’est différent d’un routage IP classique.

Prenons un équipement avec une interface accessible depuis un réseau A et une seconde interface capable de joindre un automate sur un réseau B. SSH est accessible depuis A, mais l’IP forwarding est désactivé. Une analyse limitée au routage peut conclure que A ne peut pas communiquer avec B. C’est vrai au niveau IP, mais si SSH autorise le TCP forwarding, une machine située dans A peut demander à l’équipement intermédiaire d’ouvrir une connexion vers une cible située dans B.

La communication devient alors :

attaquant → connexion SSH vers le pivot → nouvelle connexion TCP créée par le pivot → équipement OT

Il n’existe toujours aucune route directe entre A et B. Pour l’attaquant, le chemin existe pourtant. C’est toute la différence entre routage et capacité de communication.

Dans la chaîne étudiée, le Teltonika constitue un premier point de rebond vers le private APN. Le WAGO PFC200 constitue ensuite une seconde frontière entre ce réseau et l’environnement industriel. On a donc deux équipements, deux frontières et deux possibilités de pivot.

C’est aussi pour cela qu’il faut distinguer routage, NAT/PAT, proxy, tunnel, forwarding applicatif et accès d’administration. L’absence de routage ne garantit pas l’absence des autres mécanismes.

Lors d’un audit, la question n’est donc pas seulement : « Existe-t-il une route entre A et B ? » Il faut aussi vérifier s’il existe un équipement capable de recevoir une communication dans A puis d’en initier une autre vers B. Ce n’est pas une nuance théorique. C’est un chemin d’attaque différent.

Un équipement multi-homed peut devenir un pivot

Le Teltonika et le WAGO ont une caractéristique importante : ils voient plusieurs réseaux. Cette situation est très courante en environnement industriel. On la retrouve sur des RTU, des gateways protocolaires, des serveurs de maintenance, des stations d’ingénierie, des jump servers, des équipements télécoms ou encore des machines disposant d’une interface séparée pour le management.

Sur un schéma d’architecture, l’équipement appartient souvent à une zone. Techniquement, il peut pourtant en voir deux ou trois. Il faut donc regarder autre chose que sa fonction nominale : interfaces actives, routes, règles locales de firewall, services exposés sur chaque interface, SSH, proxy, forwarding IP ou applicatif, comptes d’administration et réseaux que l’équipement peut lui-même joindre.

Un zoning peut être parfaitement propre sur un HLD (High-Level Design, document d’architecture de haut niveau) tout en laissant exister un chemin inattendu dans les configurations. Un équipement multi-homed doit donc être considéré comme une passerelle potentielle, même s’il n’a jamais été conçu comme un routeur.

Une fois dans l’OT, l’analyse change d’échelle

Après le deuxième pivot, l’attaquant arrive dans un environnement industriel. CERT Polska rapporte notamment des activités de découverte portant sur HTTP, VNC, S7 et Modbus. À ce stade, l’analyse ne consiste plus seulement à identifier des hôtes accessibles ou des services exposés. L’attaquant cherche à comprendre quelles fonctions industrielles sont atteignables et jusqu’où une action cyber peut produire un effet sur le procédé.

Trois référentiels permettent de lire cette chaîne sous des angles différents. L’ICS Cyber Kill Chain (progression de l’attaquant jusqu’à l’action sur le système industriel) décrit le chemin offensif. MITRE ATT&CK for ICS (tactiques et techniques observables dans les environnements industriels) détaille les moyens utilisés à chaque étape. Les modèles CIE/CCE (Cyber-Informed Engineering / Consequence-driven Cyber-Informed Engineering) partent au contraire des conséquences physiques ou opérationnelles recherchées pour remonter vers les fonctions, systèmes et conditions nécessaires pour les provoquer.

Dans ce contexte, une action malveillante ne nécessite pas forcément un malware sophistiqué. Un automate peut exécuter une commande parfaitement valide, sur un protocole légitime, avec une fonction prévue par le constructeur. Ce qui change est l’origine de la commande, le contexte dans lequel elle est utilisée et son effet sur le procédé.

Ce que nous avons reproduit aux UECC

La démonstration présentée aux UECC reprenait cette logique générale sans reproduire chaque détail du rapport CERT Polska. L’objectif était surtout de rendre ce 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 vingt minutes, il fallait simplifier une investigation qui s’est déroulée sur plusieurs mois. Le but n’était pas d’expliquer 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 la kill chain reste représentée 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 le chemin ?

Après la session, une remarque est revenue : nous avions beaucoup montré l’attaque et moins la défense. C’était vrai, mais répondre uniquement par « segmenter », « mettre du MFA » ou « appliquer une défense en profondeur » ne dit pas vraiment comment casser cette chaîne. Il faut reprendre le chemin et regarder à chaque étape quelle capacité était nécessaire à l’attaquant.

Commencer par la fonction et les flux nécessaires

Avant de choisir un firewall ou le filtrage des flux à mettre en place, il faut savoir qui doit communiquer avec qui et surtout pourquoi. Une remontée de télémétrie n’implique pas nécessairement qu’un équipement puisse être administré depuis le même réseau. Une fonction de téléconduite ne nécessite pas non plus qu’un client d’un private APN puisse communiquer librement avec tous les autres clients.

Il faut revenir au besoin industriel : qui initie la communication, vers quoi, avec quel protocole, pour quelle fonction et dans quel sens ? Le private APN n’est pas le problème en lui-même. Le problème apparaît lorsqu’il offre davantage de capacités de communication que ce que la fonction nécessite. Un réseau privé n’est pas pour autant un réseau de confiance.

Traiter les équipements multi-homed comme des passerelles potentielles

Désactiver IP forwarding est une bonne mesure, mais elle ne suffit pas nécessairement. Il faut aussi vérifier ce que les services présents sur l’équipement sont capables de faire.

Sur chaque interface, il faut regarder quels services écoutent, si SSH est nécessaire, si le forwarding SSH est autorisé, si un proxy est actif, si l’équipement peut initier une connexion vers l’autre réseau, s’il existe des outils de prise en main à distance et quelles règles applique le firewall local.

C’est là que le hardening prend son sens. Il ne s’agit pas uniquement de respecter une baseline. Chaque service supprimé ou restreint retire une capacité qui pourrait être utilisée pour construire un chemin. Dans le cas étudié, désactiver une route n’aurait pas nécessairement empêché le pivot si SSH pouvait toujours créer les connexions nécessaires vers l’autre interface.

Séparer les accès d’administration

Une architecture fonctionnelle peut être très bien segmentée et être contournée par une mauvaise architecture d’administration. Un équipement n’a aucune raison d’être administrable depuis chacun des réseaux auxquels il est connecté.

Les accès d’ingénierie et de maintenance doivent donc être analysés séparément des flux fonctionnels. Comptes individuels, origine des connexions, bastions, postes dédiés, authentification forte lorsque le matériel le permet, journalisation et suppression des chemins d’administration inutiles font partie du sujet.

Dans le cas d’un private APN, il faut également vérifier ce que fournit réellement l’opérateur : isolation entre clients, filtrage, groupes fermés, adressage et accès aux interfaces de management.

La cyberdéfense et la stratégie de détection face au risque

Ce cas est également intéressant du point de vue de la détection. Plusieurs étapes peuvent laisser des traces : utilisation inhabituelle de SSH, accès à une interface d’administration depuis un segment inhabituel, communication latérale entre deux clients d’un APN, apparition de scans S7 ou Modbus, changement de configuration d’un équipement frontière ou commandes industrielles inhabituelles.

Aucune de ces observations n’a beaucoup de sens sans connaître l’architecture attendue. Une sonde réseau peut voir un événement, le SIEM peut recevoir un log, mais encore faut-il savoir si ce comportement est normal pour cet équipement, sur cette interface et à ce moment-là.

Tester réellement les use cases SOC

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.

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

Un HLD propre ne garantit pas une architecture réelle propre. Sur le terrain, il faut confronter le schéma aux VLAN, routes, ACL, interfaces, règles locales, services actifs et solutions de maintenance réellement présentes.

C’est particulièrement important pour les équipements placés aux frontières. L’objectif d’un audit OT ne doit pas être uniquement de chercher des écarts à un référentiel. Il faut comprendre les chemins réellement disponibles.

Quand les conditions le permettent, une validation technique contrôlée peut aussi être pertinente. Pas pour « pentester l’usine » par principe, mais simplement pour vérifier qu’un chemin annoncé comme impossible l’est réellement. La présence d’un firewall ne suffit pas à le démontrer. Il peut exister un autre chemin qui ne passe pas par lui.

Conclusion

L’incident polonais ne montre pas qu’un private APN est dangereux par nature. Il ne montre pas non plus qu’il faut bannir SSH ou les équipements multi-homed. Il montre surtout qu’une architecture peut offrir davantage de capacités que celles représentées sur son schéma.

Un équipement peut ne rien router et rester un pivot. Un réseau peut être privé et permettre un déplacement latéral. Un protocole d’administration parfaitement légitime peut créer un chemin entre deux zones qui ne disposent d’aucune route entre elles.

C’est pour cela qu’il faut regarder les capacités réelles des équipements, et pas uniquement leur fonction nominale.

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