Iranian-affiliated PLC exploitation exposes OT identity gaps

At a glance

What this is: SafeBreach’s analysis maps an Iranian-affiliated PLC exploitation campaign to OT access, project-file theft, and HMI or SCADA manipulation that can disable safety logic.

Why it matters: It matters because OT teams must govern remote access, engineering trust, and segmentation together, while identity teams should recognise that privileged access can extend into physical process impact.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read SafeBreach's analysis of Iranian-affiliated PLC exploitation and OT manipulation

Context

Programmable logic controllers become a security problem when they are reachable from the public Internet and treated like ordinary managed assets rather than constrained operational systems. This article focuses on PLC exploitation in OT environments, where identity, remote access, and segmentation controls determine whether legitimate engineering tools can be turned into attack paths.

The identity angle is real even in an OT story: configuration software, jump hosts, VPNs, modems, and privileged engineering accounts all become part of the control surface. When those access paths are weak, the issue is not only device compromise but governance failure across the human and non-human identities that can alter process logic.

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: How do security teams know whether PLC controls are actually working?

A: They need more than perimeter alerts. Effective validation includes checking whether remote sessions traverse a gateway, whether project files match a known-good baseline, whether HMI values align with independent process readings, and whether unexpected services appear on modems or OT endpoints.

Q: Who is accountable when remote OT access can alter shutdown logic?

A: Accountability sits across operations, engineering, and security, because the control path is part of safety architecture. Organisations should assign explicit ownership for remote access mediation, engineering account governance, and change approval. Frameworks such as MITRE ATT&CK for ICS and NIST CSF help structure that responsibility.

Technical breakdown

Internet-exposed PLCs as an attack surface

An Internet-exposed PLC is reachable from outside the plant or control network, which turns a specialised industrial controller into a remotely testable target. In this campaign, attackers did not need a zero-day exploit to start. They used open management paths, commonly used OT ports, and trusted configuration workflows to interact with controllers. That matters because PLC security depends on network placement, protocol filtering, and authenticated mediation, not just device hardening. Once exposure exists, reconnaissance becomes operational access, especially when the same ports and tools are used for legitimate maintenance.

Practical implication: remove direct Internet exposure and force all PLC access through segmented, authenticated control paths.

Legitimate engineering tools and project-file abuse

OT attackers often prefer legitimate configuration software because it blends into normal maintenance activity. In this case, the campaign used vendor engineering tools to connect to exposed controllers, then exfiltrated project files and modified logic objects such as Add-On Instructions. That is a form of trusted-tool abuse: the attacker is not inventing a new path, but hijacking the same lifecycle engineers use to upload, review, and deploy control logic. The security gap is governance over who can open, alter, and commit those files, plus whether baselines and integrity checks exist before changes reach production.

Practical implication: protect PLC project files with integrity checks, baseline comparison, and strict engineering account control.

HMI and SCADA manipulation hides unsafe changes

HMI and SCADA systems present process data to operators, so tampering there can conceal what the controller is actually doing. The advisory describes changes that disabled shutdown and alarm logic while also manipulating displayed values. That creates a dangerous split between ground truth and operator view. In OT terms, the attacker is not just modifying data. They are degrading the feedback loop that should alert staff to abnormal conditions. Detection therefore has to compare display values with independent process readings and monitor for unapproved changes to control logic and screen objects.

Practical implication: validate HMI and SCADA telemetry against independent sources and alert on display-to-process mismatches.

Threat narrative

Attacker objective: The attacker objective is to gain covert control over industrial process logic while hiding the change from operators and defenders.

1. Entry begins with Internet-reachable PLCs and modems that accept remote connections over common OT ports or SSH.
2. Escalation follows when attackers use legitimate engineering software or persistent modem access to retrieve project files and alter controller logic.
3. Impact occurs when modified logic and manipulated HMI or SCADA displays disable alarms and shutdown functions, creating unsafe operational conditions.

NHI Mgmt Group analysis

Exposed OT access is the real failure mode, not the PLC brand. The article shows that the adversary adapted across Rockwell, Schneider Electric, and Siemens environments because the common weakness was exposure, not a single vendor defect. That means governance must centre on where remote access terminates, how it is authenticated, and whether control traffic is confined to approved engineering paths. Practitioners should treat network exposure as the first identity failure in OT.

Trusted engineering software becomes a high-risk credentialed channel when lifecycle controls are weak. Legitimate PLC tooling gives attackers a powerful disguise because authorised maintenance workflows already expect file transfer, logic editing, and controller updates. The governance gap here is the assumption that “legitimate tool” equals “legitimate change”. In reality, the change authority needs the same scrutiny as privileged access in IT. Practitioners should align OT change control with privileged session governance and baseline verification.

Display manipulation creates an operator trust gap that standard logging will miss. The campaign’s value lies in hiding unsafe logic changes behind apparently normal HMI or SCADA output. That means process integrity cannot be judged only by device logs or perimeter alerts. Display-to-process divergence: a control failure where what operators see no longer matches what the controller is executing. Practitioners should build detection around independent validation, not just event collection.

OT security is converging with identity governance because access, not code alone, determines blast radius. Secure remote gateways, MFA, jump hosts, and approval-bound engineering sessions are now part of industrial safety architecture, not optional IT overlays. This also means the OT programme needs explicit ownership for non-human and human access paths that can alter logic. Practitioners should fold PLC reachability, engineering credentials, and modem access into identity risk reviews.

This advisory validates a shift from endpoint-centric thinking to control-path governance. In OT environments, the dangerous path is often the path that can write project files, not the path that drops malware. Frameworks such as MITRE ATT&CK for ICS and NIST CSF help organise this, but the practical insight is simpler: if an identity or tool can change controller logic, it belongs in the highest-risk access tier. Practitioners should prioritise those paths first.

What this signals

OT programmes should treat remote engineering paths as privileged access lanes, because the line between legitimate maintenance and adversary control is now too thin to ignore. The practical next step is to fold PLC reachability, modem access, and engineering credentials into identity and segmentation reviews, not leave them in separate operational silos.

Control-path governance: the decisive question is whether a path can alter logic, not whether it can reach a device. That shift matters for attack-path analysis, privileged session monitoring, and change control, and it aligns naturally with the governance lens in MITRE ATT&CK Enterprise Matrix and OT-specific defensive planning.

For identity teams, this is another reminder that machine and human access are part of the same blast radius once a controller is reachable. The programme signal is to prioritise gateways, MFA, jump hosts, and baselined change verification for any path that can touch process logic.

For practitioners

• Remove direct Internet exposure from PLCs Place all controllers behind segmented OT networks and deny inbound access from public addresses. If remote engineering is required, route it through a secure gateway or jump host that authenticates, logs, and mediates every session.
• Lock down engineering change authority Restrict PLC project-file access to named engineering accounts and require integrity checks before any upload or commit. Compare running logic and Add-On Instructions against known-good baselines before changes reach production.
• Validate display integrity against process truth Correlate HMI and SCADA values with independent process readings and alarm sources. Alert when operator displays diverge from ground truth, especially after remote sessions or controller updates.
• Hunt for unapproved modem and SSH access Review modems, engineering workstations, and connected OT endpoints for unrecognised SSH services, persistent remote-access tooling, and unusual sessions over ports 22, 102, 502, 2222, and 44818.
• Test C2 blocking and egress controls Use advisory-linked simulations and packet inspection to verify that outbound HTTP and ICMP traffic to threat infrastructure is detected and blocked before it can support exfiltration or remote control.

Key takeaways

• The article shows a control-path problem in OT, where Internet exposure and trusted engineering tools let attackers reach PLC logic without exploiting a single patchable flaw.
• The impact is operational, not theoretical: modified project files and manipulated HMI or SCADA views can disable alarms and shutdown functions while hiding the change from operators.
• The most relevant prevention is governance over access paths, engineering authority, and display integrity, backed by segmentation, MFA, baselines, and independent validation.

Key terms

• Programmable Logic Controller: A Programmable Logic Controller is an industrial device that executes control logic for machinery and processes. PLCs are often trusted to run continuously, so unauthorized access can alter physical behaviour quickly. In modern SCADA governance, PLC access must be tightly scoped and traceable.
• Human-Machine Interface: A Human-Machine Interface is the screen or console operators use to observe and control industrial systems. In SCADA, the HMI is often the first identity checkpoint for production actions, which makes shared accounts, weak authentication, and poor logging especially dangerous for accountability.
• Project File: A project file stores controller logic, configuration, and operational settings for industrial equipment. If an attacker can copy or alter it, they can change how a PLC behaves, preserve malicious edits, or move changes between environments without using obvious malware.
• Control-Path Governance: Control-path governance is the discipline of securing every route that can change operational behaviour, including engineering workstations, jump hosts, modem access, and remote sessions. It focuses on who can modify logic, how changes are authorised, and whether those paths are continuously verified.

What's in the full article

SafeBreach's full post covers the operational detail this post intentionally leaves for the source:

• IOC-based simulation IDs 11750 and 11751 that test whether controls detect and block campaign-linked C2 communication.
• Step-by-step use of the SafeBreach Scenarios page, Attack Playbook, and Known Attack Series report for AA26-097A.
• Mitigation guidance for OT gateways, firewall rules, modem security, and offline backups drawn from the CISA advisory.
• Specific validation points for checking Dropbear SSH, project-file changes, and HMI or SCADA manipulation.

👉 The full SafeBreach post covers the attack chain, simulation coverage, and OT mitigation details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management through a practitioner lens. It helps security and identity teams build the governance habits needed to control privileged access across modern programmes.