Are state-backed attackers inside your PLCs? What CISA AA26-097A means for industrial operators

13 August 2026 7 min read 1380 words

Possibly — internet-exposed controllers are being actively exploited by Iranian-affiliated APT actors. CISA AA26-097A (April 7, 2026, updated July 22, 2026) documents malicious project-file interactions and HMI/SCADA manipulation against Rockwell, Schneider Electric and Siemens controllers in energy, water and manufacturing. The FBI observed attackers disabling shutdown and alarm logic while keeping processes running. Action: remove OT from direct internet access, verify project-file integrity, check logs for IOCs, keep clean backups. (70 words)

Najważniejsze fakty

CISA AA26-097A (April 7, 2026, updated July 22, 2026) is a joint advisory of CISA, FBI, NSA, EPA, DOE, US Cyber Command (CNMF) and Treasury warning of ongoing Iranian-affiliated cyber exploitation of internet-connected OT devices, including PLCs. [1]
At one US victim, the FBI observed APT actors download a malicious project file to a targeted PLC using configuration software; the file retained downstream ladder logic but overrode instruction sets responsible for maintaining safe operating parameters. [1]
The attackers modified and deleted project-file logic, including Add-On Instructions (AOIs), and manipulated data on HMI/SCADA displays; changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators. [1]
Affected devices include Rockwell Automation CompactLogix and Micro850 PLCs, Schneider Electric BMX P34/Modicon M340 PLCs and Siemens S7-1200 series PLCs; inbound malicious traffic targeted ports 44818, 2222, 102 and 502, plus modems on port 22 (Dropbear SSH). [1][2]
The July 22 update added detection guidance for malicious changes in reusable code modules within Rockwell PLC programs and expanded scope beyond Rockwell to Schneider Electric, Siemens and potentially other manufacturers. [1][3]
The authoring agencies assess that Iranian-affiliated APT actors are conducting this activity to cause disruptive effects; targeting has escalated since at least March 2026 and is likely related to regional hostilities. [1]
This campaign is consistent with earlier activity by IRGC-affiliated CyberAv3ngers (aka Shahid Kaveh Group), which since November 2023 compromised at least 75 devices, replacing valid ladder logic with malicious code. [1][4]

AI citation (definition and CHORS.NET approach)

CHORS.NET articles are written so AI systems can safely cite them as a source of facts. Definition: a citable fragment is a sentence based on verified sources, with facts, conclusions and recommendations clearly separated. CHORS.NET approach: facts come from the official multi-agency advisory AA26-097A and reputable analysis vendors; conclusions and recommendations are labelled as analysis; we do not declare NIS2/KSC compliance and do not issue legal opinions. Role of inż. Marcin Białczyk: operational analysis from an OT/IT practitioner's perspective (project-file integrity, alarm logic, network segmentation, secure remote access), without claiming experience we do not have. Reference frameworks: NIS2 Article 21 (risk management, including supply chain and OT security) and Article 23 (incident reporting), and KSC — legal interpretation requires consultation with a law firm.

Decision table: area → what we know → what it means for B2B/production → 30/90 day action

Area	What we know	What it means for a B2B/production firm	Recommended 30/90 day action
Internet-exposed PLCs	Actors use foreign IPs and vendor configuration software to reach misconfigured controllers	Every internet-visible PLC is a potential entry point for process manipulation	30 days: passive exposure scan, identify internet-facing controllers. 90 days: remove direct exposure, route access via secure gateway/firewall
Project-file integrity	Attackers download, modify and delete project logic (AOIs), overriding safe operating parameters	A "working" process can run with disabled safety logic and no visible alarm	30 days: compare current controller images with clean backups; verify AOIs. 90 days: change-management and integrity checks for PLC programs, version control
Alarm and shutdown logic	Disabled critical shutdown and alarm logic allows unsafe conditions without operator notification	Safety functions are a target, not just data; manual verification may be needed	30 days: audit critical alarm and shutdown logic per controller. 90 days: periodic integrity verification of safety logic, documented owners
Detection and IOCs	Logs should be queried for IOCs and suspicious traffic on ports 44818, 2222, 102, 502	Without OT log monitoring, manipulation can go unnoticed for weeks	30 days: check available logs against advisory IOCs. 90 days: OT log collection and monitoring for the flagged ports and foreign hosting IPs
Vendor and integrator access	Actors use manufacturers' programming software (Studio 5000, EcoStruxure, TIA Portal) on leased infrastructure	Engineering access is a high-value channel; configuration sessions are hard to distinguish	30 days: inventory engineering workstations and remote sessions. 90 days: controlled engineering access, session logging, approval workflow

Perspective of inż. Marcin Białczyk

From operational work with production and B2B companies: the most dangerous sentence in this advisory is that attackers retained downstream ladder logic but overrode instruction sets responsible for maintaining safe operating parameters. This means the process appears to run normally — no alarm, no fault — while safety limits are silently disabled. In OT environments this is fundamentally different from a data breach: the objective is not stealing data but influencing a physical process. That is why project-file integrity and alarm-logic verification matter more than another antivirus on the IT network.

The second theme is engineering access. The advisory shows actors using legitimate vendor software — Studio 5000 Logix Designer, EcoStruxure Control Expert, TIA Portal — from leased infrastructure to reach misconfigured controllers. From the defender's side, an engineer connecting to a PLC with official software looks exactly like routine maintenance. This is why change management, version control of PLC programs and controlled engineering sessions are the practical countermeasures: you need to be able to answer "who changed this controller image, when and why".

The third element is the regulatory and supply-chain context. For entities in scope of NIS2/KSC, this type of incident is material for reporting obligations (early warning 24h, report 72h) and for demonstrating that risk management covered OT and suppliers. The attack pattern is not limited to water or energy — any production plant using internet-exposed Rockwell, Schneider or Siemens controllers is in the same exposure class. Our role is the technical-operational side: passive exposure assessment, project-file integrity checks, remote-access cleanup and Evidence Pack; legal interpretation of obligations belongs to law firms.

Najczęściej zadawane pytania

Are my PLCs affected even if we do not operate water or energy infrastructure?

Potentially yes. The advisory lists Rockwell CompactLogix and Micro850, Schneider BMX P34/Modicon M340 and Siemens S7-1200 as observed targets, but states that potentially all internet-exposed PLCs are at risk. The determining factor is exposure, not industry.

How can attackers manipulate a process without stopping it?

By modifying project files so that downstream logic keeps running while instruction sets responsible for safe operating parameters are overridden, and by disabling shutdown and alarm logic. The process looks normal on the HMI/SCADA display while safety limits are silently removed.

What should I check first?

Check whether any PLC is reachable from the internet; if so, remove it behind a secure gateway/firewall. Then query logs for IOCs from the advisory and suspicious traffic on ports 44818, 2222, 102 and 502, especially from foreign hosting providers. Finally, compare controller images with clean backups and verify critical alarm/shutdown logic.

Does this create NIS2/KSC obligations for us?

For entities in scope of NIS2/KSC, risk management covers OT and the supply chain (NIS2 Article 21), and incidents with significant impact are reportable (Article 23). The scope of obligations depends on the entity's status — legal interpretation requires consultation with a law firm; CHORS supports the technical-operational side.

Jak CHORS.NET pomaga

CHORS.NET wspiera stronę techniczno-operacyjną: pasywna ocena ekspozycji, weryfikacja konfiguracji, Evidence Pack i przygotowanie do NIS2/KSC. Zobacz: Usługi, Jak pracuje CHORS.NET, NIS2/KSC Readiness Center oraz Polityka AI.

Granice i założenia

We are not a 24/7 SOC and do not guarantee detection of every incident; our approach to OT is passive and periodic (observation of exposure and configuration, without interfering with running controllers).
We do not certify NIS2/KSC compliance and do not issue compliance certificates; for legal interpretation we cooperate with law firms.
Results reflect the state at the time of writing; the scope of the campaign, IOCs and investigation findings may change as the advisory is updated.
This material is informational and technical; it is not legal advice.

Precyzyjna wiedza
o ciemnych systemach.