OT/ICS/SCADA Forensics 2026: Investigating Breaches in Critical Infrastructure

A cyberattack on an operational technology (OT) network doesn't just steal data — it can shut down a power grid, contaminate a water supply, or halt oil refinery operations for weeks. Unlike IT breaches that primarily expose data, OT cyber incidents can halt production, damage equipment, and endanger human lives. In 2026, the stakes have never been higher. Newly identified threat groups AZURITE, PYROXENE, and SYLVANITE, alongside continued activity by ELECTRUM, KAMACITE, VOLTZITE, and BAUXITE, demonstrate how adversary activity is evolving across the ICS Cyber Kill Chain — targeting the assets that create operational impact at scale.

OT/ICS forensics is the discipline that investigates these incidents — and it is fundamentally unlike any other DFIR domain. Legacy systems, air-gap myths, proprietary protocols, and safety constraints combine to create an evidence environment where standard DFIR procedures can physically damage the infrastructure you are trying to protect. This blog explains what OT forensics actually looks like in 2026 and how to build the capability before an incident forces the question.

Why OT Forensics Breaks Every IT Forensic Assumption

The Legacy Protocol Problem

Legacy protocols, safety constraints, and limited patch windows require passive monitoring and careful change control in OT environments. A Modbus RTU device running firmware from 2003 cannot be imaged like a Windows endpoint. Its memory is non-standard, its communication is unauthenticated by design, and any forensic interaction carries the risk of disrupting the physical process it controls.

Understanding the difference between a Modbus frame and a PROFINET packet, knowing what a PLC logic bomb looks like in a forensic trace, and having hands-on experience responding to OT incidents is the baseline competency requirement — not an advanced specialization.

Living-Off-the-Land in OT Environments

Living-off-the-land attacks reshape ICS and OT incident response as traditional organizational risk models struggle to cope — designed for static environments rather than dynamic, converged operational networks.

Nation-state actors operating inside OT networks increasingly use native engineering tools — the same software that legitimate operators use daily — to move laterally, modify PLC logic, and establish persistence. LOTL (Living-off-the-Land) in OT leaves no traditional malware signature, making behavioral analysis of engineering workstation activity the primary detection methodology.

Table: OT vs IT Forensic Investigation — Key Differences

Dimension	IT Forensics	OT/ICS Forensics
Primary evidence source	Windows Event Logs, disk	Historian logs, PLC ladder logic
Imaging approach	Bit-for-bit disk copy	Passive network capture only
Reboot for imaging?	Often acceptable	Never — may halt physical process
Protocol knowledge	TCP/IP, SMB, HTTP	Modbus, DNP3, PROFINET, EtherNet/IP
Safety constraint	None	Evidence collection can cause physical harm
Tooling standard	Volatility, FTK, Autopsy	Wireshark + OT protocol dissectors, Dragos

Critical Evidence Sources in OT Incident Response

The Historian: Your Most Valuable OT Evidence Source

The process historian — a time-series database recording every sensor value, setpoint change, and control action across the OT environment — is the forensic gold mine of ICS investigations. Unlike IT logs that record administrative actions, the historian records the physical world: exactly what temperature a reactor reached, when a valve opened, and whether the reading matched the control command sent.

Forensic techniques for ICS include network forensics to track attackers from phishing to HMI breach, examining technologies at Purdue Levels 2 and 3 including HMI and historian systems, and creating baselines for Windows-based workstations in industrial environments.

Historian evidence collection priorities:

Time-synchronized process data — every setpoint deviation from baseline during the investigation window
Operator action logs — HMI (Human-Machine Interface) keyboard and mouse events with timestamps
Alarm history — suppressed alarms are a primary indicator of attacker manipulation
Engineering workstation access logs — any unauthorized PLC programming session

Network Forensics at the Purdue Model Boundary

Network forensics at Purdue Levels 2 and 3 tracks attackers from initial phishing compromise through HMI breach — the IT/OT boundary crossing is the most forensically significant event in any ICS incident.

The Level 3/Level 2 boundary — where enterprise IT meets process control networks — is where most OT breaches cross. Full packet capture at this boundary using OT-aware protocol dissectors (Wireshark with Modbus/DNP3 plugins) provides the forensic record of exactly when and how an attacker moved from IT into OT.

Table: OT Evidence Sources by Purdue Model Level

Purdue Level	Systems	Key Evidence	Volatility
Level 4 (Enterprise IT)	Domain controllers, email	Windows Event Logs, Active Directory	Low
Level 3 (Operations)	Historian, SCADA servers	Process data, operator logs, HMI audit	Medium
Level 2 (Control)	HMI workstations, engineering stations	PLC program versions, ladder logic changes	Medium
Level 1 (Field devices)	PLCs, RTUs, DCS	Configuration files, setpoint history	High
Level 0 (Physical process)	Sensors, actuators	Physical process data (via historian)	Very High

Threat Groups and MITRE ATT&CK for ICS

Mapping 2026 Adversaries to the ICS Kill Chain

Cybersecurity incidents in OT environments go beyond data and into operations. In SCADA or DCS environments, a single event can disrupt control processes, impact safety instrumented systems, and create conditions that put people at risk.

The MITRE ATT&CK for ICS framework — distinct from the enterprise ATT&CK matrix — maps adversary TTPs specifically to industrial environments. Key techniques observed in 2026 incident response engagements include:

T0845 — Program Upload — attacker exfiltrates PLC logic to understand the physical process
T0836 — Modify Parameter — alters setpoints to cause physical damage while appearing normal
T0856 — Spoof Reporting Message — manipulates sensor readings so operators see false process data
T0816 — Device Restart/Shutdown — triggers unplanned shutdown of field devices
T0800 — Activate Firmware Update Mode — exploits firmware update to install malicious PLC logic

Important: Standard MITRE ATT&CK detection logic does not cover OT-specific techniques. Every DFIR team operating in or adjacent to OT environments must deploy ATT&CK for ICS as a separate detection and investigation framework alongside the enterprise matrix.

Compliance Frameworks for OT Forensic Investigations

Apply ISA/IEC 62443, NIS2, and CRA to support compliance and risk reduction in OT environments — these frameworks define the baseline security controls whose absence or failure you will be documenting during forensic investigations.

Key frameworks governing OT forensic evidence:

ISA/IEC 62443 — Industrial automation and control systems security standard
NIST SP 800-82 Rev. 3 — Guide to OT security with forensic evidence requirements
NERC CIP — Critical Infrastructure Protection standards for energy sector OT
NIS2 Directive — EU mandatory incident reporting for critical infrastructure operators

Key Takeaways

Never reboot or power-cycle OT devices for forensic purposes — physical process disruption is irreversible and may trigger safety incidents
Capture historian data immediately — process time-series records are your most precise evidence of attacker manipulation of physical systems
Deploy full packet capture at the Purdue Level 3/Level 2 boundary — this is where IT/OT crossing events are recorded
Use MITRE ATT&CK for ICS — the enterprise ATT&CK matrix does not cover OT-specific techniques like parameter modification or spoof reporting
Audit suppressed alarms — alarm suppression is the primary indicator that an attacker has manipulated HMI visibility to conceal physical process changes
Map all findings to ISA/IEC 62443 and NIST SP 800-82 — OT forensic reports must align with the compliance frameworks your critical infrastructure clients operate under

Conclusion

OT/ICS forensics in 2026 is the most consequential and least standardized DFIR discipline in practice. The evidence environments are fragile, the protocols are proprietary, the safety stakes are physical, and the threat actors — AZURITE, VOLTZITE, and their counterparts — are nation-state level in capability. Every DFIR team that operates near critical infrastructure needs OT-specific forensic procedures, historian evidence collection playbooks, and MITRE ATT&CK for ICS detection logic before an incident demands them. The next ICS breach will not wait for your team to learn the difference between a Modbus frame and a PROFINET packet. Build that knowledge now.

Frequently Asked Questions

Q: What is OT/ICS forensics and how does it differ from standard DFIR? A: OT/ICS forensics investigates cyber incidents in operational technology environments — industrial control systems, SCADA networks, PLCs, and HMI workstations that control physical processes. Unlike standard DFIR, OT forensics cannot use conventional imaging or reboot procedures because disrupting these systems can halt production or cause physical harm, requiring entirely different evidence collection methodologies.

Q: What is the most critical evidence source in an ICS forensic investigation? A: The process historian — a time-series database recording every sensor value, setpoint change, control command, and alarm event across the OT environment — is the most forensically valuable evidence source. It records the physical world with millisecond precision and can establish exactly when an attacker altered process parameters or suppressed alarms to conceal their manipulation.

Q: What is MITRE ATT&CK for ICS and why does it matter for OT forensics? A: MITRE ATT&CK for ICS is a distinct threat matrix mapping adversary techniques specific to industrial environments — including PLC parameter modification, spoof reporting messages, and firmware update exploitation. Standard ATT&CK enterprise techniques do not cover these OT-specific attack patterns, making ATT&CK for ICS the required framework for scoping, detecting, and documenting OT incident investigations.

Q: What is a living-off-the-land attack in OT and why is it forensically difficult? A: LOTL attacks in OT use legitimate engineering software — the same tools operators use daily — to move laterally, modify PLC logic, and establish persistence without deploying any detectable malware. Forensically, this means investigators must establish behavioral baselines for normal engineering workstation activity and identify deviations, rather than hunting for malware signatures.

Q: What compliance frameworks govern OT forensic investigations? A: ISA/IEC 62443 provides the primary industrial automation security standard. NIST SP 800-82 Rev. 3 governs OT security with forensic evidence requirements. NERC CIP mandates incident reporting and forensic evidence retention for energy sector critical infrastructure. The EU NIS2 Directive imposes mandatory incident notification obligations for operators of essential services across all OT sectors.