12 Attack Scenarios: Records and Retest

12.4.1.1 Administration-Compromise Worksheet

The progression has eight review transitions. At each one, ask what control should stop it, what observable would reveal it, and which owner receives the alert.

Figure 12.1 lays the eight transitions out as two phases and pairs each stage with the observable a defender would see and the gate that should answer, then restates the worksheet’s six review fields beneath the chain.

Notice where Figure 12.1 changes colour: the handoff from 4 · Initial exploitation to 5 · Management expansion is the moment a single-host incident becomes a fleet risk, which is why its gate reads least-privilege zones rather than yet another detection control. The review card’s CASCADE RISK — High entry says the same thing in worksheet language; the numbered walkthrough below expands each transition in turn.

1. Infrastructure reconnaissance: unusual discovery traffic or inventory queries test whether network exposure and monitoring reveal the management surface.
2. Device identification and selection: asset inventory, service banners, and management metadata can make a high-value device distinguishable; minimize unnecessary disclosure and alert on broad enumeration.
3. Vulnerability discovery: patch state, configuration weakness, or exposed administrative functions become the hypothesized entry condition; the evidence is a current vulnerability and hardening record.
4. Initial exploitation: the boundary fails and unauthorized execution or privileged access appears; application control, exploit protection, and authentication logs should expose the transition.
5. Network or management-plane expansion: the foothold reaches credentials, peers, or control services; segmentation and per-device authority should limit the blast radius.
6. Persistence: an unauthorized service, account, scheduled action, or equivalent backdoor survives restart; secure configuration baselines and integrity monitoring should detect it.
7. Software or firmware control: the attacker attempts to make the state durable through an update path; signed artifacts, anti-rollback policy, approval separation, and installation logs must reject or reveal it.
8. Remote control and collection: commands, device data, or fleet actions are now available to the unauthorized operator; containment revokes credentials, isolates affected nodes, preserves evidence, and restores a known-good image.

Do not collapse the worksheet into “enable logging.” A log that stays on the compromised administration host may be erased with the host. The evidence path needs independent collection, synchronized time, protected retention, and a tested alert that crosses the same trust boundary the scenario is reviewing.

A sensor-value manipulation review should focus on the accepted data path. For an industrial robot or actuator system, the condition is that calibration parameters, thresholds, or sensor values can be changed or accepted in a way that drives wrong decisions. The review should request configuration-control records, tamper-detection evidence, data input validation, output filtering, safety-aware design limits, behavior monitoring, and training or operating procedures for the people who maintain those values.

Before carrying Critical Scenario Review Records into implementation, check the visual evidence for this claim: “An eight-step attack flow for calibration-value manipulation on an industrial robot, from sensor calibration through attacker tampering to erratic robot motion” is explicit in the diagram. That is the reason Figure 12.2 appears at this point in the narrative.

Figure 12.2 first identifies 1. Sensing equipment, then distinguishes wrong values accepted, before reaching or unexpectedly. This is not a generic flow: the three labels show “An eight-step attack flow for calibration-value manipulation on an industrial robot, from sensor calibration through attacker tampering to erratic robot motion” is explicit in the diagram. That sequence connects Critical Scenario Review Records to evidence a reviewer can name and retest.

A botnet or privileged command-injection review should focus on exposed management paths, weak or default credentials, debug modes, and whether a compromised device can reach command-and-control infrastructure or recruit peers. Evidence should cover closed or justified ports, unique credentials, disabled insecure defaults, least-privilege command permissions, signed software, constrained outbound traffic, monitoring for unusual device behavior, isolation, and recovery. The point is to show whether the system can prevent, detect, contain, and recover from the condition before it cascades.

12.4.1.2 Defensive Botnet Propagation Chain

The sequence below is deliberately written from the defender’s side. It preserves the state transitions needed for containment without supplying commands or payloads.

Before the full table, Figure 12.3 draws the recruitment spine: seven device states falling from an exposed management service to a botnet under command, with the tell-tale observable on the left of every arrow and the control that breaks the transition on the right.

The colour ramp of Figure 12.3 is the containment argument: the amber states — Internet-exposed service, Credentials under attack — are cheap to break with removed exposure and unique credentials, while everything below Privilege gained demands progressively heavier controls, ending at egress caps + DDoS protection once a fleet is already obeying someone else. Each row of the table below matches one arrow in the figure, so use the table for evidence wording and the figure for the order.

Containment speed changes the outcome. If the mean detection-and-isolation delay is longer than the recruitment interval, infected population can grow before each response cycle completes. Measure both times during an exercise, then test whether unique-credential coverage, segmentation, and egress policy keep one compromised device from becoming a fleet event.

A grid-connected metering or control-system review should treat financial-motivated and time-synchronization conditions as distinct from generic sensor-value manipulation. A time-synchronization attack targets the timestamp a measurement unit attaches to a reading rather than the reading itself, so a plausible value can still drive a wrong control decision if the time reference is manipulated. A closed-loop replay condition is a further variant: an attacker who has learned normal sensor outputs can repeat them while injecting a different real value, so the observable telemetry stays plausible while the true system state becomes unobservable to operators. Physical conditions on generators, substations, transmission equipment, or meters, including tampering for energy theft, sit alongside the digital path and warrant the same asset-and-boundary discipline as a compromised gateway. Evidence should cover time-source integrity and cross-checks, price- or measurement-source authentication, detection for a valid-looking but repeated data stream, and physical tamper evidence on field equipment, alongside the general availability evidence described above.

Worked Scenario Review

A gateway receives device telemetry, forwards selected commands, and can install signed configuration bundles. The condition under review: telemetry from an enrolled device can influence a service decision, but the review has not shown rejected-message evidence for malformed or out-of-scope messages.

Practitioner Knowledge Check

If you can build a scenario record and match a fitting mitigation, you can stop here. Continue to Under the Hood for denied-case reasoning, residual risk, and scope discipline.