More water, wastewater and manufacturing operators are moving their supervisory control and data acquisition (SCADA) software, the system that watches and coordinates the plant, out of the control room and into the cloud. The traffic between the programmable logic controllers (PLCs) on site and the cloud SCADA then crosses the public internet inside an encrypted virtual private network (VPN) tunnel. A research team at the University of British Columbia (UBC) has now shown that the tunnel's encryption is not enough on its own to keep that link dependable.
What the researchers found
The paper, "ICS-Sniper: A Targeted Blackhole Attack on Encrypted ICS Traffic," has been accepted for the Network and Distributed System Security (NDSS) Symposium in March 2027, and UBC announced it on 22 October 2026. The team showed that someone who controls a single router somewhere on the internet path between a plant and its cloud SCADA could disrupt the process without breaking the encryption, without getting into the plant network, and without knowing the control logic.
The reason is simple to explain. Encryption hides what is inside each message, but it does not hide when messages are sent, how big they are, or which direction they travel. PLCs talk to SCADA in a steady, repeating rhythm, and that rhythm changes just before the process changes state, for example when a pump is about to start or a valve is about to close. By watching only that pattern, an adversary on the path can guess when an important command is likely, and quietly drop a small number of packets at that moment. The researchers report that dropping under 5 percent of packets was enough in their tests.
The work was done on simulated water treatment testbeds modeled on the Secure Water Treatment (SWaT) research plant, one built with real Allen-Bradley Micro800 PLCs and one fully in software, using Modbus and EtherNet/IP traffic over OpenVPN with SCADA hosted in Amazon Web Services. No live plant or real water was involved. According to UBC, one test delayed the start of clean water pumping by about 15 minutes, and another left a simulated valve open more than nine minutes longer than intended. Eight state-of-the-art detection tools did not raise an alarm in two of the five scenarios, and in the others the alerts came only after the process had already been affected, because these tools are built to notice floods of traffic, not a short silence.
This is academic research, not an attack seen in the wild. There is no vulnerability identifier (CVE) and no product to patch. The researchers point out that the attacker needs a foothold on a router along the path, such as a rogue insider at an internet provider or a nation-state actor that has already compromised network equipment, which is the kind of access recent campaigns against Cisco and Juniper routers have been after.
Where this shows up, from the plant floor to the cloud
On the plant floor, nothing changes: the PLCs, sensors and drives keep doing what they were told. At the site edge, the cellular or broadband router and the VPN gateway carry every message to and from the cloud. Out on the internet, the traffic passes through routers owned by other companies, and that is where this risk lives. In the cloud, the SCADA server sees late or missing updates and may make the wrong call, while the operator sees a link that still looks alive.
What owners and operators should do
1. Map which sites depend on cloud-hosted or remotely hosted SCADA for real-time control, and which ones only send data up for reporting. The first group carries this risk.
2. Make sure each site can run safely on its own if the cloud link goes quiet. Local control logic, interlocks and fail-safe states should not depend on a command arriving from the cloud on time.
3. Give critical sites a second network path, such as a different carrier or a cellular backup, so one compromised router cannot silently cut off important messages.
4. Monitor the link for missed or late updates, not just for outages and traffic spikes, and have operators treat repeated delays as a security question as well as a network question.
We are here to help, so check out our resources online at www.redtigersecurity.com and book a follow-up call with our team if you have any questions: https://calendly.com/jonathanpollet/30min
Source: https://www.cs.ubc.ca/news/2026/10/ubc-researchers-uncover-new-cyber-threat-water-and-energy-networks
Paper: https://arxiv.org/abs/2312.06140
Check out our resources and book a follow-up call with our team.
