Silent Tank Overfill: When a Single Register Write Changes Physical Reality
A single Modbus register change can silently alter physical system behavior, exposing gaps in how detection programs measure effectiveness.
Most cyber ranges measure alerts.
Very few measure whether those alerts actually matter.
I’ve been building out a small ICS scenario inside OPFORGE to explore a simple question:
What happens when a single unauthorized Modbus write changes how a physical system behaves?
This scenario models a basic tank system:
- Tank level controlled by threshold setpoints
- PLC exposes values over Modbus
- A simulator represents both the process and controller
Registers:
- R0 → tank level
- R1 → low setpoint
- R2 → high setpoint
- R3 → high-high setpoint
Control behavior:
- Inlet valve opens and closes based on thresholds
- Alarm states include low / low-low and high / high-high
The adversary doesn’t deploy malware.
They don’t need persistence.
They do one thing:
Modify a single register: High setpoint from 80 → 98
Nothing appears broken at first.
But the system behavior shifts:
- The tank fills longer than expected
- The high alarm is delayed
- The high-high alarm may trigger before the high alarm
This creates an impossible condition:
A more severe alarm triggers before a less severe one.
That’s not noise.
That’s a process integrity failure.
Most detection programs focus on:
- Did we see the Modbus write?
- Did we log the event?
Those are necessary.
But they are not sufficient.
The real question is:
Did the system behave differently in a way that matters?
Because that is what an adversary is trying to achieve.
This scenario is not about ICS theory.
It is about measuring whether a defensive system can:
- Detect unauthorized control-plane changes
- Correlate those changes to physical impact
- Identify process anomalies, not just network activity
This is the first scenario in a broader validation series:
- Loss of View → sensor manipulation
- Stuck Actuator → loss of control authority
- False Normal → data integrity attack
Each scenario answers the same question:
Does the system remain safe under adversary-driven conditions?
This scenario is part of a larger OPFORGE validation environment.
Artifacts will include:
- Tank simulator implementation
- Modbus interaction scripts
- Attack and restoration tooling
- Detection engineering experiments
A detection that fires is not the goal.
A detection that proves the system is still safe is.