Attacking and Defending an EtherNet/IP Water-Treatment Controller

The environment under test

The plant is a small conventional water-treatment works, from intake through coagulation and filtration to chlorination and distribution. It runs on one CompactLogix-class programmable logic controller. CompactLogix is Allen-Bradley and Rockwell Automation's controller line, a familiar sight in water and wastewater plants, so the target stays representative rather than exotic. It scans remote I/O racks in each treatment area.

The protocol is EtherNet/IP carrying CIP, the native protocol of the Rockwell ecosystem. Explicit request-and-response messaging runs on port 44818, and cyclic I/O runs on UDP 2222. The controller exposes its data as numbered byte blocks called assemblies. Assembly 100 carries the true sensor readings and assembly 150 the writable setpoints and actuator commands. Assembly 154 is the HMI data table the operator's screen reads.

Methodology, and why the evidence holds up

The demonstration runs on a real controller. A real EtherNet/IP controller serves the protocol on loopback. A physics simulation models the plant, so a real write to a setpoint moves a real physical variable such as chlorine residual or distribution pressure, with realistic time lags. A driver performs the attack over the actual protocol, every packet is captured, and a converter turns the capture into the replay. A ship gate publishes only a genuine capture.

Every number in the live demo is a reading logged from that running lab under a real captured session. During development, the first capture recorded a run where the controller turned the writes away. That recording was set aside, because the demo carries only attacks that land.

Attack 1, deceive by false data injection

Status: fully captured and live in the demonstration.

Three unauthenticated CIP SetAttributeSingle writes, in sequence. The first drives the chlorine dose setpoint (assembly 150) to roughly 15 mg/L, and the dosing pump obeys, so the true residual climbs toward a toxic level. The second is the load-bearing move: the residual analyzer reading (assembly 154) is forced to a safe-looking value and held there, so the operator's screen keeps showing a calm number while reality diverges. In the captured run the truth reached 11.14 mg/L while the screen read 1.02. The third stops the high-lift pump, and distribution pressure collapses from 380 to 54 kPa, which fires a global alarm.

The lesson for a defender lands in one line. The alarms that fire are the ones the attacker left alone, and the reading he froze is the very one that certifies the water safe to drink.

Real-world anchor. This reproduces the mechanism of the Oldsmar, Florida incident of February 2021, with the differences stated up front. Oldsmar's real chemical was sodium hydroxide rather than chlorine. Its attribution was later disputed and may trace to operator error. And this study adds one move Oldsmar lacked, freezing the sensor, which is the Stuxnet false-data pattern.

MITRE ATT&CK for ICS: Remote System Discovery (T0846), Unauthorized Command Message (T0855), Modify Parameter (T0836), Spoof Reporting Message (T0856), Manipulation of View (T0832).

Attack 2, seize by ransomware lockout

Status: mechanism verified against the controller. Documented profile.

A ransomware operator goes past breaking the process. It holds the process hostage and strips the owner's ability to recover. Against this controller that is two moves. The first is mass process corruption: a burst of writes drives every setpoint to an unsafe value at once, chlorine maxed and pumps stopped, then freezes the HMI so the operator screen still reads normal. The second is operator lockout by connection exhaustion: the controller accepts a fixed number of explicit CIP connections, verified in its configuration as six. The attacker opens and holds every slot, so when the operator's HMI or an engineer's laptop reaches for the controller to reverse the damage, the controller has no slot left to give it.

The plant sits in an unsafe state its own operators can no longer reach, sometimes with a ransom note written into a spare data-table region. The finite connection pool is the key fact. A resource an operator rarely considers becomes the lockout mechanism.

Real-world anchor. LogicLocker (Georgia Tech, 2017) was a proof-of-concept ransomware for PLCs that locked the controller and held its I/O hostage. EKANS and Snake (2020) was real-world ransomware with ICS-process awareness. This is the same idea expressed in CIP: seize the process, then hold recovery out of reach.

MITRE ATT&CK for ICS: Unauthorized Command Message (T0855), Denial of Control (T0813), Loss of Control (T0827), Loss of Availability (T0826).

Attack 3, destroy by denial of service

Status: one vulnerability path verified against the controller, plus a class-level risk on the same surface. Documented profile.

Path A, unauthenticated device reset. The CIP Identity object implements a Reset service, with reset types for a power-cycle and a factory reset. On this controller the service answers any host that can register a session, and session registration is open. That host can command the device to reset. On production hardware the reset reboots or factory-defaults the controller, dropping the entire plant's control and I/O from a single unauthenticated packet.

Path B, memory safety in the stack itself. The same unauthenticated surface that carries the reset service is parsed by native code, and a parser defect there is a remotely triggerable denial of service with nothing in the way. Stacks of this class are a standing target of the practice's fuzzing, and any result goes to the maintainer first. The takeaway is that the surface carries memory-safety risk as well as the reset.

MITRE ATT&CK for ICS: Device Restart/Shutdown (T0816), Denial of Service (T0814), Loss of Availability (T0826), Loss of Protection (T0837).

The common root cause, and the remediation roadmap

All three attacks share one enabler, and a small set of controls closes all three.

1. Control who can reach the controller. Segment the network on the Purdue model into IEC 62443 zones and conduits. The control zone that holds the PLC answers only a defined engineering zone, over a single defined conduit, and stays closed to everything else. Most of these attacks stall at the first step once the rogue host has no route to port 44818.

2. Authenticate the protocol. CIP Security adds authentication and integrity to CIP. It is the direct fix for a protocol that trusts anyone who can reach it, and it closes all three attack paths at the source.

3. Trust more than one channel for a safety number. Independent instrumentation and a display-versus-truth comparator make a false-data injection visible.

4. Monitor both the wire and the physics. Network detections flag unauthorized writes, unexpected sessions, connection-pool saturation, and reset commands. Process detections flag values that leave their safe band or that contradict an independent truth. Together they buy the minutes a human needs to reverse an attack, which is exactly what happened at Oldsmar.

5. Plan to recover. Tested offline backups and out-of-band controller access, backed by a written runbook, turn a hostage or bricked controller into a routine recovery.

These map cleanly onto IEC 62443, its zones and conduits, its seven foundational requirements and a target security level.

Scope and limits

What this demonstrates

One protocol carries three distinct classes of attack, each reproduced against a realistic controller and each traced back to the same unauthenticated trust model, with a control that closes it. The engineering worth here is the path itself. A captured packet becomes a named technique, and the named technique becomes a specific, standards-mapped fix.