Carefully read yesterday’s joint advisory on Iranian-Affiliated cyber actors exploiting PLCs from CISA, FBI, NSA, DOE, EPA, and Cyber Command, because there's a detail in the technical summary that deserves more attention than the headline will give it.
The Iranian-affiliated cyber actors targeting Rockwell Automation PLCs across U.S. critical infrastructure didn't exploit a vulnerability. They didn't need one. They used legitimate vendor engineering software, connected to internet-exposed PLCs. No public CVEs, novel techniques or zero-days. They used the tool the way it was designed to be used.
I've been in this industry long enough to remember arguing about whether ICS environments would ever really be targeted at scale. We're well past that debate. But this campaign, which traces back as early as January 2025, represents something worth thinking through carefully: what happens when the attack surface isn't a vulnerability, but an abused feature?
Key Takeaways: CISA Cybersecurity Advisory AA26-097A
- No exploit was required. When OT/ICS devices are left internet-accessible, attackers don't need a vulnerability — they use the same legitimate tools and protocols that engineers use every day.
- Disconnecting from the internet is the right response. But, if this is not technically or operationally possible, implement some level of security controls, such as IP filtering or monitoring.
- Understand your attack surface - if you don't know your exposure, you can't protect your organization. Don't assume that this is only the OT/ICS devices that you or your team have installed.
How Attackers Exploited Legitimate PLC Access
The threat actors here are assessed to be affiliated with Iran's Islamic Revolutionary Guard Corps (IRGC), but any adversary could exploit this. They accessed CompactLogix and Micro850 devices using Rockwell Automation's Studio 5000 Logix Designer. On the wire, the traffic looks like a remote engineering session. Because that's exactly what it was. The difference is who was sitting at the keyboard. Once in, they manipulated the ladder logic and device configuration.
This isn't a product problem, or a Rockwell Automation problem. Rockwell Automation has been proactive on exactly this issue - publishing hardening guidance, issuing customer advisories, working with the authoring agencies on this alert. The deeper issue predates any single platform. ICS equipment across the industry was designed under a reasonable assumption: if someone has the engineering software and the network path to your PLC, they're authorized to be there. That made sense when these networks were isolated. It doesn't hold anymore, and that's an industry-wide problem, not a product defect. Any access to industrial automation introduces risk, and this reality is not just limited to Rockwell Automation or any other ICS OEM. The bottom line is that these controllers should not be accessible to anyone but authorized users.
Why "Just Disconnect It" Isn't Enough for OT Security
The advisory's primary mitigation is to remove PLCs from direct internet exposure. That's correct - do it where you can. But anyone who has actually worked with water utilities, energy operators, or municipal infrastructure knows that "just disconnect it" glosses over operational realities. There are remote pump stations nobody can drive to at 2 a.m. There are distributed generation assets spread across a region. Remote access didn't get into OT environments because people were lazy - it got there because operations demanded it, and often the alternative was leaving a site unmanaged.
So the harder question isn't whether to close that exposure over time. It's what you do right now, before that work is complete. If someone established an engineering session to one of your PLCs from an overseas IP, outside your normal change windows, and quietly pulled the project file, would any alarm have fired? Would anyone have seen it?
That's the gap this advisory is actually about.
How to Detect Unauthorized PLC Access in OT Environments
Look at the ATT&CK mapping in the advisory:
- T0883 - Internet Accessible Device - is the initial access technique. No exploitation required.
- T1565 - Stored Data Manipulation - is the impact.
- C2 runs across ports that are standard OT protocol territory: 44818 and 2222 for EtherNet/IP, 502 for Modbus, 22 for SSH via Dropbear, and 102.
That last one is worth pausing on. Port 102 is Siemens S7. The advisory notes these actors "may also be targeting devices manufactured by companies other than Rockwell Automation." That's not a throwaway line. If you're running Siemens, Schneider Electric, or other exposed OT devices, these IOCs belong in your hunt just as much as they do in any Rockwell Automation or Allen-Bradley shop.
Detecting this kind of activity doesn't require predicting an attacker's IP address in advance. It requires knowing your environment well enough to recognize what doesn't belong. Which workstations normally initiate engineering sessions? During which hours? To which devices? What does a project file read look like when it's an authorized maintenance task versus someone just grabbing the ladder logic? These are answerable questions - but only if you have protocol-level visibility into OT network traffic and have done the work to know your attack surface.
Most of the affected organizations don’t have a holistic view either because they are unaware of the risk or don't understand it. That's the honest assessment.
Immediate Steps to Protect Internet-Exposed PLCs
I recommend re-reading the full advisory. The mitigation guidance is solid. A few things to prioritize in the near term:
- Remove internet accessible devices where possible. Implement security where it’s not possible. This can start as simply as putting IP filters on your cell modems for example, limiting them to only what is needed for operations and engineering. Check Shodan to ensure you’re not on the radar, publicly.
- Pull logs and check for traffic involving the IOC IP addresses, focusing on ports 44818, 2222, 102, 22, and 502 - and pay attention to where that traffic is coming from geographically. For Rockwell Automation controllers – or frankly, any controllers – that have a physical mode switch, put it in run position now to block remote modification while you assess your exposure. Map which of your PLCs have any form of internet reachability, direct or indirect through a jump host, and build a remediation sequence as soon as resources allow – or sooner.
- On the infrastructure side, remote access to OT devices should run through authenticated gateways with MFA enforced, and workstation-level controls should restrict which machines can initiate programming sessions to which devices. PLCs need to be in defined patch cycles with maintenance windows. None of this is new guidance - but this advisory is a useful forcing function to find out how much of it is actually implemented versus just documented somewhere.
- One more thing worth putting on the list: pay attention to the geopolitical environment. The authoring agencies explicitly assess this escalation as tied to rising tensions between Iran, the U.S., and Israel. That correlation isn't new - Iranian-affiliated OT activity has tracked with periods of kinetic escalation consistently over the past several years. That doesn't mean your threat level should spike with every news cycle, but when the regional picture gets more volatile, it's a reasonable prompt to re-verify your exposure, refresh your IOC hunts, and confirm your monitoring coverage is actually running the way you think it is. In critical infrastructure, geopolitical context is a legitimate input to threat posture.
The campaign described in this advisory isn't technically sophisticated. The actors found PLCs reachable from the internet, used the vendor's own tools to connect, and altered what operators could see on their screens. The reason it worked is that there was nothing in place to see it happen or stop the access.
That problem is fixable. But fixing it starts with being honest about where the visibility actually ends.
