Damage to Property (T0879) is the point where an attack on a control system stops being an IT problem and becomes broken equipment, spilled material or harm to the surrounding environment. In ATT&CK for ICS it is an Impact (TA0105) technique, and it is often the side effect of other techniques rather than a step in its own right. ATT&CK states that no standard detection method currently exists for it, so the defence lies in engineering: mechanical protection, independent safety systems and network allowlists that stop the earlier steps. This guide reviews the cases ATT&CK records, the three mitigations it maps, and how to plan for physical consequences. It is for OT security leads, control and safety engineers and risk owners.
Key takeaways
- Damage is an outcome, not an action. ATT&CK describes it as resulting from breakdowns or as tangential damage from other techniques, and it can lead to Loss of Safety (T0880).
- There is no detection for the impact itself. ATT&CK's detection strategy states that no standard method exists, so detection effort belongs on the preceding techniques.
- Non-digital protection is the last line. ATT&CK's M0805 recommends interlocks, rupture disks and release valves with minimal digital components.
- Safety systems must stay separate. M0812 asks for safety instrumented systems segmented from operational networks.
- Old cases still teach. Maroochy (2000) and the German steel mill (reported 2014) show remote access and uncontrolled shutdowns turning into physical damage.
What T0879 covers
ATT&CK for ICS defines Damage to Property as adversaries causing damage and destruction of property to infrastructure, equipment and the surrounding environment when attacking control systems. It may result in device and operational equipment breakdown, or be tangential damage from other techniques. ATT&CK links it to three neighbouring impacts:
| Related technique | Relationship ATT&CK describes |
|---|---|
| T0880 Loss of Safety | Severe physical damage and disruption may result in loss of safety |
| T0827 Loss of Control | Operations that result in loss of control may also cause damage to property |
| T0828 Loss of Productivity and Revenue | Damage may be motivated directly or indirectly by an adversary seeking this impact |
ATT&CK lists no platform for the technique, because it is an effect in the physical world. For the tactic-level view of how adversaries reach this point, see the ATT&CK for ICS Impair Process Control Tactic Guide and the ATT&CK for ICS Inhibit Response Function Tactic Guide.
Cases ATT&CK records
| Case | What ATT&CK records | Defensive lesson |
|---|---|---|
| Maroochy Water Breach (C0020), 2000 | Remote access to the wastewater control system and altered data so that pumping station functions did not occur, or occurred differently; about 800,000 litres of raw sewage spilled into parks, rivers and a local hotel, harming marine life | Radio and engineering software access gave full control; device allowlists and alarm integrity would have limited it |
| German steel mill, reported by BSI in its 2014 IT security report | A targeted attack affected industrial operations and caused breakdowns of control system components and whole installations; an uncontrolled shutdown of a blast furnace caused massive damage | Plan for the physical result of losing control, including safe shutdown paths that do not depend on the control network |
| Lodz tram system, Poland, 2008 | A student used a remote controller device to capture and replay legitimate tram signals; ATT&CK reports four trams derailed and forced emergency stops | Unauthenticated wireless control signals can cause physical harm directly |
| CyberAv3ngers (G1027), 2026 Iranian Water Campaign | Disrupted water operations, including loss of water pressure and flooding | Exposed and weakly protected controllers in water utilities remain a live risk; see the CyberAv3ngers Threat Actor Profile Guide |
ATT&CK's Maroochy campaign page also maps the incident to Rogue Master (T0848), Wireless Compromise (T0860), Alarm Suppression (T0878) and Modify Parameter (T0836), which shows how many earlier steps sat in front of the damage. These are the steps you can detect.
Triton: intent without damage
Triton is often discussed alongside physical damage because it targeted safety instrumented system controllers. CISA's HatMan analysis (MAR-17-352-01) is careful here: it states that the malware on its own does nothing catastrophic, because safety systems do not directly control the process, but that combined with malware affecting the process it could contribute to physical harm. CISA's report does not record damage occurring. Treat Triton as evidence that adversaries study the safety layer, not as a damage case. See the Safety Instrumented Systems Security Guide.
The three mitigations ATT&CK maps
- M0805 Mechanical Protection Layers: protection devices should have minimal digital components so they are not exposed to related adversarial techniques. Examples ATT&CK gives are interlocks, rupture disks and release valves. These act on physics, so a compromised controller cannot disable them.
- M0812 Safety Instrumented Systems: ensure all SIS are segmented from operational networks to prevent them from being targeted by additional adversarial behaviour. The HatMan report adds keeping safety engineering stations off larger networks and keeping the controller key switch out of program mode except during approved changes.
- M0807 Network Allowlists: host-based allowlists so devices accept connections only from master stations or known management and engineering workstations. At Maroochy, a rogue device acting as a master was enough.
| Protection layer | Example | Survives a compromised controller? | Security owner action |
|---|---|---|---|
| Mechanical (M0805) | Relief valves, rupture disks, hard-wired interlocks | Yes, acts on pressure or position directly | Confirm in the process hazard analysis that the worst cyber case is bounded by these devices |
| Safety instrumented system (M0812) | Independent safety controller and sensors | Yes, if segmented and its engineering path is protected | Segment, restrict engineering access, alarm on mode changes |
| Basic process control | PLC or DCS logic and alarms | No, this is the layer the attacker targets | Network allowlists (M0807), integrity checks, monitoring |
| Operator response | Alarms and HMI displays | Not reliably, alarms and views can be manipulated | Independent indications for critical variables |
Planning for physical consequences
- Bring cyber into the hazard study. For each high-consequence scenario, ask what happens if the control system issues the worst credible commands and suppresses the alarms. See the OT Cyber Physical Risk and Safety Guide.
- Identify which scenarios only digital layers protect. Those are candidates for added mechanical protection or independent safety functions.
- Segment safety systems. Follow zone and conduit design so the SIS is reachable only through controlled paths; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide and the IEC 62443 Guide.
- Allowlist controller connections. Only named master stations and engineering workstations should reach field devices.
- Exercise a cyber-initiated shutdown. Practise bringing the process to a safe state manually, without trusting HMIs.
Detection: watch what comes before
ATT&CK's detection strategy for T0879 (DET0762) contains one analytic, which states that no standard detection method currently exists for this technique. Plant instrumentation will show the damage; security monitoring should catch the steps before it. Based on the cases above, prioritise:
- Connections to field devices from hosts or radios that are not approved masters.
- Parameter writes, program downloads and operating mode changes outside change windows.
- Alarm suppression or alarm setting changes.
- Any network path or engineering session that reaches the safety system.
See the OT Network Security Monitoring Guide for collecting these signals.
Where identity fits
Several recorded cases turn on who could connect and command: an outsider with engineering software and radio access at Maroochy, and controllers reachable with weak protection in water utilities. Named engineering accounts, controlled vendor access and removal of default credentials reduce the number of paths to a damaging command. See the OT and ICS Identity and Access Guide.
Responding when damage is possible
- Process safety first. Operations decide on safe state or shutdown; security supports with information.
- Use independent indications. Do not rely on HMIs that may be manipulated.
- Preserve evidence without delaying safety action. Controller programs, engineering station images and network captures matter for root cause, but never ahead of safety.
- Check the safety layer. Verify SIS programs and modes against approved baselines.
- Report as required. Physical damage may trigger safety and environmental reporting as well as cyber reporting. See the OT Incident Response Guide.
Measuring readiness
- Hazard study coverage: share of high-consequence scenarios assessed with a cyber-initiated cause.
- Non-digital backstop coverage: share of those scenarios bounded by a mechanical protection layer or independent safety function.
- SIS segmentation: number of network paths into safety systems outside approved conduits, target zero.
- Allowlist enforcement: share of field devices that accept connections only from approved masters.
- Exercise frequency: manual safe shutdown drills with a cyber scenario per year.
Common failure patterns
- Treating digital safety as independent when it shares a network: M0812 exists because SIS on operational networks can be reached by the same attacker.
- Removing mechanical protection during modernisation: replacing a relief device with a software trip removes the layer an attacker cannot reach.
- Hazard studies that assume the control system fails randomly: an adversary can create combined failures and hide alarms at the same time.
- Waiting for an impact alert: there is no standard detection for the damage itself, only for the steps before it.
- Unauthenticated remote and wireless control: both Maroochy and Lodz involved commands accepted from devices that should not have been trusted.
Practitioner checklist
- Add cyber-initiated causes to the process hazard analysis for high-consequence scenarios.
- Confirm mechanical protection layers exist where consequence is severe, and are retained in upgrades.
- Segment safety instrumented systems from operational networks.
- Keep safety controllers out of program mode except during approved changes, and alarm on mode changes.
- Enforce network allowlists so field devices accept only approved masters.
- Monitor for the preceding techniques: rogue masters, parameter changes, alarm suppression.
- Run manual safe shutdown exercises with a cyber trigger.
Standards and references
- MITRE ATT&CK for ICS: T0879 Damage to Property
- MITRE ATT&CK for ICS: Maroochy Water Breach (C0020)
- MITRE ATT&CK for ICS: M0805 Mechanical Protection Layers
- MITRE ATT&CK for ICS: M0812 Safety Instrumented Systems
- MITRE ATT&CK for ICS: M0807 Network Allowlists
- CISA: MAR-17-352-01 HatMan, Safety System Targeted Malware
- MITRE ATT&CK: CyberAv3ngers (G1027)
Related NHI Mgmt Group resources: Safety Instrumented Systems Security Guide, OT Cyber Physical Risk and Safety Guide, Water and Wastewater Cybersecurity Guide, ICS Malware History Guide.