PLC Cyberattacks 2026: How Iranian Hackers Exploit Legitimate Engineering Software (CISA AA26-097A)

Diagram comparing a traditional malware-based PLC attack path, which requires custom malware and an exploited vulnerability, against a living-off-the-land PLC attack path, where an attacker connects directly to an internet-exposed PLC using the plant's own legitimate engineering software with no malware or exploit involved.

A PLC living-off-the-land attack is when an intruder controls a programmable logic controller using the plant's own legitimate engineering software — Studio 5000, EcoStruxure Control Expert, TIA Portal — instead of custom malware. CISA's joint advisory AA26-097A, first issued April 7, 2026 and significantly expanded July 22, 2026, documents exactly this pattern against internet-exposed Rockwell, Schneider Electric, and Siemens PLCs. No exploit chain, no dropped binary — just a misconfigured PLC reachable from the internet and the same software your own engineers use every day. That is precisely why a clean patch cadence alone would not have stopped it.

Quick Facts

Question	Answer
What is CISA AA26-097A?	A joint advisory (initial release April 7, 2026; major update July 22, 2026) warning that Iranian-affiliated actors are accessing internet-exposed PLCs using operators' own legitimate engineering software rather than custom malware.
Which PLC models are named?	Rockwell CompactLogix and Micro850 (initial scope); Schneider Electric Modicon M340/BMX P34 and Siemens S7-1200 added in the July 2026 update.
Does patching stop this attack?	No — the campaign relies on internet exposure plus authorized engineering software, not on exploiting an unpatched CVE. One related vulnerability, CVE-2021-22681, was separately added to CISA's Known Exploited Vulnerabilities catalog.
Who is behind it?	Most consistently identified as CyberAv3ngers — the actors' own branded persona — assessed as linked to Iran's IRGC Cyber Electronic Command (reportedly its Shahid Kaveh sub-unit) and to the 2023 Unitronics water-utility compromises. The same activity is also tracked under several vendor-specific names; see "What CISA AA26-097A Actually Says" below.
What's the worst confirmed outcome so far?	At one US victim, ladder logic was reportedly modified to disable safety shutdown and alarm functions.

Where This Fits

This is a spoke of our OT Cybersecurity 101 filler, which lays out why OT security requires a different model than IT security in the first place. If you haven't read that piece yet, start there for the Purdue-model/availability-over-confidentiality context this article assumes.

It's also the direct counterpoint to Why You Can't Just Patch a PLC: OT Patch Management Explained — that spoke covers the patch-cadence side of PLC security. This one covers the attack class patch cadence doesn't touch.

What CISA AA26-097A Actually Says

The advisory has two distinct phases, and the differences between them matter for scoping your own exposure.

April 7, 2026 — initial release. CISA, alongside several other agencies, warned that Iranian-affiliated actors were scanning for and connecting to internet-exposed Rockwell Automation CompactLogix and Micro850 PLCs. The access method flagged was notable: the actors used Studio 5000 Logix Designer — Rockwell's own legitimate engineering software — rather than deploying custom malware to establish control.

July 22, 2026 — major update. CISA expanded the advisory's scope to add observed targeting of Schneider Electric BMX P34/Modicon M340 controllers (via EcoStruxure Control Expert) and Siemens S7-1200 controllers (via TIA Portal) — reported as scanning activity and inbound connection attempts on each vendor's associated protocol ports, not a confirmed device compromise at the level documented for Rockwell. The confirmed intrusion and ladder-logic manipulation described below remains specific to a Rockwell deployment; Schneider and Siemens are newly in-scope for monitoring, not confirmed victims. The update also added detection guidance for malicious changes to reusable ladder-logic code modules, and disclosed that at one confirmed US victim (the Rockwell case), the actors modified ladder logic to disable safety shutdown and alarm functions — allowing unsafe conditions to develop without alerting operators.

Issuing agencies: the advisory was originally co-authored by FBI, CISA, NSA, EPA, DOE, and US Cyber Command's Cyber National Mission Force at the April 7, 2026 release. The Department of the Treasury joined as a co-author with the July 22, 2026 update, bringing the full list to seven agencies. This agency breakdown is cross-corroborated by two independent secondary analyses (IOActive and ComplianceHub.Wiki) that separately describe the same April-vs-July agency split, rather than resting on a single secondary summary. CISA's own advisory page returned a 403 to automated fetch during research for this article — readers who need the authoritative agency list for a compliance context should still confirm directly at cisa.gov/news-events/cybersecurity-advisories/aa26-097a or a Wayback Machine snapshot.

Threat-actor naming: the actors are most consistently referred to as CyberAv3ngers — the group's own branded hacktivist persona — assessed as linked to Iran's IRGC Cyber Electronic Command, reportedly via its Shahid Kaveh sub-unit. The same or closely overlapping activity is also tracked under vendor-specific names that should not be read as a single CISA-issued alias list: Microsoft tracks related activity as Storm-0784; Mandiant/Google as UNC5691; CrowdStrike as Hydro Kitten; and Dragos as BAUXITE. PYROXENE is a separate Dragos-tracked cluster reported as pursuing OT supply-chain intrusions since 2025 — treat it as associated/overlapping reporting, not a confirmed alias of the same group. CISA's own advisory text was not independently accessible during research (see agency note above); treat CyberAv3ngers as the best-corroborated name and the vendor names as parallel taxonomies rather than a confirmed alias list from CISA itself.

To be precise about degree: Rockwell is the only vendor for which a confirmed intrusion with ladder-logic manipulation has been disclosed. Schneider Electric and Siemens are described as observed targeting — scanning activity and inbound connection attempts on their respective protocol ports — not confirmed device compromises, per corroborating secondary analysis (IOActive). Any framing that describes Schneider or Siemens PLCs as "compromised" by this campaign should be treated as imprecise language from secondary coverage rather than a confirmed outcome.

Why "Living-off-the-Land" Breaks the Patch-First Mental Model

Most PLC security guidance — including our own patch-management coverage — is built around a CVE-driven workflow: a vulnerability is disclosed, a vendor ships a fix, you schedule a maintenance window, you patch. That workflow assumes the attacker needs an exploit to get in.

This campaign doesn't need one. The actors reportedly used the engineering software vendors ship on purpose, connecting to controllers that were simply reachable from the internet. There is no CVE to patch against the access method itself, because the access method isn't a vulnerability — it's a legitimate feature being used by someone who isn't supposed to have access to it.

This is a meaningfully different attack model from the malware-based ICS attacks that get taught in most OT security training.

Aspect	Malware-based PLC attacks (Stuxnet, TRITON/Triconex)	Living-off-the-land PLC attacks (CISA AA26-097A pattern)
Payload	Custom-built malware/exploit code delivered to the target	None — no custom binary; the "payload" is a config change made with legitimate tools
Entry point	Often an air-gap-crossing vector (infected USB, engineering laptop) or a specific software vulnerability	Direct network access to an internet-exposed PLC
Tools used	Purpose-built attack frameworks	The plant's own engineering software (Studio 5000, EcoStruxure Control Expert, TIA Portal)
What a CVE scan would catch	Often yes — a specific exploited vulnerability	Often no — no vulnerability is being exploited
Primary mitigation	Patch management, USB/removable-media controls	Remove internet exposure, restrict engineering-software access, monitor for unauthorized logic changes

The practical implication: if your OT security program's PLC checklist stops at "patch cadence" and "known-vulnerability scanning," it has no control that would have caught this campaign. You need a second, separate control layer aimed at configuration exposure and authorized-tool misuse, not vulnerability exposure.

How the Campaign Actually Works: Tools, Ports, and Access

Based on the advisory and the secondary analyses covering it, the pattern reported is straightforward:

Discovery. The actors scan the internet for PLCs reachable on industrial protocol ports — reporting points to EtherNet/IP (port 44818), Modbus TCP (port 502), ISO-TSAP (port 102, used by Siemens S7 controllers), and remote-access ports including 22 and 2222.
Access. Instead of exploiting a vulnerability, the actors connect using the same engineering software an authorized technician would use — Studio 5000 Logix Designer for Rockwell controllers, EcoStruxure Control Expert for Schneider controllers, TIA Portal for Siemens controllers.
Persistence. Reporting on the campaign describes use of Dropbear SSH for maintaining access on compromised systems.
Manipulation. In the confirmed case CISA disclosed, the actors modified ladder logic — the core control program running on the PLC — specifically to disable safety shutdown and alarm functions, so unsafe process conditions could develop without triggering an operator alert.

Separately, CISA's Known Exploited Vulnerabilities (KEV) catalog added CVE-2021-22681 — an insufficiently protected credentials vulnerability affecting Rockwell's Studio 5000 Logix Designer, RSLogix 5000, and Logix Controllers — on March 5, 2026, with a federal remediation deadline of March 26, 2026 under Binding Operational Directive 22-01. That addition predates AA26-097A's April 7, 2026 initial release by about a month, and CISA has not described CVE-2021-22681 as the access method used in the confirmed AA26-097A intrusions — it's a related-but-separate patchable vulnerability in the same product family, not the primary living-off-the-land access vector this advisory documents.

What Would (and Wouldn't) Have Stopped This

Given the mechanism above, here's how the standard OT mitigation layers actually stack up against this specific attack model:

Patch management — would not have stopped it. The confirmed access method doesn't rely on an unpatched CVE. (See Why You Can't Just Patch a PLC for what patch management does cover.)
Removing internet exposure / network segmentation — this is the control CISA leads with. If the PLC was never reachable from the public internet in the first place, the entire access chain in this advisory doesn't work. This is the same design discipline covered in IEC 62443 Zones and Conduits Explained — routing any necessary remote engineering access through a secure gateway/jump host instead of exposing the PLC directly.
Asset inventory — a prerequisite, not a mitigation by itself. You cannot fix internet exposure on a PLC you don't know exists. See OT Asset Management: How to Build an Industrial Asset Inventory for the "step 0" version of this problem.
MFA and access-gateway controls on engineering software sessions — directly relevant, since the attack abuses legitimate engineering-software access rather than a software flaw. This overlaps with the remote-access guidance in Zero Trust for OT.
Logic-change monitoring / configuration-baseline detection tooling — the layer that actually catches the manipulation step (the ladder-logic edit), as opposed to preventing the access step. This is the category of tooling covered in OT Security Vendor Comparison: Dragos vs. Claroty vs. Nozomi.
Software supply-chain visibility (SBOM) — tangentially relevant here mainly through CVE-2021-22681's presence in the KEV catalog; see SBOM for Industrial Control Systems for why knowing what's actually running on a controller matters even when the primary campaign isn't CVE-driven.

Incident Response Checklist: Confirming or Ruling Out Ladder-Logic Tampering

If you're trying to determine whether your own PLCs have been affected by this campaign — or any logic-tampering incident — a vendor detection-rule pitch isn't the first move. These are the checks that come before you call in tooling:

Pull the current ladder-logic project file and diff it against your last known-good, independently stored backup — not against a vendor default template. If you don't have a verified offline backup to diff against, that gap is itself the finding.
Check engineering-workstation session logs for Studio 5000 / EcoStruxure Control Expert / TIA Portal connections outside your documented change-management windows — unexplained sessions, especially from unfamiliar source IPs or at odd hours, are the strongest early signal.
Review the PLC's own audit/event log where the platform supports one for online edits, downloads, or firmware changes that don't correspond to a logged, approved change ticket.
Check network flow logs at ports 44818 (EtherNet/IP), 502 (Modbus TCP), 102 (ISO-TSAP), 22, and 2222 for connections originating from outside your known engineering subnet — particularly any connection reaching the PLC directly from the public internet.
Verify safety-instrumented function and alarm setpoints against your documented baseline values, not just the presence of the safety code block. The confirmed AA26-097A incident involved logic that still existed but had been altered to not function as intended — a code-presence check alone would miss that.

None of these five steps require purchasing new tooling. They require having a documented baseline to compare against in the first place, which is the recurring theme across this entire cluster.

FAQ

Q: What is CISA advisory AA26-097A?
A: It's a joint cybersecurity advisory, initially released April 7, 2026 and substantially expanded July 22, 2026, warning that Iranian-affiliated threat actors are accessing internet-exposed PLCs from Rockwell, Schneider Electric, and Siemens using the operators' own legitimate engineering software rather than custom malware.

Q: Is my PLC affected by the CISA AA26-097A advisory?
A: The advisory names Rockwell CompactLogix and Micro850, Schneider Electric Modicon M340/BMX P34, and Siemens S7-1200 controllers. Being on this list doesn't automatically mean you're compromised — the relevant risk factor is whether that controller (or its engineering-access path) is reachable from the public internet, since that exposure is the actual entry point the advisory describes.

Q: Can a living-off-the-land PLC attack be stopped by patching?
A: No, not by patching alone. This campaign's confirmed access method doesn't rely on exploiting an unpatched CVE — it relies on internet-exposed PLCs and legitimate engineering software. Patch management still matters for other threats, but it isn't the control that addresses this specific attack model. Segmentation, removing internet exposure, and access-gateway controls are.

Q: Who is CyberAv3ngers and are they linked to the 2023 Unitronics attacks?
A: CyberAv3ngers is the name most consistently used across coverage of this campaign, reported as linked to Iran's IRGC and to the 2023 compromises of Unitronics PLCs at US water utilities. Other aliases circulating in vendor threat-intel reporting should be treated with caution, since they come from different companies' independent tracking systems and may not all refer to the same group with equal certainty — see the "What CISA AA26-097A Actually Says" section above.

Q: How do I check if my PLC's ladder logic has been tampered with?
A: Start by diffing the current project file against a verified, independently stored known-good backup — not a vendor template. Then check engineering-software session logs for connections outside approved change windows, review any onboard PLC audit log, check network flows on the ports this campaign uses (44818, 502, 102, 22, 2222), and verify safety/alarm setpoints against a documented baseline rather than just confirming the safety code block is present. See the full checklist above.

Sources

CISA AA26-097A — primary advisory; returned a 403 to automated fetch during research for this article. Agency-list, alias, and confirmed-vs-targeted claims above are cross-corroborated against two independent secondary analyses (IOActive, ComplianceHub.Wiki) rather than a direct read of the primary text; confirm directly or via a Wayback Machine snapshot before citing in a compliance context.
Picus Security — CISA Alert AA26-097A: Iranian-Affiliated Actors Target PLCs Across US Critical Infrastructure
IOActive — Iranian-Affiliated Actors Expand PLC Targeting to Siemens and Schneider Electric
SafeBreach — CISA AA26-097A Iranian PLC Exploitation Coverage
ComplianceHub.Wiki — CISA AA26-097A Update: Iranian PLC Targeting of Critical Infrastructure, July 2026
CISA — CISA Adds Five Known Exploited Vulnerabilities to Catalog (March 5, 2026) — primary source for the CVE-2021-22681 KEV addition date and federal remediation deadline.
CrowdStrike — Hydro Kitten Adversary Profile and Dragos — BAUXITE — vendor threat-actor taxonomy pages used to attribute individual alias names (Storm-0784/Microsoft, UNC5691/Mandiant, Hydro Kitten/CrowdStrike, BAUXITE and PYROXENE/Dragos) to their source vendors rather than presenting them as a single unified list.
Tenable — Coordinated Cyberattack on Minnesota Water Utilities — referenced for background on water-sector PLC incidents involving Iranian-affiliated actors; not confirmed to be the identical actor set or advisory tracked in AA26-097A, so treat as contextual rather than as a named example of this specific campaign.

Author Bio

Written by The Whitepaper Skeptic. In OT/smart-factory security architecture reviews for industrial clients, "how is the PLC reachable from outside the plant network" was consistently a harder question to get a straight answer to than "when was it last patched" — asset owners could usually produce a patch log, but a clean, verified inventory of every remote-access path into a controller was rarer. That gap is exactly what this advisory exploits, which is why segmentation and access-path review get more weight here than a vulnerability scan would.

Search This Blog

Beyond the Whitepaper