Industrial plants are moving their Supervisory Control and Data Acquisition (SCADA) systems to the cloud. This puts the link between on-site equipment and the SCADA out on the public Internet, albeit VPN-encrypted. ICS-Sniper shows that an on-path attacker can disrupt the plant operations by reading only the shape of that encrypted traffic (i.e., packet sizes, timing, and direction) and dropping a small, precisely chosen set of packets.
ICS-Sniper is the work of researchers at the University of British Columbia. This research was funded in part by the National Cybersecurity Consortium of Canada (NCC), the Natural Sciences and Engineering Research Council of Canada (NSERC), and the Digital Research Alliance of Canada (DRAC).
SCADA is the software that synchronizes the distributed processes in a plant. It used to live on-site, on a private network. Increasingly, water, wastewater, and manufacturing operators run it on cloud platforms instead — utilities across the US, Canada, Australia, and New Zealand are among the early adopters.
No SCADA hardware or local IT staff to run at every remote site.
Operators monitor and control geographically spread-out assets from anywhere.
Cloud providers offer uptime guarantees that on-site systems can't match at low cost.
The trade-off: The plant's some of the most time-sensitive control traffic now crosses the open Internet. To protect it, operators follow the standard NIST recommendations and AWS playbook — authenticate the endpoints, add a firewall and intrusion detection, wrap the traffic in a VPN, and watch for high-volume denial-of-service. This is exactly the architecture ICS-Sniper targets, and it slips past all four safeguards.
The setup in the wild: PLCs on site, SCADA in the cloud, an encrypted VPN across the Internet — and an adversary who only needs a foothold on one router in between.
An on-path adversary can degrade a safety-critical plant by dropping under 5% of its packets — and stay invisible to today's detectors.
A rogue insider at an ISP, or a nation-state with access to a router on the path — the same foothold behind recent Cisco and Juniper router vulnerabilities.
Outside the plant perimeter, on the public Internet leg between the site and its cloud-hosted SCADA.
Watch the encrypted VPN flow, learn its rhythm, then drop the right packets at the right moment to desynchronize the process.
The exposure is new — it only exists once SCADA leaves the plant's private network. And the usual defenses (VPN, firewalls, DoS monitoring) give a false sense of safety against it.
PLCs talk to SCADA in a steady, repeating rhythm. Each state of the process has its own burst pattern, and that pattern shifts the moment the process is about to change state. VPN encryption hides the contents, but it can't hide when packets arrive, how big they are, or which way they're going. ICS-Sniper reconstructs the rhythm from that metadata alone.
Demonstrated on realistic water-treatment plants with cloud-hosted SCADA.
Stalls the plant's core job — producing and pumping purified water on schedule.
Breaks tightly-timed hand-offs between stages, draining water the plant already cleaned.
The process falls behind, forcing extra runtime or missing its output target.
No monitored detector flags the attack until the plant is already degraded.
In a real plant, these disruptions ripple outward — to the communities and downstream facilities depending on the water — and the whole attack needs nothing more than a foothold on one router along the path. As cloud-hosted SCADA becomes the norm, more plants inherit exactly this exposure.
An ensemble of eight state-of-the-art ICS detectors — network-based and process-log-based — was trained and run against the attack. In two of five scenarios no detector alerted during the attack at all; in the rest, alerts only arrived after the plant operations had already been degraded.
A short quiet gap on the link — exactly what a dropped burst looks like — triggers nothing. That design is fine for high-rate floods and blind to a targeted blackhole.
No spoofed ARP, no altered payloads, no extra traffic, no volume spike.
ICS-Sniper drops far fewer packets than a naive blackhole aiming for the same effect — and it leaves liveness-check probes untouched, so the link still looks alive.
Catching this likely means actively polling the link in step with each PLC's rhythm — an unsolved research problem, not a setting on an existing tool.
The attack needs a compromised on-path device to exist — so hardening routers and monitoring the ISP path still matters. Beyond that, the paper points to three directions, none of them fully solved yet.
So a single compromised hop can't blackhole the flow.
Everything is open source across five repositories: the attack, the detector ensemble, and three testbeds. Preprocessed traces and SCADA logs ship with the repos, so you can reproduce the profiling and detection results with no live testbed, no special hardware, and no GPU.
The profiling module (phase folding over traffic metadata to find superperiods and rank critical windows) plus the packet-dropping controller. Needs Python 3.10 and tshark.
The IPAL ensemble used to measure stealth — Kitsune, inter-arrival-time, PASAD, InvariantRules and more — with detection-lag and alert-overlap scoring.
Real Allen-Bradley Micro800 PLCs running connected Modbus/TCP over OpenVPN — the realistic-timing testbed.
Software-simulated PLCs running unconnected Modbus/TCP over OpenVPN for fast prototyping.
Software-simulated PLCs running unconnected ENIP/TCP over OpenVPN.
The full set of encrypted VPN traces captured from our testbeds, shared for convenience.
Open on Google Drive# get everything into one folder git clone https://github.com/ICS-Sniper/ICS-SNIPER-attack.git git clone https://github.com/ICS-Sniper/SOTA-detectors-NDSS.git git clone https://github.com/ICS-Sniper/Modbus-C-hardware-testbed.git git clone https://github.com/ICS-Sniper/Modbus-U-software-testbed.git git clone https://github.com/ICS-Sniper/ENIP-U-software-testbed.git
With the included traces you can run the profiling and detector steps without setting up a live testbed. Each repository's README has the full setup; the software testbeds and live capture are only needed if you want to reproduce end to end.
Short video
