- › A federal advisory this month described AI-written tooling giving read and write access to Siemens S7 memory, configuration, and ladder logic over the S7comm protocol.
- › Write access to logic means the process changes and the display keeps agreeing, because the display renders what the controller reports rather than what the equipment is doing.
- › Your operators are trained to trust the screen, which is correct almost always and wrong exactly when it matters.
- › The independent read is the control: an instrument on a separate path, a person with eyes on the equipment, or a physical measurement nobody can write to.
- › Recovery is the part nobody times, because restoring a controller is fast and proving the logic on it is the one you intended is not.
Every process operator I have worked around has the same relationship with their screen. It is the instrument. Twenty years of shift work builds a genuine skill at reading it, spotting the value that drifted, noticing the trend that started an hour ago, and that skill is real and hard-won.
It also rests on an assumption nobody ever wrote down, which is that the screen reports the plant. The screen reports the controller, and on an ordinary day those are the same statement. This month produced a federal advisory describing tooling that makes them different.
What the Advisory Actually Described
On August 19 the NSA, CISA, FBI, Department of Energy, and Environmental Protection Agency issued a joint warning that actors are using AI to write Python exploitation scripts against Siemens S7 controllers, built around the snap7 libraries and communicating over the S7comm protocol. The tools give read and write access to programmable logic controller memory, configuration data, and ladder logic programs, and they are packaged to look like legitimate operational technology monitoring software. The targeted families run S7-200 through S7-1500, and the sectors named are critical manufacturing, energy, water and wastewater, chemical, food and agriculture, commercial facilities, and the defense industrial base.
Read access tells an attacker what your plant does. Write access to ladder logic lets them change what it does, and the second capability is the one that changes your incident response rather than your patching schedule.
Why the Display Keeps Agreeing
Walk the data path for a moment, because the answer is in the architecture rather than in anything exotic. Your human machine interface polls the controller and renders what comes back. A tag on the screen maps to an address in controller memory, and the number displayed is whatever occupies that address when the poll lands. The interface has no independent knowledge of the valve, the pump, or the tank. It has never measured anything.
So an attacker with write access has two straightforward options. They can change the logic driving the equipment while leaving the reported values alone, or they can change the values written to the addresses the interface reads. Either way the operator sees a plant behaving normally, because the thing generating the picture is the thing that was compromised.
This is not novel and it is not theoretical. It is the technique behind the most studied industrial attack in the field’s history, where the centrifuges were destroyed while the monitoring showed nominal operation. What changed this month is the cost of building the tooling to do it.
The Question Your Plan Does Not Answer
Pull your operational technology incident response plan and look for the step where somebody confirms plant state. In most plans that step is implicit, because it never needed to be written, and the operator looks at the screen and reports what they see, the incident commander works from that report, and the whole response is built on a reading nobody thought to question.
Now suppose the screen is part of the compromise. Every decision downstream inherits a number somebody else chose, and the more competent your response team is, the faster they will act on it.
The uncomfortable version of that question is this. If your interface showed you a completely normal plant right now, what independent evidence could you gather in the next thirty minutes to confirm it, and who would you have to call to get it?
Building the Independent Read
The defense here is not a product, it is a second source of truth that the attacker’s access does not reach. Four of them are available to almost every plant, and none of them require you to buy anything.
Put a human where the equipment is
The oldest control in the industry and still the strongest. A person standing at the pump can hear it, feel the vibration, read the local mechanical gauge, and see whether the discharge is flowing. None of that traverses the network.
Write it into the plan as a named step rather than assuming somebody will think of it, because at three in the morning during an incident nobody thinks of it.
Keep instruments that report on a separate path
Local mechanical gauges, chart recorders, and instruments that report to a historian on a different network segment give you a reading the compromised path cannot rewrite. Many plants already have these and have stopped looking at them, because the digital version is easier and lives on the desk.
Know which of your measurements have a second source, and more importantly know which ones do not, because the ones with a single path are the ones an attacker only has to lie about once.
Reconcile against physical reality
The best independent checks are the ones arithmetic will not let you fake, and they are the ordinary ones: tank levels against pumped volumes, energy consumed against work reportedly done, material in against material out over a shift.
If the flow meter says the pump moved 400 cubic metres and the tank level says it moved 40, one of those is lying and you now have a place to start. An attacker who wants to defeat this has to falsify several independent systems consistently, which is a much harder job than changing one number.
Baseline the logic and check it
Take a known-good copy of the ladder logic on your critical controllers, store it somewhere the control network cannot reach, and compare periodically. Many platforms will do the comparison for you.
This is the control that turns a four-day recovery into a shorter one, because the hard part of restoring a controller was never the restore. It was establishing that what you restored is what you meant.
The Recovery Nobody Has Timed
Reporting this week put a UK power plant offline for four days in July, attributed by The Telegraph to Iranian actors, with the facility unnamed and no official confirmation. Take the four days rather than the attribution, because the duration is the part that holds regardless of who was responsible.
Four days is not a restart. Four days is people rebuilding a control system and then satisfying themselves that the logic running on it is the logic they intended, without being certain what was changed or when. That second half is where the time goes, and it is the part no tabletop exercise ever includes.
The practical test costs you an afternoon. Take one critical controller, assume its logic was modified at an unknown point in the last ninety days, and walk through what you would do. Most operators discover they have no baseline, no confident restore point, and no way to date the change, which is the finding.
For the surrounding material, our guide to operational technology security covers the programme, the ICS primer covers the fundamentals, and exposed PLCs where the attack was setting a password covers how these devices get reached in the first place. The network half sits in network security when there is no perimeter, and the advisory’s own first mitigation remains blocking internet access to the controllers.
Ask One Operator One Question
Find somebody who runs a shift and ask them how they would know the screen was wrong. The good ones will not reach for a procedure, they will tell you about a pump that sounds different, a valve that always sticks, a reading that never sits quite where the display claims.
That knowledge is your independent read, it lives in people rather than in systems, and no part of your programme currently records it, so write it down while they are still there to tell you.
Want to know what your plant could prove if the screen were lying? Contact Grab The Axe for an operational technology assessment, or start with our free Human Attack Surface Score.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →