Industrial control systems run the parts of the world that don’t get to go down: power distribution, water treatment, manufacturing lines, chemical processing. They’re also some of the least defensible networks in existence, built on protocols from the 1980s, hardware with a 20-year service life, and an operational priority (keep the process running) that’s frequently at odds with security best practice (patch it, segment it, lock it down).
This post covers the failure modes that actually show up in ICS breaches, paired with the real incidents that demonstrate each one.
What’s an ICS?#
Industrial control systems are the computers that monitor and control physical processes in critical infrastructure: energy, water, transportation, manufacturing. They break down into three components. Sensors collect data about the physical process (temperature, pressure, flow). Controllers use that data to issue commands to actuators, valves, motors, pumps, that actually change the physical process. Human-machine interfaces (HMIs) give operators a way to watch and control all of it.
A few things make ICS security a different discipline from enterprise IT security. The hardware is highly distributed, often composed of gear from several vendors, and often deployed in remote or harsh environments. It has a long service life and can’t be swapped out the way a laptop can, which means a lot of ICS networks are still running software and protocols that predate modern security thinking and can’t be easily patched. And the priority order is inverted from a typical enterprise network: availability usually outweighs confidentiality and integrity, because the consequence of an ICS going down isn’t a leaked spreadsheet, it’s a power outage, contaminated water, or worse.
Where ICS environments actually get breached#
Network segmentation#
An ICS network with no segmentation is a single blast radius: an attacker who lands anywhere can reach everything. Segmentation limits that by dividing the network into isolated pieces, each with its own access controls, so a foothold in one segment doesn’t hand over the whole environment. The standard toolkit for this is VLANs to logically separate devices, DMZs to buffer the OT network from the internet and from the corporate IT network, firewalls to enforce the boundaries between segments, and role-based access control (RBAC) to limit what an authenticated user or device can reach even within a segment. Air-gapping, physically disconnecting the network entirely, is the extreme version and is expensive enough to manage that it’s usually reserved for the most critical systems. Building the segments isn’t the finish line, either; validate them with penetration testing after implementation, since a segmentation strategy that looks correct on a network diagram can still leak in practice.
The most common way segmentation actually fails is dual-homed systems: a device connected to both the IT and OT networks at once, usually to provide some legitimate bridge between them. It’s also the single most direct path an attacker can take straight from a phished corporate laptop into the control network, and it can bypass segmentation entirely regardless of how well the rest of the network is designed. If you have dual-homed systems, monitor them closely, harden them, and restrict what traffic can cross them to only what’s essential.
Triton (2017). Attackers compromised a Schneider Electric Triconex safety instrumented system at the Petro Rabigh petrochemical plant in Saudi Arabia. A bug in the attackers’ own malware triggered an unplanned safe shutdown, which is how the intrusion was discovered in the first place. Triton’s real capability, disabling the safety system that’s supposed to prevent a catastrophic failure, is the part that should worry you: it means the attackers weren’t just after data, they were positioning to disable the one thing standing between a process fault and physical harm.
Authentication#
Default and weak credentials are still one of the most common ways into ICS devices, many of which ship with well-documented default passwords that never get changed. The fix is unglamorous: complex, unique passwords (12+ characters, not dictionary-based), rotated regularly; multi-factor authentication wherever it can be layered on; role-based access so a compromised account only grants what that role actually needs; and, non-negotiably, changing every default credential before a device goes into production. This applies to devices, not just people: an ICS device joining the network should present a valid digital certificate or equivalent credential before it’s trusted, the same way a user has to authenticate.
Mirai and the Dyn attack (2016). The Mirai botnet didn’t crack passwords through brute force. It scanned the internet for devices with Telnet open and tried a fixed list of about 60 hardcoded default username and password pairs, credentials that on many of the compromised IoT devices couldn’t even be changed. That was enough to build a botnet large enough to knock Dyn, a major DNS provider, offline and take a chunk of the internet down with it. Mirai targeted consumer IoT rather than ICS specifically, but the lesson transfers directly: unchanged default credentials on internet-reachable devices is one of the cheapest attacks that exists, and it works at scale.
Outdated software and firmware#
Legacy software and firmware that never gets patched is close to a structural feature of ICS environments rather than an oversight, because a lot of this hardware physically cannot be patched without downtime the business can’t absorb, or without breaking vendor support. That doesn’t make it less dangerous. A real patch management program needs an inventory of every device and its firmware version, a process for monitoring vendor security bulletins, testing patches in a non-production environment before deployment, and a documented baseline configuration so deviations are visible. Wrap all of it in a formal change management process, documented procedures for testing, deploying, and rolling back, so patches go out in a controlled way instead of ad hoc.
WannaCry (2017). The ransomware spread using EternalBlue, an NSA-developed exploit for a flaw in SMBv1 (Microsoft’s file-sharing protocol) that had leaked publicly via the Shadow Brokers a month earlier. Microsoft had already shipped a patch, MS17-010, but the machines that got hit hadn’t applied it. WannaCry wasn’t an ICS-specific attack, but it hit ICS environments hard regardless, because so many run Windows systems that are difficult to patch on any reasonable cadence, and once inside a flat network, a worm doesn’t care what kind of device it’s spreading to.
Monitoring and logging#
An ICS network without monitoring can be compromised for a long time before anyone notices, because there’s nothing watching for the compromise in the first place. A working program combines network monitoring (unusual traffic, unexpected connections to ICS devices, known attack signatures), host-based monitoring (unauthorized file changes, unusual process activity), centralized logging that captures system, network, and ICS-specific events like control commands, and a SIEM to correlate all of it into something a human can actually act on. NIST’s Cybersecurity Framework, updated to version 2.0 in 2024, is a reasonable structure to build this around: Govern, Identify, Protect, Detect, Respond, Recover.
Stuxnet (discovered 2010). The worm that targeted Iran’s Natanz nuclear enrichment facility is believed to have been active since around 2007, meaning it operated undetected for roughly three years before a self-propagation bug caused it to spread outside the intended environment and get noticed. Three years of undetected dwell time inside a nuclear facility’s control systems is the strongest possible argument for monitoring that actually watches ICS traffic and behavior, not just the IT network around it.
Remote access#
Remote access is a necessary convenience and a direct line into the control network if it isn’t secured. That means strong authentication (MFA, not just a password), access controls scoped to what the remote user actually needs, encrypted channels (SSH or VPN rather than an exposed protocol), monitoring of remote sessions specifically, firewall rules that restrict remote access to known IP ranges, and the same patch discipline for the VPN gateways and remote desktop servers that make the access possible in the first place, since those are common targets in their own right. Smartphones and tablets increasingly show up on this list too; if mobile devices can reach the ICS network, they need the same device authentication and access controls as anything else, not an exception because they’re convenient.
Oldsmar, Florida (February 2021). An attacker accessed the water treatment plant’s SCADA system through TeamViewer, remote access software with legitimate use by plant staff, and raised the sodium hydroxide (lye) setpoint from around 100 parts per million to 11,100, roughly a hundredfold increase. A plant operator watched the cursor move across his screen in real time, immediately reversed the change, and no contaminated water ever left the plant. It worked out because a human happened to be watching. That’s not a monitoring program, that’s luck, and it’s the gap between “we have remote access” and “we have secured remote access.”
Ukrainian power grid attack (December 2015). Sandworm, a Russian state-linked group, spear-phished their way into a Ukrainian utility’s corporate network with malicious Office macro documents, then pivoted from there into the ICS network controlling power distribution. Using the BlackEnergy3 malware for persistent access and KillDisk to destroy data and complicate recovery, the attackers remotely opened breakers and cut power to roughly 230,000 customers. It remains the clearest real-world demonstration of what an attacker with full ICS access can actually do, and of how directly a phishing email on the corporate side can end in a blackout on the OT side.
Why the protocols themselves are insecure#
Data moving across an ICS network should be encrypted, both in transit and at rest, using strong algorithms with keys that are managed and rotated properly. Digital certificates from a trusted CA provide mutual authentication between devices and users. TLS is the standard for general traffic; SSH or a VPN should wrap remote access specifically. None of this replaces network segmentation, it’s what protects the traffic that has to cross segment boundaries in the first place. Data historians and other storage systems deserve the same attention specifically, since they aggregate process data from across the environment and are a correspondingly attractive target, so encrypt what’s stored there, not just what’s moving.
That still leaves the ICS protocols themselves, and this is worth understanding at the packet level rather than taking on faith, because the insecurity isn’t a configuration mistake you can patch. It’s the design.
Modbus is the oldest and most common of the three, designed by Modicon (now Schneider Electric) back in 1979 for
serial communication between PLCs, later extended to run over TCP on port 502. It organizes data into four tables:
coils and discrete inputs (single-bit values representing physical outputs and inputs, like a relay or a limit
switch), and input and holding registers (16-bit values, with holding registers used for setpoints and
configuration). A small set of function codes covers everything a client needs: read coils, read registers, write a
single coil, write a single register, write multiple coils or registers. And that’s the whole security model, there
isn’t one. Modbus has no authentication, no encryption, and no integrity or replay protection beyond a basic
transport checksum meant to catch transmission errors, not tampering. Any client that can open a TCP connection to
port 502 can issue any function code the device will accept, no credentials required. If you can read the register
map, either by brute-forcing reads or pulling vendor documentation, you can write to it. A Modbus/TCP Security
extension adding TLS exists, but it isn’t backward compatible with the installed base and rarely shows up in the
field, so most Modbus traffic you’ll encounter runs in the clear. pymodbus and mbtget are the standard tools for
talking to it; smod builds Metasploit-style attack modules on top.
The frame itself makes the point better than a description can. Here’s a write-single-register request, the whole thing:
packet-beta title Modbus/TCP frame (write single register, FC 0x06) 0-15: "Transaction ID" 16-31: "Protocol ID (0x0000)" 32-47: "Length" 48-55: "Unit ID" 56-63: "Function Code (0x06)" 64-79: "Register Address" 80-95: "Register Value"
Seven bytes of MBAP header to route and frame the message, then a function code and whatever data that code needs. Nowhere in there is a field for a username, a token, or a signature, because the spec never allocated one. That’s not a simplification for the diagram, that’s the entire frame.
DNP3 is dominant in North American electric and water utilities, standardized as IEEE 1815 after Westronic (later
GE Harris) developed it in the early 1990s for the low-bandwidth serial and radio links common in utility telemetry.
It runs a master/outstation model, TCP port 20000, with the outstation always acting as the server. Structurally it
has the same hole as Modbus: no authentication, no encryption, nothing beyond a CRC that catches transmission errors
rather than deliberate tampering. An attacker positioned to intercept or spoof the master-outstation session can
inject unsolicited control commands or rewrite a legitimate one in flight, the textbook example being a CLOSE
breaker command silently rewritten to TRIP. DNP3 does have a real answer to this, Secure Authentication version 5
(SAv5, IEEE 1815 Chapter 7), which adds HMAC-based challenge-response so an outstation can verify a command actually
came from an authorized master. It was deliberately built to be backward compatible so it can run alongside
unauthenticated legacy peers on the same network, which is exactly why it’s easy to leave switched off entirely, and
a lot of the installed base of outstations can’t be upgraded to support it even if an operator wanted to.
IEC 61850 is the modern substation automation standard, first published in the early 2000s to replace the patchwork of proprietary serial protocols inside a substation. Two pieces of it matter here. GOOSE (Generic Object Oriented Substation Event) is a raw, non-routable multicast Ethernet frame used for time-critical peer-to-peer signaling directly between protection relays, breaker trips and interlocking status, and it has no native authentication or encryption at all. It carries sequence numbers for detecting retransmissions, but those provide no cryptographic protection, so a local attacker who can craft a frame with a plausible sequence can get it accepted as genuine. MMS (Manufacturing Message Specification) is the other half, TCP/IP-based supervisory traffic on port 102 for SCADA and HMI polling and control, and it inherits the same base weakness as Modbus and DNP3 unless it’s separately secured. The reason GOOSE stays unauthenticated in practice isn’t neglect, it’s physics: IEC 61850-5 requires the most time-critical trip messages to complete in under 4 milliseconds, and the cryptographic signature schemes tested against that budget (the extension is IEC 62351-6) haven’t been fast enough to meet it in real deployments. That’s a genuine, unresolved engineering tension between security and the timing a protection relay needs to actually protect anything.
The real-world case study for all three of these is Industroyer (also tracked as CrashOverride), the malware behind
the December 2016 attack on the Ukrainian grid, and it’s worth being precise about what it actually did rather than
the popular shorthand. Industroyer shipped separate payloads for IEC 60870-5-101 and -104 that hijacked the
legitimate communication process on the target system and looped “select and execute” commands, iterating discovered
addresses and simply flipping their state, no authentication to bypass because there wasn’t any. Its IEC 61850 module
worked the same way but over MMS, not GOOSE: it opened a session on port 102, enumerated variable names looking for
patterns like CSW (the logical-node name IEC 61850 uses for breaker and switch control), and issued reads and
writes to change breaker state directly. That distinction matters if you’re learning this: Industroyer is a real,
devastating demonstration of unauthenticated ICS protocol abuse, but it’s an MMS/supervisory-layer attack, not the
GOOSE/protection-layer spoofing that shows up in academic research. Modbus and DNP3 don’t have an equivalent headline
incident attached to them, and that’s worth sitting with rather than treating as reassurance; their insecurity gets
proven constantly through Shodan-exposure research and routine pentests, it just doesn’t need a named breach to be a
real risk. A protocol doesn’t have to make the news to be broken.
Antivirus and endpoint protection in ICS#
Standard enterprise antivirus often isn’t compatible with ICS software and can actively interfere with a control system’s performance, so the product needs to be chosen with that constraint in mind, and scans need to run during low-activity windows rather than whenever the enterprise policy defaults to. Beyond signature-based AV, file integrity monitoring (FIM) catches unauthorized changes to control system configurations, host-based intrusion detection catches unauthorized changes more broadly, network-based intrusion detection (Snort and Suricata both do this well) catches exploitation attempts and malicious traffic, and sandboxing gives you a safe place to detonate anything suspicious before it touches production. Tripwire and OSSEC are common choices for the file integrity and host monitoring pieces specifically. None of this works without a process to keep it updated; stale AV definitions and stale detection rules are functionally no protection at all.
Incident response#
An ICS incident response plan needs a named team that includes IT, security, operations, and relevant vendors, not just a generic security on-call rotation, because restoring a control system safely requires people who understand the physical process. Define procedures for identifying, containing, and recovering from an incident; build a communications plan covering internal stakeholders, regulators, and vendors; and have a disaster recovery plan that covers restoring configurations and data specifically for control systems, not just IT infrastructure. CISA (which absorbed the standalone ICS-CERT branding in 2023) publishes ICS-specific incident response guidance worth building your process around, and NIST’s CSF 2.0 covers the same ground at a higher level. None of this is worth much without regular tabletop exercises that actually simulate an ICS-specific incident, and without updating the plan based on what those exercises turn up.
Two more habits round this out. Regular vulnerability assessments, including penetration testing, catch what day-to-day operations miss. And employees need to understand ICS-specific risk, not generic security awareness training, since the consequences here (physical, not just data) are different from what most security training assumes.
Tools attackers use against ICS#
An engagement testing an ICS environment usually draws from the same reconnaissance and exploitation toolkit as any other assessment, with a handful of ICS-specific additions. Nmap and OpenVAS handle discovery and scanning. Wireshark, Zeek (the network security monitor formerly known as Bro), and Suricata handle protocol analysis, useful for understanding what an ICS protocol is actually doing on the wire before you try to abuse it. Metasploit and Core Impact both ship SCADA-specific exploit modules as add-ons to their general-purpose frameworks, rather than being ICS tools in their own right. Rockwell and Siemens hardware also shows up in lab environments, not because either company sells a testbed product, but because their real PLCs and control systems are what a lot of labs standardize on to match what’s actually deployed in the field.
For a safe place to practice, three open-source options cover different needs, and none of them require touching a
client’s environment or your own production network. MiniCPS, from SUTD’s SCy-Phy research group, extends Mininet
(the SDN network emulator) with simulated Modbus/TCP and EtherNet/IP devices plus a physical-process simulation
layer, so instead of just capturing packets you watch a spoofed register write actually move a simulated value. It
ships a working example built around the SWaT (Secure Water Treatment) testbed research: make swat-s1-init && make swat-s1 stands up three simulated PLCs and a tank-level process you can attack directly. It’s a research toolkit
more than a turnkey lab, though, it needs Linux, Mininet, and root, and you’ll be writing Python to define anything
beyond the built-in example. OpenPLC sits at the other end of that spectrum: a real, working soft-PLC that
implements IEC 61131-3 (ladder logic, structured text, and the rest), speaks Modbus/TCP, and runs as a Docker
container or on real hardware like a Raspberry Pi. Stand it up, write a simple ladder-logic program controlling a
digital output, then attack it from a separate machine with pymodbus or Metasploit’s Modbus modules exactly the way
you would a real PLC on an engagement. If you find OpenPLC v3 tutorials online, note that the project restructured
in 2026: v3 is archived, and the current OpenPLC Runtime and Editor live under the Autonomy-Logic org instead. And if
you want both halves at once, a real PLC plus a simulated process plus pre-built exercises, GRFICS pairs OpenPLC with
a simulated industrial process and ships ready-made scenarios: man-in-the-middle, command injection, false data
injection, PLC reprogramming in the style of Stuxnet, and malicious firmware upload in the style of Triton. It’s the
closest thing on this list to a guided course rather than a sandbox.
Malware in this space, Triton being the clearest example, arrives through the usual vectors: phishing, infected removable media, exploit kits. Once in, capabilities range from data exfiltration to outright disruption of the physical process, sometimes via a persistent backdoor rather than a smash-and-grab. Detection leans on the same tools mentioned above, Tripwire, OSSEC, Snort, plus dedicated OT platforms like Tenable.ot (formerly Indegy) and Microsoft Defender for IoT (formerly CyberX), both built specifically to understand ICS protocols rather than treating OT traffic like generic IT traffic. Prevention is mostly the same list this whole post has been building: segmentation, patching, and training. Recovery leans on the disaster recovery and incident response planning covered above.
What this comes down to#
Every incident in this post traces back to one of five gaps: no segmentation, weak credentials, unpatched systems, no visibility, or unsecured remote access. None of these are exotic. They’re the same fundamentals that show up in every security program, just with higher stakes, because an ICS breach doesn’t stop at stolen data. Get the fundamentals right here and you’ve closed the paths that Triton, Mirai, WannaCry, Stuxnet, and the Ukrainian grid attackers all actually used.
