New Research: Attackers Can Disrupt a Plant Without Breaking Its Encryption

On November 3, 2026, researchers at the University of British Columbia published an attack they call ICS-Sniper. It disrupts an industrial process without decrypting a single packet, without touching anything inside the plant, and without setting off the detectors the security team already runs.

The paper, ICS-Sniper: A Targeted Blackhole Attack on Encrypted ICS Traffic, has been accepted at the Network and Distributed System Security Symposium 2027. The work is by Gargi Mitra, Aastha Mehta and Karthik Pattabiraman, with Chanyuan Liu, Pritam Dash, Yingao Elaine Yao and Alain Zhiyanov. No exploitation in the wild has been reported. What makes it worth reading is not the exploit, it is the assumption it breaks: that encrypting the link between a site and its control center protects what travels over that link. This post covers what the researchers did, why the detectors stayed silent, and what changes when that link runs over a carrier network you do not own.

How the Attack Works

The attacker in this paper never gets inside the plant. The threat model gives it covert, persistent control of one or more ISP or provider edge routers sitting on the path between the site gateway and a cloud hosted SCADA system. From there it can see VPN headers, packet lengths and timing. It cannot decrypt payloads, inject traffic, or compromise any device on the plant network.

That is a much weaker position than most OT threat models assume an attacker needs. And it is enough.

Industrial traffic is periodic. PLCs poll on fixed cycles, so the encrypted stream carries a rhythm even when the contents are sealed. The researchers use phase folding across inter packet intervals and packet lengths to recover what they call the superperiod, the least common multiple of the PLC communication periods. Once they have that, they can predict the short windows where state changing commands are likely, and drop packets only inside those windows.

Nothing is read. The attack works on shape and timing.

What the Researchers Found

The evaluation ran on two versions of a water treatment testbed at the Singapore University of Technology and Design, one with software simulated PLCs and one with real Allen-Bradley Micro800 hardware. Traffic ran Modbus/TCP and EtherNet/IP over OpenVPN.

The numbers from the paper:

1. Superperiod identification was accurate in every configuration tested. Across seven configurations the attack identified the superperiod correctly 100% of the time, and ranked the most critical one first in 71% of cases.
2. A process delay attack held up clean water pumping by about 30 minutes. It did so by dropping roughly 4.7% of total packets over a 14 minute window.
3. A depletion attack left a backwash valve open 9 minutes and 11 seconds longer than intended. That run dropped about 4.1% of packets.
4. On real PLC hardware, one minute of dropped packets was enough to matter. About 2.5% of packets caused a two minute delay that cost three extra minutes of operation to recover.

Dropping under 5% of traffic is not a denial of service. It looks like a bad link.

Why None of the Detectors Fired

This is the part worth bringing to your next OT security review. The researchers tested eight detectors, both network based and process log based, plus the IPAL ensemble. None of them alerted while the attack was active.

The reason is structural. Network detectors are event driven. They are built to fire on something appearing: a new connection, an unexpected protocol, a scan. ICS-Sniper does not add anything. It removes a small number of packets from a stream that is already encrypted and already expected. The absence of a command inside a normal looking flow is not an event, so nothing fires until the attack stops.

A monitoring stack tuned to notice what shows up will not notice what went missing.

Why This Matters on a Carrier APN

The paper puts its attacker on a generic internet path and does not discuss cellular at all. That connection is my read, not a finding of the research, and it is the reason this paper should land differently for a utility than for an enterprise IT team.

For a utility, the path between a remote site and the control center is frequently a carrier APN over a public mobile network. A recloser, an RTU or a line sensor sits behind a cellular router at a substation, and its traffic crosses infrastructure the utility does not own, operate or monitor. That is the exact position the paper’s threat model describes, and it is the one part of the path where a utility’s own tooling ends.

Most teams have already made peace with this by encrypting the link. The reasoning is sound as far as it goes, and it is also what the compliance regime asks for. NERC’s Critical Infrastructure Protection Roadmap, published January 2026, notes that CIP-012 “provides confidentiality and integrity protection only for control-center-to-control-center communications.” Confidentiality and integrity are the named objectives. Availability of a specific command at a specific moment is not, and the same roadmap warns that residual risk often comes “from limited visibility into where outdated or vulnerable technologies remain in use.”

Encryption was the right control for the threat it was chosen to address. It was never a control for traffic analysis.

What Detection Looks Like

If the attack produces no new events, detection has to come from somewhere other than event matching. Three places are worth checking in your own environment:

1. Look for devices that go silent rather than devices that act up. A field device that stops reporting on its normal cycle, while the link stays up and the SIM stays attached, is the signal here. Most alerting is tuned for the opposite case.
2. Baseline each device against its own rhythm, not against a site average. The attack depends on periodicity being predictable from outside. The defender can use the same periodicity, and has the advantage of knowing the device type and its expected cycle.
3. Correlate the cellular layer with the application layer. A gap in SCADA polling that lines up with no change at all in the SIM’s session state tells you the problem is on the path, not on the device. Reading those two views separately, in two different consoles, is what makes this hard to spot.

The researchers propose traffic shaping and redundant network paths as mitigations, and are direct that shaping without hurting performance is still an open problem. Neither is a quick change for a utility with thousands of sites already in the field.

Actions to Take Now

1. List which of your remote sites reach the control center over a carrier network. Separate them from the sites on your own private network. Only the first group sits in this threat model, and most teams do not have that split written down anywhere.
2. Ask whether your monitoring can tell you that a device stopped talking. Not that a link went down, which you would see. That a specific device’s expected traffic is missing while everything around it looks normal.
3. Record the expected polling cycle for each device type you operate. You cannot detect a gap in a rhythm you have never measured. This is also the inventory work that wide area private cellular visibility depends on.
4. Check that one team can see both the cellular session and the OT application traffic. Where those two views live with two different teams, the correlation that catches this never happens.
5. Add the WAN path to your incident response playbook. If a process runs late and the devices all look healthy, the current playbook probably has no next step. Decide now who investigates the path.
6. Stop treating an encrypted link as a monitored link. Encryption tells you nobody read the contents. It tells you nothing about what was delayed or dropped.

The Real Lesson

The security of a remote site is not only a question of who can get into it. It is also a question of who sits between it and the people operating it, and what they can work out from watching.

That is a visibility problem before it is a cryptography problem, and it is the same gap we wrote about after the Poland grid attack: operators did not lose power, they lost the ability to see and control what was happening. Closing it starts with knowing every cellular connected device you operate, which network each one is on, and what normal looks like for each one, so a missing command reads as an alert instead of a slow afternoon. OneLayer builds that inventory across private cores and carrier networks and applies identity and policy per device, which is also why SIM based identity on its own is not enough once devices sit behind routers in the field.

See how OneLayer builds a live inventory of every cellular connected device across carriers and private cores, including the OT devices sitting behind a field router.