OT Penetration Test on a Drinking Water Network's Supervision System
A drinking water utility wanted to know what an attacker could actually reach on its supervision system. With no interruption to production, no operational downtime.
[ Context ]
The operator provides drinking water production and distribution for a mid-sized urban area and several attached rural municipalities. The network has 12 remotely managed sites: a well field, a treatment plant, four head and distribution reservoirs, and six lift stations. Everything reports to a centralized SCADA system installed at the technical headquarters, backed by an alarm relay to on-call workstations reachable 24 hours a day. The remotely controlled functions directly affect service quality: starting and stopping pumps, managing reservoir levels, regulating chlorination.
The installation was modernized in successive waves over roughly fifteen years. Legacy radio links coexist with 4G routers installed more recently on the most isolated sites, and the integrator who maintains the PLCs has permanent remote access for troubleshooting interventions. The technical department had already commissioned a documentary audit of its architecture, but no offensive test had ever been conducted on the scope. The operator's qualification as an entity subject to NIS2 made this verification necessary, with one clear requirement set from the first conversation: water distribution was never to be put at risk.
The Challenge
The operator wasn't looking for a list of theoretical vulnerabilities. It wanted an answer to a precise question: from outside the technical network, how far can you go, and what can you reach once you're there? Three entry points were suspected but had never been tested: the integrator's remote access, the remote management links to isolated sites, and the on-call workstations used outside the premises. The difficulty lay in the nature of the installation. A typical penetration test allows writes, restarts, flooding. On a live chlorination PLC, none of those actions is acceptable.
The constraint was set before the method: no write commands on production equipment, no availability testing on live PLCs. Anything involving an offensive action had to be demonstrated elsewhere.
Shared VPN account for the integrator's remote access
Radio remote management in the clear, with no frame authentication
On-call workstations connected to the SCADA system from office sessions
Our Approach
No interruption to production, no operational downtime: the assignment was built around this constraint rather than around the offensive scenario. Anything involving a write, a restart, or manipulating a PLC was replayed on a pre-production test bench built with the operator's own hardware and firmware. On the live installation, the team limited itself to progression and observation, during night windows set with the on-call department. The operations teams followed every step.
Written definition of the testable scope, the list of prohibited actions, and the excluded equipment. Designation of an on-call point of contact reachable during every test window, and an immediate-stop procedure the operator can trigger without justification. Validation of the night window schedule based on the reservoir filling slots.
Passive observation of network traffic, no injection into the production network. OT asset inventory: PLCs, HMIs, supervision stations, network equipment, remote access. Survey of the remote management protocols used site by site, identification of firmware versions and exposed services, reconstruction of the actual flows between the SCADA system and the 12 sites.
Assembly of a test bench using a pumping PLC and a chlorination PLC identical to those in the fleet, same firmware versions, same network configuration. Intrusive tests were run exclusively on this bench: register writes, sending command orders, replaying remote management frames, attempting to halt the CPU. Every effect obtained was filmed and documented.
Testing of the three suspected access paths under real operating conditions: the integrator's VPN, the radio link to an isolated reservoir, the on-call workstation connected from outside. Progression up to the supervision network and the PLCs, systematically stopping at read-only. No write commands on production equipment, with the demonstration of impact referred back to the test bench.
Drafting of the report with the attack paths reproduced step by step, the flow diagrams, and the zone and conduit segmentation. Each finding carries its risk level, estimated effort, and identified owner. Remediation plan prioritized across three horizons: immediate, 6 months, 18 months. A validation session with the teams, followed by a decision summary.
[ Results ]
Three complete access paths demonstrated all the way to supervision, including one from an off-site on-call workstation.
Flow mapping of the 12 remotely managed sites: metering and control now kept separate, no more shared path.
Integrator access overhauled: named accounts, second factor, time slots, and logging; on-call workstation separated from the office network.
27 findings prioritized across three horizons; report, diagrams, and configurations remain usable in-house.
We wanted to know what was actually reachable on our supervision system, not receive one more theoretical list. The pre-production test bench removed our main reservation: no commands were sent to live PLCs, and our on-call staff followed every test window. The three demonstrated paths were presented to our management with the remediation effort alongside each one, which let us decide without debating in the abstract.
Discover other industrial cybersecurity missions carried out by Leviotec, in France and internationally
.svg)
.svg)