Iranian-affiliated PLC exploitation exposes OT identity gaps

At a glance

What this is: SafeBreach’s analysis of CISA Advisory AA26-097A shows Iranian-affiliated actors exploiting exposed PLCs, stealing project files, and altering HMI and SCADA logic to disable safety functions.

Why it matters: OT teams need to treat PLC reachability, engineering-tool access, and display integrity as identity and trust problems, not just asset-hygiene issues, because exposed control paths can become operational control.

Context

Programmable logic controllers become dangerous when their management interfaces are reachable from the Internet and their engineering tools can connect without strong trust gating. In that state, the problem is not simply one of patching a device but of controlling who or what can issue authoritative commands to industrial logic.

This campaign sits at the intersection of OT security and identity governance because the attacker is abusing legitimate engineering access patterns, not only malware. When configuration software, modem access, and control-plane reachability are not tightly bound to approved operators and networks, the boundary between maintenance and manipulation collapses.

Key questions

Q: What breaks when PLCs are exposed directly to the Internet?

A: Direct exposure removes the safety margin that OT segmentation is supposed to provide. Attackers can probe controllers, identify common ports, and interact with engineering interfaces without first compromising an internal foothold. Once that happens, remote access, project-file theft, and logic manipulation become much easier to automate and hide.

Q: Why do legitimate engineering tools increase OT compromise risk?

A: Legitimate tools carry built-in trust. When attackers use the same software engineers use for normal maintenance, activity can look like routine administration unless access is tightly bound to approved hosts, accounts, and change windows. The risk is highest when project files, controller uploads, and operator displays are all mutable from one path.

Q: What are the signs that HMI or SCADA data may be manipulated?

A: Look for a mismatch between operator displays and independent process readings, especially when alarms, shutdown logic, or set points do not behave as expected. Unexpected changes in PLC project files, unusual remote engineering sessions, and unrecognised modem or SSH activity are also strong indicators that the display layer may no longer be trustworthy.

Q: When should organisations route PLC access through jump hosts and secure gateways?

A: They should do it whenever a controller can be reached from outside a tightly controlled OT zone. A jump host or secure gateway is the right pattern when remote maintenance, vendor support, or cross-site engineering is required, because it lets teams mediate, log, and authorise access without exposing the PLC directly.

Technical breakdown

Internet-exposed PLCs and OT control-plane exposure

An Internet-exposed PLC is reachable by external traffic on industrial protocols such as EtherNet/IP, Modbus TCP, or Siemens S7, which means the device is accepting operational commands across a boundary that was never meant to be public. In this campaign, the exposure mattered because the actors could connect directly to controllers and related modems instead of needing to compromise a deeper internal foothold first. Once that reachability exists, the rest of the attack becomes a matter of exploiting trust in the control plane rather than exploiting a classic software flaw.

Practical implication: remove direct Internet exposure from PLCs and mediate all engineering access through a controlled gateway or jump host.

Legitimate engineering tools as an access path

The campaign used normal OT engineering software to interact with controllers, which makes malicious activity look operationally familiar unless access is tightly governed. This is a governance problem as much as a detection problem: if the environment cannot distinguish an approved engineer session from an adversary using the same tooling from an unauthorized source, then the tool itself becomes part of the attack path. That is why authentication, source validation, and network-level authorization matter more than simply identifying the software name on the wire.

Practical implication: restrict PLC programming and maintenance tools to approved workstations, identities, and network paths.

Project file exfiltration and HMI or SCADA manipulation

Project files contain the logic and configuration that define how a PLC behaves, so stealing them gives an attacker a blueprint for subsequent tampering. Once those files are modified, the changes can be pushed back into operational environments and reflected in HMI or SCADA displays, creating a dangerous split between what operators see and what the process is actually doing. In this advisory, that split included disabling shutdown and alarm logic, which turns a visibility issue into a physical safety issue.

Practical implication: baseline project files, verify logic integrity, and compare HMI or SCADA readings against independent process data before restoring or trusting them.

Threat narrative

Attacker objective: The objective is to gain unsafe operational control of PLCs while masking the manipulation from operators and preserving persistence for repeated access.

1. Entry occurred through Internet-accessible PLCs and associated modem interfaces that were reachable from foreign-based infrastructure.
2. Credential and tool abuse followed when the actors used legitimate OT engineering software and, in at least one case, Dropbear SSH for persistent remote access.
3. Escalation and impact occurred when project files were exfiltrated, modified, and redeployed, while HMI and SCADA displays were manipulated to hide changes and disable shutdown and alarm logic.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OT identity gaps are now a control-plane risk, not a niche access issue. This campaign shows that the identity question in OT is not just who logs into an engineering console but what authority a session acquires once it reaches a PLC. When legitimate tools and exposed devices are combined, authorization becomes inseparable from network placement and device hardening. Practitioners should treat PLC reachability as an identity boundary, not a routing detail.

Exposed engineering trust is the named failure mode here. The article shows a specific governance assumption that failed: that PLC access would remain inside a trusted operational enclave. Once Internet-facing exposure and vendor tool compatibility are both present, adversaries can move from reconnaissance to control manipulation without needing novel malware. Practitioners should focus on eliminating externally reachable trust paths, not on assuming detection will compensate later.

Display integrity is part of OT governance. The manipulation of HMI and SCADA data matters because operators make safety decisions based on what those interfaces report. If the display layer can be altered independently of process state, then human oversight is being used as a false control. Practitioners should validate that monitoring, alarm, and shutdown logic are verified against authoritative process data rather than trusted by default.

Project-file integrity deserves the same attention as credential integrity. In OT environments, a PLC project file is effectively the configuration identity of the controller because it defines behaviour, not just settings. If that file can be stolen, altered, and redeployed, the attacker has moved from access to governance of the process itself. Practitioners should manage project files as high-value operational assets with strict provenance and change control.

Campaign expansion across vendors signals opportunistic OT targeting. The shift from one PLC family to multiple vendors suggests the actors are optimising for exposure and reachability, not for a single product weakness. That pattern should push asset owners to inventory exposed control paths across the whole environment, because the real risk sits in how devices are deployed and accessed. Practitioners should reassess segmentation and remote-access design across all OT platforms, not only the ones named in the advisory.

What this signals

OT reachability is the governance problem hiding inside many PLC incidents. The campaign shows that once controllers and modems sit on public-facing paths, the security question shifts from patch status to trust boundary design. For practitioners, the priority is to map every route by which engineering control can be reached and close the ones that were never meant to be public.

Project-file integrity is becoming a first-class operational control. In industrial environments, logic files are not just configuration artefacts, they are the behavioural identity of the PLC. That makes file provenance, baseline comparison, and restore validation central to safe recovery after suspected tampering.

Display-layer deception creates a dangerous false sense of control. If HMI or SCADA values can be altered while the underlying process changes remain hidden, operators lose the ability to trust what they see. Security teams should therefore validate monitoring against independent process sources and not assume the interface itself is a reliable source of truth.

For practitioners

• Remove direct Internet exposure from PLCs Place controllers behind segmented networks and ensure all maintenance access traverses a jump host or secure gateway that enforces authentication, logging, and source control.
• Restrict engineering tools to approved sessions Limit PLC programming software to authorised workstations and identities, then verify that remote access originates only from vetted management paths and approved operators.
• Validate project-file integrity before restoration Compare current PLC project files and Add-On Instructions against known-good baselines before pushing changes or restoring backups, and treat any mismatch as a compromise signal.
• Monitor OT ports and modem services for abuse Review logs for suspicious traffic on 44818, 2222, 102, 502, and 22, then investigate unrecognised SSH services, foreign hosting providers, and modem-originated access.
• Test detection against the advisory IOCs Use IOC-based simulations and threat-hunting queries to confirm that egress controls, alerting, and response workflows detect communication with known campaign infrastructure.

Key takeaways

• This campaign exposes a governance failure in OT environments where reachable PLCs, trusted engineering tools, and weak segmentation combine to give attackers unsafe operational authority.
• The advisory shows that the issue is not limited to one vendor or one exploit path, because the actors used standard OT protocols, remote-access tooling, and display manipulation to widen impact.
• Practitioners should focus on removing direct exposure, controlling engineering sessions, and validating project-file and display integrity because those controls determine whether access can become process manipulation.

Key terms

• Programmable Logic Controller Exposure: The condition where a PLC is reachable from untrusted networks, including the Internet, instead of being isolated inside a controlled industrial segment. Exposure matters because it turns an operational controller into a remotely reachable trust target, widening the attack surface and making access governance a safety issue.
• HMI and SCADA Manipulation: The alteration of operator-facing displays or supervisory data so that the interface no longer reflects the true state of the industrial process. In OT incidents, this breaks human trust in the control environment and can hide unsafe conditions, delayed alarms, or tampered shutdown logic.
• Engineering Trust Boundary: The set of technical and procedural controls that determines who may use OT engineering tools, from where, and against which devices. When that boundary is weak, legitimate configuration software can become an attacker vehicle for unauthorized changes, file theft, or process manipulation.
• Project File Integrity: The assurance that PLC project files, logic blocks, and configuration artefacts have not been altered, replaced, or tampered with outside approved change control. In OT security, project files define controller behaviour, so their integrity is as important as the device’s own authentication and network protections.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.