When Your PLC Faces the Internet

Picture a process tank on level control late in a night shift, the level creeping past its high setpoint while the board stays quiet. No annunciator lights. No horn. The transfer pump that should have staged up sits idle, because the rung watching that level and the rung driving the alarm were both quietly rewritten some weeks back. Everything else in the program runs the way it always has. The controller isn't faulted. It's executing its logic exactly as written, and someone else wrote that part.

That's close to what the FBI and CISA say they found at a U.S. victim in an advisory seven federal agencies updated this July. Attackers pushed a modified project file onto a live PLC. They kept the ladder that ran the process day to day, then added logic that overrode the instructions holding the machine inside safe operating limits. Shutdown and alarm functions went dark. Operators saw no sign anything had drifted. The advisory names water, wastewater, and energy sites as the ones hit, but the controller in that story is a close cousin of one on your floor, whatever you make. The same CompactLogix that runs a municipal lift station runs a CIP skid in a dairy, a conveyor drive in a rolling mill, a gas train on a waste-to-energy boiler.

The document carries a mouthful of a title about Iranian-affiliated actors and programmable logic controllers, and the press picked up the geopolitics. Read it from the control room and the point is narrower, and worse. Your control logic is a file. That file travels over the same engineering channel you use to commission and tune. And when the controller holding it can be reached from the open internet, rewriting your process doesn't take a clever exploit. It takes the file and a way in, and both are nearer to hand than most plants care to admit.

No exploit required

The line worth reading twice is what the advisory says it is not. It isn't reporting a new flaw in any of these controllers. No zero-day, no exotic malware, no broken cipher. The agencies are plain that this is opportunistic targeting of gear left reachable and thinly hardened. The PLCs did what they're built to do: accept an authenticated engineering session and load whatever program it hands over.

So how does a controller end up facing Tehran? Usually through a door someone opened for a sound reason and forgot to shut. A cellular router bolted onto a remote skid so the integrator could dial in during startup. A firewall rule punched through "for now" to let a vendor troubleshoot. A modem on an outlying station a small operator stood up because rolling a truck to every trip wasn't in the budget. Each made sense on the day. Stack them up and you get a controller answering on a public address, on ports every controls engineer already recognizes: 44818 for EtherNet/IP on the Rockwell side, 502 for Modbus, 102 for the S7 protocol on Siemens gear. Some of the field modems the actors used, they reached over SSH and rode in from there.

None of that reconnaissance is hard anymore. A PLC with a public address is findable from a chair: scan the ports, read the banner that names the CPU, infer the process from the tag names. What used to be the slow part of an attack has gone cheap. And the tooling wasn't custom. This campaign ran the vendors' own engineering software (Rockwell's Studio 5000 Logix Designer, Schneider's EcoStruxure Control Expert, Siemens' TIA Portal) off leased hosting abroad. The same software your integrator opens on a Tuesday morning.

There's a sting in reaching for the real engineering tools. Traffic from Studio 5000 or TIA Portal looks exactly like traffic from Studio 5000 or TIA Portal, because that's what it is. It speaks the protocol the controller expects, from software the controller trusts, over an authenticated session the controller was told to honor. A defense tuned to catch malware signatures or malformed packets sees nothing to flag. But the abnormal thing was never the how; it's the who, the when, and the where-from, a valid tool and a valid login arriving from a foreign host at an hour no engineer was on shift. Spotting that means watching for context, not contraband.

Credentials finish the job. A device still wearing its factory password, or a weak one cloned across a fleet, turns a reachable controller into an open one. This is the same actor set that, in a campaign a few years back, hit at least 75 internet-exposed controllers with operator panels and swapped the valid ladder for their own. None of the mechanics have changed since. The target list just widened, from one small-controller brand to Rockwell's CompactLogix and Micro850, Schneider's Modicon M340, Siemens' S7-1200, and, in the agencies' own words, potentially any exposed controller.

The program is a file

What the July update added is the part that should land on anyone who's ever archived a project file and filed it as a backup rather than a secret. The actors weren't only fiddling with live memory. They pulled whole project files off the controllers and out to infrastructure they owned, and studied them at leisure.

A PLC project file is the densest description of a plant that exists in one place. The ladder, the input and output map, the interlock and alarm logic, the tag names, the comments one engineer left for the next: all of it, in engineering units, annotated. Lift that file and you don't have to guess how a pasteurizer holds temperature, or which permissives a burner management system checks and in what order, or when a digester gas blower is cleared to start. It's written down. The specialist knowledge that once cost an attacker months now sits in the document you email to a systems integrator.

Pull apart the two things that access buys, because they're two different crimes. Reading the file is espionage; the attacker learns your process cold. Rewriting it is sabotage. The same open door serves both, which is why exfiltration and tampering show up in the same advisory: once the project file is theirs to copy and yours to trust, they can take their time offline, understand the plant, and hand back a version that runs but lies.

Then comes what they did inside it, the genuinely clever and genuinely unnerving bit. Modern control code is modular. On a Rockwell platform you build an Add-On Instruction, a reusable block you define once and drop into dozens of rungs across a project. (An AOI is the rough equivalent of a Function Block, or a user-defined block, on other vendors' controllers.) It's good practice. It's also a fine place to hide. Alter the logic inside a single AOI and the change rides along into every rung that calls it, quietly, a layer below where a fast scroll through the main routine ever looks. You review the ladder, it reads clean, and the tampering sits one level down in a module you trust because you wrote it last spring.

That's why the update carried specific guidance to check reusable code modules for anomalous changes: open the AOIs, not just the main ladder, and compare them against known-good. The same actors also groomed what the screens reported, editing the values shown on HMI and SCADA displays. Put the two moves together. The interlock that should trip is gutted inside a trusted block, and the number on the operator's screen is dressed to look normal while the process walks toward the edge. That's the silent board from the top of this piece, built on purpose.

The key the internet can't turn

Reach for the front panel of a CompactLogix and you'll find a small three-position keyswitch: RUN, REM, PROG. Set to RUN, the controller flatly refuses a remote program download. The refusal is enforced in hardware, and no packet can reach around it. The advisory's guidance is exactly that: keep the switch in RUN, move it to REM or PROG only for the minutes you're genuinely downloading a change, then turn it back. A physical key beats a firewall rule for one blunt reason. Nobody in another country can turn it.

There's a catch the agencies are careful to flag, and it bites the hasty. Changing modes commits whatever program is currently loaded, so validate what's on the controller before you switch to RUN. Flip to run over a file that's already tampered and you've locked the tamper in. Validate first, then commit. For controllers that manage mode in software rather than a physical switch, much of the S7 family among them, the equivalent is turning on programming protection so a remote session can't silently redefine the logic through the engineering tool.

A keyswitch doesn't cover everything, though, and treating it as a cure is how a plant talks itself into false comfort. Plenty of sites truly need remote engineering access. A change pushed through a sanctioned maintenance window strolls right past a switch that happens to sit in REM. The deeper fix the advisory keeps circling back to is dull and structural: take the controller off the public internet entirely, and put every remote session through a broker. A jump host in a screened network. Reached only after multifactor authentication, it terminates the engineer's connection and opens a separate one inward. No inbound port sitting open to the world. Cellular field links folded into a private APN instead of a raw public address. It's more moving parts than a modem and a port-forward, and it's the difference between a door and a wall with a guarded gate.

Segmentation earns its keep in the same breath. A flat control network, where one exposed device can address every other, turns a single forgotten modem into a doorway to the whole plant. Carve the network into zones with controlled conduits between them, the model the ISA/IEC 62443 series is built around, and a foothold on the outlying pump station stays on the outlying pump station instead of pivoting to the boiler controls two subnets over. It won't stop the first intrusion. It decides how far that intrusion travels, and on a plant the distance between a contained nuisance and a line down is often exactly that.

Locking, though, only helps against changes you didn't authorize. The other half is knowing what "good" even looks like, and here a lot of plants are quietly exposed. Ask for the golden copy of a controller's program and you'll often get an archive three years stale, drifted from the running logic by a dozen undocumented field edits nobody wrote down. That gap is the attacker's friend, because you can't diff against a reference you don't really have. So keep offline backups of the logic and configuration, verify a backup is clean before you ever restore from it (a compromised archive just reinfects the controller), and run the vendor's integrity tools against the live program on a schedule rather than after an incident.

Then there's the behavioral layer, where a plant already wired up for reliability holds an edge it rarely thinks to spend on security. A control network is quiet by nature. The same controllers trade the same messages with the same endpoints on the same cycle, around the clock. Against that flat baseline, a program download or a mode change is a rare and noisy event, provided someone is listening for it. The edge telemetry already trending vibration, temperature, and flow off the DIN rail sits in the right spot to catch an engineering session at an hour the shift roster says is wrong, or a management-protocol call that changes an asset's operating mode. Watching for exactly those two things is in the advisory's own list. It's an alarm a plant can build out of signals it already owns.

None of it works if the people are missing from the diagram. A great many small operators don't run their own OT at all. An integrator holds the keys and dials in when something trips, and the advisory makes a point of telling owners to check that their service providers even know an active campaign is underway. That call is worth making before an incident, not during one. The vendor who can read your controller on a Sunday is also the account most likely to be reused, over-privileged, and reachable from wherever their laptop happens to be.

Credential and service hygiene is the dull floor under all of it. The advisory's list here is almost tedious, which is rather the point: move devices off their default passwords to something long and unique per device, not one shared secret across the fleet. Switch off the authentication keys and legacy services nobody uses, too, the stray Telnet, FTP, or VNC left listening, a web server enabled on a gateway during commissioning and never turned back off. Each is a line a startup checklist could have carried and often didn't. But the device shipped working, and working felt like finished.

Run down the full set of fixes and something awkward surfaces. Disconnect the controller from the public internet. Change default passwords. Put remote access behind a gateway and multifactor authentication. Segment the network. Hold offline backups. Not one of these is new, and every engineer reading this knew all of them years ago. The advisory reads less like a dispatch about a sophisticated adversary and more like an inventory of the jobs a plant keeps deferring because the asset in question is running and nobody wants to be the one who touched it.

That deferral has its own logic, and it deserves respect even as you unwind it. Availability is the first duty of a control system, ranked by that same series of standards alongside keeping data confidential, because a process that stops the wrong way can put someone in a hospital bed. A station that "just works" is a station you don't visit. The default password nobody rotated survived because rotating it meant a site trip and a chance of a bad reconnect. The mode switch left in REM survived because REM is convenient. Every one of those small surrenders was availability quietly winning an argument, year over year. The attackers understood that better than anyone. The thing they switched off at that victim site was the shutdown logic, the safety that guards availability, and they did it so the line kept running while it drifted somewhere it shouldn't.

Which carries it back to the quiet board on nights. The controller did what it was told. Whether one of your PLCs faces the internet isn't really the hard question, because you can settle that this week: pull the asset list, scan for the open ports, hunt for the modem nobody remembers logging into. The harder one is what the dark annunciator asks. When the logic meant to protect a process gets rewritten a layer down, where the ladder still reads clean and the screen still shows green, what in your plant notices first: a person reading a trend, a tool diffing against known-good, or whoever happens to walk past the tank as it goes over?

Notes

This is a news post anchored to advisory AA26-097A, which the FBI, CISA, and five other federal agencies updated on 22 July 2026; the specifics on internet-exposed controllers, project-file exfiltration, the Add-On Instruction guidance, and the mode-switch caveat all come from that document, linked above. Where the argument holds is a plant with real OT reachable beyond its own fence line. A genuinely air-gapped line, or a small flat network with no remote path at all, has a different first problem, and it isn't this one. The controllers, ports, and tools named here are the ones the advisory calls out, not a claim about what sits on any particular site. And a keyswitch in RUN is a guard, not a guarantee: it does nothing against a change pushed through a legitimate window, which is why the watching matters as much as the locking.