I gave a talk at the 2026 Southeast Symposium on Contemporary Engineering Topics (SSCET) called “Anatomy of an OT Attack.” This post is my slides and speaker notes all smashed together as best I could for the blog. It is not quite a direct transcript because the slides were sparse and I tend to rattle my gums a little differently once I’m in front of people.

The talk was about the part of an operational technology (OT) attack that usually gets compressed into one word: discovery. I used some old war stories and two recent papers to try to highlight a couple of things that I think are useful for blue teams. A little synthetic network telemetry helped show the difference between getting into a facility and learning enough to affect the processes inside it.

Before I go any farther, every event in this story happened during an authorized assessment with written permission. I pulled the events from several engagements and removed the identifying details before assembling one client safe story. This exact sequence never happened and the network records are also synthetic. They use real Zeek fields and documentation only IP addresses, but none of the values came from a client.

It is 2 a.m.

It is two o’clock in the morning, and I am going over a fence.

There are cameras. I can see them. I am climbing anyway.

I had already spent several days on site. I was not learning the terrain in the dark or wandering around with a flashlight. I knew the route and I knew where the cameras were. Under written authorization, I had effectively cased the place.

Once I was over the fence, I found an unlocked vehicle. Inside it were the things that mattered: a badge and keys. The photo on the badge was close enough to me that nobody looking from a distance would question it.

The fence makes for a better story for my talk, but the badge was more valuable. The fence got me onto the property. The badge gave me time and legitimacy.

Access is not an attack narrative

Richard Derbyshire’s paper, “The Challenges of Operational Technology Penetration Testing”, asks what a useful OT penetration test should produce. Too much of this work stops at the sort of result we already know how to produce in IT, such as a vulnerability list or a foothold. Sometimes it only proves that a device is reachable.

Derbyshire combined a literature review with interviews of five practitioners and five people who procure or manage OT penetration tests. The literature review found no public practitioner methodology for live OT penetration testing. The interviewees wanted plausible attack narratives tied to how the physical process works, not another pile of generic findings. Ten interviews make for a small sample, but what they wanted matched what I have seen on assessments.

Access proves that I can get somewhere. It says nothing about how the plant works or what manipulating it would do. A foothold is not an attack narrative.

Derbyshire’s summary of Marina Krotofil’s Cyber-Physical Attack Lifecycle made this click for me. It has five stages:

1. Access: Establish a foothold.
2. Discovery: Learn how the process works and identify useful control points.
3. Control: Test how the live process responds to manipulation.
4. Damage: Produce the physical effect.
5. Cleanup: Attempt to leave the wrong story behind after the effect.

The stages can loop, so this is not a rigid checklist. The composite attack in my talk moved from Access through Discovery and reached the boundary of Control. Dynamic manipulation was outside scope of my agreements and Damage and Cleanup are never in scope for my work.

Discovery is what turned access into a target specific plan.

Off the OT wire

What did the OT network sensor see while I crossed the fence and collected the badge from the vehicle?

Nothing.

None of those events touched the OT network. That does not mean nothing could see me. The access control system could record a badge event. Cameras and motion sensors could create their own evidence. Some of those systems may use a network, but they are not OT network telemetry by default.

The badge worked after hours. I entered the building, made small talk with an employee, and continued toward the equipment. At this point I was no longer invisible. The access control system had the credential and the time. The cameras had a record that could confirm the entry. The evidence existed, but nobody had decided the combination was worth reviewing.

An after hours badge rule and somebody responsible for checking it would have been enough to start asking questions. The camera record could then answer what happened.

Off the OT wire is not the same as invisible. It means the signal belongs to another control and probably another owner.

Now the wire can see me

Once inside, I placed a small computer on a switch port. In the synthetic examples below, that device is 192.0.2.77. It established a persistent reverse SSH channel through Tor. I represent the outside of that tunnel as TLS from 192.0.2.77 to the fake external relay at 198.51.100.44 on port 443.

Zeek cannot see the SSH session inside the encryption, but it can still record the outer connection:

1$ zeek-cut id.orig_h id.resp_h id.resp_p service \
2    duration conn_state local_orig local_resp < conn.log
3192.0.2.77  198.51.100.44  443  ssl  13278.000000  SF  T  F

This row uses fields from Zeek’s stock conn.log. The addresses come from the RFC 5737 TEST-NET ranges. The 13,278 second duration is a little over three hours and forty one minutes. SF means the connection was established and closed normally. With the site’s local networks configured correctly, local_orig is true and local_resp is false.

Zeek gives me facts about the connection. To call 192.0.2.77 a new source or the destination unexpected, I still need an asset inventory and a network policy. “TLS happened” tells me almost nothing. A useful alert says that an unknown OT source made a long lived connection to an external destination from a segment where that direction should not exist.

This environment had been described as air gapped. In practice, it was logical segmentation with a route that still allowed unexpected egress. A VLAN can isolate traffic by configuration, but it is not physical disconnection. If the air gap model were true, this outbound connection could not exist.

“Air gapped” turned out to mean “a VLAN with a story attached.”

That is not true of every supposed air gap, but it has been true on more than one of my assessments.

Discovery has a shape

The outer connection let me reach the box from outside the site. Passive capture gave me traffic for process discovery. When the same source moved from sitting there to active discovery, a synthetic analyst view made the pattern easier to see:

This source was not in the asset inventory, and now it was touching control services on known endpoints.

Each site has to tune timing and counts to its normal polling and maintenance behavior, including engineering work. The useful question to sak here is: why is this new source talking to these control endpoints in this direction?

Discovery showed me what the devices were and which protocols they spoke. The assessment had also established a working management path to the devices controlling the process. That is where I stopped. The rules let me demonstrate reachability, not issue a live command. That was enough for the finding.

A hypothetical step into Control would have looked like this in Zeek’s stock dnp3.log:

1$ zeek-cut id.orig_h id.resp_h id.resp_p \
2    fc_request fc_reply < dnp3.log
3192.0.2.77  192.0.2.10  20000  DIRECT_OPERATE  RESPONSE

The row says that the drop device sent a DIRECT_OPERATE request to the DNP3 outstation at 192.0.2.10. Zeek records the request, but the site’s role inventory explains why it matters: 192.0.2.77 is not an approved master. That makes the request worth immediate attention.

MITRE ATT&CK for ICS describes related behavior as Rogue Master and Unauthorized Command Message. Whatever product raises the alert, the role violation is what matters.

Two kinds of missed

There are two different meanings of “missed” in this story.

The OT network did not miss the fence. The fence never touched it. The badge and camera events belonged to physical security systems, and they were recorded without producing a useful response.

After the drop device came online, it was a different story. The new source and its external connection were on the OT wire. So was the discovery traffic. If nobody was looking for those conditions, I was still effectively invisible even though the packets were sitting there.

I cannot ask an OT sensor to see through a fence. Once I put packets on its wire, though, I think it is fair to ask why nobody noticed.

Can an LLM skip discovery?

Everything so far used old, boring tradecraft. For the bonus round, we can time travel the attack into the current AI gold rush, where every problem is being issued a chatbot whether it asked for one or not.

Marco Cook and his colleagues tested five general purpose model families against real PLCs for “With Power comes Responsibility: Attack Synthesis for Industrial Control Systems using Large Language Models”.

The models generated 1,395 scripts. The researchers advanced 646 of them to execution, and fifteen produced the expected impact. That is 2.32 percent of the executed set and 1.08 percent end to end. No script successfully attacked PLC application code or firmware.

More context did not produce a smooth increase. At the execution stage, the reported results were:

Low context still included the objective and a generic topology, so generic network attacks sometimes worked. At medium context, the models often invented tags or registers. High context supplied the application code and tag table, which gave the models real details about the testbed.

Those numbers belong to this experiment, not to every LLM or PLC. Fifteen successes is a miserable hit rate, but it is not zero. The tested models were already old by the time I gave the talk. I expect modern models to have higher success rates.

The network does not give a shit whether the script was written by a person or generated by a model. Traffic is traffic. It only helps the defender if somebody is looking.

My takeaway for the talk was that the attacks given the most target context had the highest success rate in this experiment. An attacker may leave evidence while collecting that context. Some attacks worked with less context, too. Discovery gives defenders an opportunity, but attackers do not always need it.

Monitoring is not detection

I have done too many penetration tests where I was completely invisible. Some sites had no OT monitoring at all. Other sites had sensors everywhere, but nobody looked at the output or nobody had decided which events mattered. It made no difference to me as the attacker.

Monitoring means a sensor made a record. Detection means somebody decided the record mattered and got it in front of a person in time to do something. A log nobody checks may help with the incident report later. It did nothing while I was in the network.

So what should you do with this?

• Know which devices are supposed to talk on each OT segment. Without that, a new source is just another address.
• Track direction and role, not only ports and addresses. Ask whether this source should start this kind of communication with that destination.
• Alert on a short list of violations that matter at the site. In this story, that could be a new source suddenly touching several control endpoints. Unexpected egress is another useful condition.
• Put a process affecting command from an unapproved master at the front of the line.

Do not turn this into another alert firehose. Pick a few conditions that actually matter at the site and make sure somebody is watching for them.

Define the anomaly. Put it on the glass.

References

• Richard Derbyshire, “The Challenges of Operational Technology Penetration Testing”, Digital Threats: Research and Practice 7(2), 2026.
• Marco Cook, Andrei Stoica, Awais Shah, and Dimitrios Pezaros, “With Power comes Responsibility: Attack Synthesis for Industrial Control Systems using Large Language Models”, ACM Transactions on Privacy and Security 29(3), 2026.
• Marina Krotofil, Security of Cyber Physical Systems: Process-Aware Approach, Hamburg University of Technology, 2023.
• NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, 2023.
• MITRE ATT&CK for ICS.
• Zeek conn.log documentation and dnp3.log documentation.
• RFC 5737, IPv4 Address Blocks Reserved for Documentation.