OPFORGE ICS Scenario 01: Silent Tank Overfill (Implementation)

Executive Summary

Objective: Determine whether a defensive system can detect when a valid control-plane action produces an unsafe physical outcome.

Approach: Simulated adversary manipulation of a Modbus register controlling tank fill thresholds within a segmented ICS environment.

Key Insight: Control-plane actions can remain protocol-valid while inducing unsafe process states that evade traditional detection approaches.

Outcome: Identified detection gaps across control-plane visibility, configuration drift, and process-aware monitoring; developed detection opportunities across network, log, and behavioral layers.

Relevance: Demonstrates how adversary emulation can be used to measure defensive effectiveness in cyber-physical systems, not just alert generation.

Capability Demonstrated: Adversary-driven validation of cyber-physical system integrity using control-plane manipulation.

This document provides the technical implementation of the Silent Tank Overfill scenario.

For the conceptual overview and motivation:

• https://alfredopelaez.com/writing/2026-03-22-silent-tank-overfill/

Purpose

The goal of this scenario is to answer a specific question:

Can a defensive system detect when a control-plane change causes a meaningful change in physical process behavior? [1]

This scenario measures impact, not just alerts, aligning with threat-informed defense principles that emphasize measuring detection effectiveness against adversary behavior rather than alert presence alone [1].

More specifically, it tests whether a defensive capability can:

• observe a control-plane change to a critical process value
• recognize that the change produces behavior outside expected operation
• distinguish valid control activity from unsafe outcomes
• support analyst understanding of cause to effect

What This Demonstrates

• Adversary emulation in ICS/OT environments
• Detection engineering across control-plane and process layers
• Mapping cyber actions to physical system impact
• Validation of detection coverage using ATT&CK-aligned techniques
• Design of repeatable, measurable cyber-physical test scenarios

Validation Objectives

This scenario validates:

1. Control-plane visibility Detect writes to critical registers

2. Baseline deviation awareness Identify abnormal configuration changes

3. Process-aware detection Detect violations of expected process behavior

4. Outcome-based assessment Correlate command, state, and physical impact

ATT&CK ICS Mapping

• Technique: Manipulation of Control (T0831)
• Sub-technique: Change Setpoint (T0821)
• Tactic: Impact

This scenario emulates adversary behavior in which control parameters are modified to produce unsafe or unintended physical outcomes while remaining valid at the protocol level.

Architecture Overview

• OpenPLC (opf-plc01) - Modbus TCP interface
• Process Simulator (opf-sim01) - enforces tank physics
• Modbus TCP - control-plane interface
• Attack Scripts - perform register manipulation

The PLC exposes state. The simulator enforces reality.

This separation is intentional. It allows the scenario to distinguish between a control-plane action that appears valid and a physical outcome that is operationally unsafe.

Register and Coil Design

Holding Registers

R0 = tank_level
R1 = low_setpoint
R2 = high_setpoint
R3 = high_high_setpoint

Coils

C0 = inlet_valve
C1 = low_alarm
C2 = low_low_alarm
C3 = high_alarm
C4 = high_high_alarm

R2 is the critical register in this scenario because it directly controls when filling should stop under normal conditions.

Baseline Behavior

Control logic:

• If tank_level <= low_setpoint -> fill
• If tank_level >= high_setpoint -> stop

Operating band:

30 -> 80 -> 30 -> repeat

Alarm thresholds:

• low_alarm at <= 30
• low_low_alarm at <= 10
• high_alarm at >= 80
• high_high_alarm at >= 90

Under baseline conditions:

• alarm ordering is consistent
• system behavior is predictable
• filling stops before the system enters a high-high condition
• the alarm model matches the configured operating envelope

Expected Invariants

Under normal operation:

• high_alarm triggers before high_high_alarm
• high_high_alarm never occurs while high_alarm remains unset
• filling stops at the high setpoint
• thresholds remain within expected bounds

These are process invariants, not network indicators.

Attack Implementation

A single Modbus write modifies the high setpoint:

R2: 80 -> 98

Execution:

python3 attack_set_high_threshold.py

This is a control-plane action, not an exploit. It aligns with known ICS adversary behaviors such as setpoint manipulation (T0821) and control logic modification described (T0831) from MITRE ATT&CK for ICS [2].

Nothing crashes. No memory corruption occurs. No protocol violation is required.

The action is valid at the protocol level.

That is the point.

This scenario tests whether a defensive system can recognize when a valid command produces an invalid operational outcome.

Example Control-Plane Artifact

The following packet captures the exact moment the high setpoint is modified:

• Function Code: Write Single Register (6)
• Target Register: R2 (high_setpoint)
• New Value: 98

This represents a valid Modbus command that produces an unsafe operational outcome.

Detection Opportunities

• Register write to critical parameter
• Value deviation from expected baseline
• Correlation between control change and process anomaly

Post-Attack Behavior

The system enters an invalid state:

high_high_alarm = 1 while high_alarm = 0

Invariant violated: high_high_alarm should never trigger before high_alarm

Observed effects:

• extended fill duration
• delayed high_alarm
• high_high_alarm triggers first
• stop condition no longer aligns with expected operating range

This represents a process integrity failure, not a network anomaly.

At the network layer, the event may appear minor: a single register write.

At the process layer, the effect is significant: the control system continues filling beyond the expected upper operating bound and enters a high-high alarm state before normal high alarm sequencing is satisfied.

That is the signal this scenario is designed to surface.

What Should Be Detected

A capable detection system should identify the following behaviors, consistent with threat-informed detection methodologies used in ATT&CK Evaluations [1]:

• a Modbus write to critical register R2
• deviation from the expected setpoint baseline
• abnormal alarm sequencing
• process behavior outside normal operating bounds
• mismatch between configured stop logic and expected safety envelope

More importantly, it should support an analyst conclusion such as:

A control-plane change altered the tank stop threshold, causing filling to continue long enough to violate expected alarm ordering and enter an unsafe process state.

That is materially different from:

A Modbus write occurred.

Detection Opportunities

This scenario creates several distinct detection opportunities.

1. Control-plane detection

Detect that a write occurred to a sensitive register:

• Modbus write to R2
• write source, timing, and new value captured
• register classified as safety-relevant or operationally critical

2. Configuration drift detection

Detect that the new value deviates from the expected baseline:

• baseline high setpoint is 80
• observed value becomes 98
• deviation exceeds allowed tolerance or approved change window

3. Process anomaly detection

Detect that system behavior now falls outside expected operating logic:

• fill duration exceeds normal range
• high-high state occurs before high state
• stop condition no longer occurs at the expected threshold

4. Correlation and impact assessment

Correlate the control action to the physical effect, representing the impact phase of the ICS Cyber Kill Chain where adversary actions translate into physical consequences [4]:

• register write precedes the process anomaly
• alarm ordering changes only after threshold manipulation
• restoring the default threshold returns expected behavior

Recovery

Restoring the original setpoint returns the system to expected behavior, confirming that the impact was caused by control-plane manipulation rather than simulator instability or random process drift.

Reproducibility

Baseline:

python3 plc_init.py
python3 -u tank_sim.py

Attack:

python3 attack_set_high_threshold.py

Restore:

python3 attack_restore_defaults.py

High-state validation:

INITIAL_TANK_LEVEL=95 python3 -u tank_sim.py

Assessment Criteria

This scenario is most useful when it produces an explicit assessment.

Minimum success condition

The environment records the write to R2.

Better success condition

The environment records the write and identifies the resulting threshold deviation.

Strong success condition

The environment records the write, identifies the threshold deviation, and detects that process behavior now violates expected alarm ordering or safe operating bounds.

Best success condition

The environment supports full analyst reconstruction of:

• what changed
• when it changed
• why it mattered
• what physical effect followed
• what defensive improvement is required

This is the standard that matters.

The objective is not to prove that telemetry exists.

The objective is to prove that the defensive system can translate telemetry into an accurate assessment of process integrity.

Key Insight

The critical signal is not the write. The critical signal is that the system is no longer behaving correctly.

This reflects a shift from network-centric detection toward process-aware monitoring, a gap consistently identified in ICS security guidance and research [3].

That distinction matters.

A network-centric detection model may identify a protocol action. A process-aware validation model identifies whether the action changed the system in a way that matters operationally.

This scenario is built to test the latter.

Next Steps

• integrate telemetry into detection pipelines
• score detection against physical impact
• add automated checks for alarm ordering invariants
• expand to additional scenarios:
  • loss of view
  • actuator manipulation
  • false data injection

Why It Matters

Defensive systems that cannot distinguish between valid control actions and unsafe outcomes risk failing silently in cyber-physical environments.

That is the standard OPFORGE is designed to test. This scenario demonstrates how to measure and close that gap.

References

[1] MITRE Center for Threat-Informed Defense (CTID) - Detection Evaluation Methodology https://ctid.mitre.org/

[2] MITRE ATT&CK® for ICS - Manipulation of Control / Change Setpoint https://attack.mitre.org/matrices/ics/

[3] NIST SP 800-82 - Guide to Industrial Control Systems (ICS) Security https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf

[4] SANS - Industrial Control System Cyber Kill Chain https://www.sans.org/white-papers/36297/