Recap: I Watched Someone Take Over a Cooling System From a Laptop — IT/OT Security at Upper Bound 2026

Part of my Upper Bound 2026 series — write-ups of the talks I caught at Amii's AI conference in Edmonton that I wanted to carry home. This one was on the eStruxture Stage, Thursday May 21, and it was the most visceral session of the week. There was a live attack demo. On a cooling system. From a laptop. I want to walk through what they showed.

The Talk: "Critical Infrastructure Cyber Attack Vectors and Prevention"

Prashant Prashant and Rajat Kundu gave this one on the eStruxture Stage, 11:30–12:00 on May 21. The pitch going in was "GenAI as an adversarial asset against industrial control systems." The delivery was: a structured walkthrough of how IT and OT networks are supposed to be separated, followed by a live demonstration of what happens when that separation has gaps — specifically, a Modbus injection attack launched from a Kali Linux machine using Metasploit's modbusclient module, aimed at a simulated data-center cooling system.

I watched them take control of that cooling system from a laptop. In about five minutes. On a conference stage.

That's the talk. Let me unpack why it worked and what it means.

Who They Are

Prashant Prashant and Rajat Kundu are security practitioners working in the industrial and critical-infrastructure space. The talk was squarely in the defensive-security/OT track — the goal wasn't to teach anyone how to attack things, it was to demonstrate concretely why certain architectural assumptions are wrong, and what the actual mitigations look like.

The Foundation: The Purdue Model

Before the demo, they grounded the audience in the model that most OT/ICS security thinking builds on: the Purdue Enterprise Reference Architecture, developed by Theodore J. Williams at Purdue University in the early 1990s. It gives industrial environments a layered hierarchy for separating process control from enterprise IT. The levels:

• Level 0 — Physical process: sensors, actuators, the thing actually happening in the physical world (temperature, pressure, flow).
• Level 1 — Basic control: PLCs and RTUs that read Level 0 and issue direct commands to process equipment.
• Level 2 — Supervisory control: SCADA systems and HMIs, the dashboards and control loops that operators interact with.
• Level 3 — Site operations: production scheduling, historian systems, the operational layer that aggregates plant data.
• Level 3.5 — The DMZ: the buffer zone. Traffic between OT and IT should pass through here and nowhere else, with strict controls on what can transit.
• Level 4+ — IT / enterprise: business systems, ERP, the corporate network. This is the internet-facing, patch-regularly, helpdesk-ticket world.

The point the Purdue Model makes — and the point the whole talk turned on — is that Levels 0–3 are operational technology. They run processes that have physical consequences. They often run on legacy hardware with decades-old firmware. They weren't designed with internet-era threat models. The model says: keep them separated from IT by zones and conduits, with the DMZ as the only sanctioned crossing point.

Worth a note: the Purdue Model shares a layered hierarchy with ISA-95, the standard for integrating enterprise and control-system networks, but they're not the same thing — ISA-95 is focused on manufacturing integration, while Purdue is the security reference architecture. The security standard that operationalizes Purdue-style thinking is ISA/IEC 62443, which formalizes the "zones and conduits" approach as the basis for industrial cybersecurity. NIST SP 800-82 Rev. 3 (September 2023) — Guide to Operational Technology Security — is the other essential document here, mapping these concepts to a broader OT-security framework.

The Demo: Modbus and the Attack

Here's the thing about Modbus: it was developed by Modicon (now Schneider Electric) in 1979 as a serial communication protocol for industrial equipment. It is still running in data centers, factories, and utilities around the world right now. And it has no built-in authentication, no encryption, and no message integrity verification. None. If you can reach a Modbus device on the network, you can talk to it. If you can talk to it, you can issue commands.

The demo was structured as a scenario: a data-center cooling system, controlled via Modbus, with a simulated network segmentation gap — the kind that exists in real environments when OT and IT networks have been quietly bridged over years of "just let operations connect to this one thing." Prashant and Kundu used Kali Linux and Metasploit's scanner/scada/modbusclient auxiliary module to connect to the simulated controller and manipulate its register values.

I want to be careful about what I describe here, because the point of the demo was educational and defensive — it was about motivating the architectural fixes, not about giving anyone a cookbook. So I'll say this: what they showed was not complicated. The commands were short. The protocol's lack of authentication meant there was no authentication step to defeat. The "attack" in this case was closer to "send a legitimate-looking message to a device that cannot tell the difference between you and the authorized operator" than it was to any clever exploit. That's the unsettling part. The vulnerability isn't in a specific CVE. It's in the architecture.

A data-center cooling system that receives incorrect setpoints or gets commanded to change its operating state can cause thermal runaway. In a real environment, that means equipment damage or failure. That's what the demo made concrete: this isn't theoretical. The gap between "attacker can reach the device" and "attacker can cause physical damage" is a single Modbus write.

The Four Vulnerability Classes They Named

Prashant and Kundu organized the attack surface around four classes that the demo illustrated:

1. Network segmentation gaps. The Purdue DMZ exists on paper; in practice, there are bridges — a vendor VPN that lands on the wrong segment, a historian that got connected directly to enterprise file shares, a "temporary" IT-to-OT link that's been temporary for seven years. Each gap is a potential Modbus-reachable path.
2. Inadequate protocol monitoring. Modbus traffic looks like normal OT traffic, because it is normal OT traffic. Without behavioral baselines and anomaly detection on the OT network, you can't distinguish a legitimate operator from an attacker. Most OT environments have very little of this.
3. Insufficient access controls. Modbus has no access controls to strengthen. But the network layer around it can — and often doesn't. Firewall rules on OT segments are frequently too permissive, credentials for HMI access are shared or default, and role-based controls are rare.
4. Undetected operational disruption. An attacker who can issue commands to a cooling system doesn't have to cause immediate dramatic failure. They can make gradual changes — drift setpoints, suppress alerts, modify historian values — that accumulate into a serious incident before anyone notices anything is wrong. The demo made the point that impact can be spread across time in ways that look like operational noise until they don't.

The Defenses

The second half of the talk was what to do about it. The recommendations weren't novel, but the demo gave them teeth:

• Strict network segmentation. Enforce the Purdue DMZ for real, not just on the architecture diagram. Traffic between OT and IT passes through the DMZ and nowhere else. ISA/IEC 62443's zones-and-conduits model is the framework for implementing this rigorously.
• Deny-by-default firewall rules on OT segments. The default posture should be: nothing traverses the OT/IT boundary unless it's explicitly allowed by policy. Whitelisted, not blacklisted.
• Isolate ICS from IT networks. Physically if possible, logically at minimum. The less IT-networked infrastructure that can reach Level 1 or Level 2, the smaller the attack surface. This includes third-party vendor access — every remote-access path to OT is a potential entry point.
• Protocol-aware monitoring. Put sensors on the OT network that understand Modbus (and DNP3, and EtherNet/IP, and the other ICS protocols in your environment) and alert on unexpected register writes, unusual command sequences, or access from unexpected sources. MITRE ATT&CK for ICS is the threat-technique knowledge base for this — it maps attacker behaviors to the ICS-specific tactics you'd want to detect.

NIST SP 800-82 Rev. 3 is the practical guide for anyone implementing this in an OT environment — it covers network architecture, asset management, monitoring, and incident response for control systems specifically.

The GenAI Angle: They Red-Teamed Themselves With It

Here's where GenAI actually came into this talk — and it's more grounded than the usual "AI will attack you" framing. The presenters used GenAI as part of their own red-team: leaning on it to find attack paths and probe their own setup the way an adversary would. The model becomes a force-multiplier for whoever's doing the probing — speeding up reconnaissance, helping assemble the attack against an unauthenticated Modbus device, surfacing where a segmentation gap might be hiding.

The defender's takeaway is the uncomfortable flip side: the same acceleration is available to whoever's probing your environment. The demo used free tooling that's been around for years; GenAI just lowers the skill and time floor for putting it to use. The fix doesn't change — close the architectural gaps — but there's less runway to do it.

The Real-World Stakes

Prashant and Kundu placed the demo in a lineage of real attacks that validate the threat model:

• Stuxnet (2010) — a sophisticated nation-state worm targeting Siemens PLCs at the Natanz uranium enrichment facility. The canonical proof that physical infrastructure can be damaged through digital means.
• TRITON/TRISIS (2017) — malware that targeted Schneider Electric Triconex safety instrumented systems (SIS). Safety systems exist to prevent catastrophic failures; TRITON was designed to disable them. The intent appeared to be enabling a physical disaster to occur without the safety shutoff triggering.
• Industroyer/CrashOverride (2016) — the malware behind the Ukraine power grid attack. It spoke native industrial protocols — IEC 104, IEC 101, IEC 61850, and others — to issue commands directly to substation equipment.

These weren't theoretical. They happened. The demo on the conference stage was a lower-tech illustration of the same class of vulnerability: a protocol with no authentication, a segmentation gap, and a device that does what it's told.

Why It Stuck With Me

I've been thinking more about OT security over the past few months — partly because I'm in the early stages of building a small Purdue-model lab of my own, just to get hands-on with how these network layers actually behave. Nothing elaborate, just enough to make the architecture tangible. Watching this demo made me glad I'm doing that from the defenders' side with a map in hand.

The thing the demo did that a slide wouldn't: it made the gap between "this is a known vulnerability" and "an attacker can actually exploit this, today, in an afternoon" feel like nothing. The protocol is old. The tools are free. The barrier is not technical sophistication. The barrier is architecture — and architecture has been quietly violated in production environments for years because convenience beat discipline.

Two things I'm carrying from this one:

• The DMZ is not optional. The Purdue model's Level 3.5 exists for a reason. If you're in an environment where OT and IT networks have been bridged, that's not a configuration detail — it's an open door.
• Modbus doesn't protect itself. Neither does DNP3, or most of the other protocols running in the OT stack. The network around them is all you have. Make the network strong.

And the reframe they left the room with, which I keep coming back to: stop asking "does the AI understand what it's doing?" The Modbus demo had no AI in it. The protocol doesn't care who's issuing commands. The question that matters for critical infrastructure isn't about AI comprehension — it's about accountability: who is accountable when something goes wrong? That question gets harder and more urgent as AI-assisted attacks become more automated and harder to attribute.

The accountability side of that question is something I'm covering in another post in this series — there was a session at Upper Bound on frameworks for AI-agent accountability that this one pairs with naturally. Stay tuned.

The Research Base

The references that back the core claims here:

• The Purdue Enterprise Reference Architecture — Theodore J. Williams, Purdue University, early 1990s. The foundational layered hierarchy for IT/OT segmentation. Note: shares structural similarities with ISA-95 (manufacturing integration) but is not the same standard.
• ISA/IEC 62443 — the security standards series for industrial automation and control systems, formalizing zones and conduits: isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• NIST SP 800-82 Rev. 3 — "Guide to Operational Technology (OT) Security," September 2023: csrc.nist.gov/pubs/sp/800/82/r3/final
• Modbus — developed by Modicon (now Schneider Electric) in 1979. No built-in authentication, encryption, or message integrity verification. Metasploit's scanner/scada/modbusclient auxiliary module (Rapid7) is the tooling from the demo.
• ICS attack cases — Stuxnet (2010, Siemens PLCs, Natanz); TRITON/TRISIS (2017, Schneider Electric Triconex SIS); Industroyer/CrashOverride (2016, Ukraine power grid).
• MITRE ATT&CK for ICS — threat-technique knowledge base for industrial control systems: attack.mitre.org

More in the Upper Bound 2026 series: Bayesian optimization, AI-agent accountability frameworks, and a few other sessions worth unpacking.

Header photo by Ant Rozetsky on Unsplash.

Content on this blog was created using human and AI-assisted workflows described here. Original ideas and editorial decisions by Justin Quaintance.