Cloud Security Wire
AWS Azure GCP RSS
AWSAzureGCP Hardening Guide critical

Iranian APT Targets Internet-Exposed Rockwell PLCs: Cloud and OT/IT Boundary Hardening

CISA Advisory AA26-097A documented Iranian-affiliated threat actors targeting internet-exposed Rockwell Automation Allen-Bradley PLCs using EtherNet/IP. With 5,219 PLCs exposed globally and 74.6% in the US, the campaign demonstrates the attack path from cloud-connected IT to operational technology — and where cloud security controls can stop it.

By Editorial Team · ·
#ICS#OT#Rockwell Automation#Allen-Bradley#EtherNet/IP#Iranian APT#PLC#CISA#AA26-097A#OT security#cloud#IT/OT boundary#2026
Critical Severity

This issue has been assessed as critical severity. Review affected configurations immediately.

CISA Advisory AA26-097A, published in March 2026, documented a campaign by Iranian-affiliated threat actors against internet-exposed Rockwell Automation Allen-Bradley programmable logic controllers. The attack vector was EtherNet/IP, Rockwell’s industrial Ethernet protocol, accessible directly on port 44818 from the public internet. The threat actors used legitimate Rockwell Studio 5000 engineering software to connect to exposed PLCs, modify project files, and alter the process control logic displayed to operators.

The most insidious element was not the initial access. It was the manipulation. The modified PLC project files changed the values shown on HMI screens while altering the actual process control commands. Operators could see readings that indicated normal operation while the underlying physical process was behaving differently.

This article focuses on the cloud security angle: how internet-accessible OT systems end up connected through cloud infrastructure, where the attack surface actually sits, and what cloud-side controls can reduce exposure.

How Exposure Happens

Many organisations believe their PLCs and SCADA systems are air-gapped or isolated. In practice, cloud integration has created new connectivity paths that are not always intentional or documented.

Cloud historians and remote monitoring: Industrial operators increasingly push operational data to cloud platforms (AWS IoT, Azure IoT Hub, GCP IoT Core, or SaaS industrial analytics platforms). The data path from the PLC to the cloud runs through an OT gateway or historian. If that gateway has direct internet connectivity and insufficient segmentation, the path is bidirectional: the cloud can reach the PLC.

Remote access solutions: Technicians and OEM vendors need remote access to PLCs for maintenance. Many deployments use commercial VPN appliances or RDP/VNC servers on OT network segments, connected to the internet for remote access. If these are misconfigured, they expose the OT network to the same internet that cloud services use.

Cloud jumpboxes: Some organisations set up EC2 or Azure VM instances as jumpboxes for accessing OT networks, connected to both the public internet and a VPN into the plant network. A compromised jumpbox provides direct OT network access.

Shodan and similar internet scanning tools have consistently identified over 5,000 internet-reachable EtherNet/IP endpoints. The CISA advisory confirmed active Iranian exploitation of this exposure. The attack did not require defeating any industrial protocol security, because there was none: stock EtherNet/IP without authentication, directly reachable.

The IT/OT Boundary Problem in Cloud Architectures

Cloud connectivity changes the traditional Purdue model assumption that OT networks are isolated below the enterprise IT layer. When PLCs send telemetry to an AWS IoT Core instance and receive configuration parameters back from a cloud management portal, there is a data path between the cloud and the field device. That path needs to be protected at the cloud side as well as the OT side.

Cloud-side attack paths to OT:

  • Compromised cloud credentials (IAM key, service account) with access to an IoT Core Thing or Azure IoT Hub device that sends configuration messages to an OT gateway
  • Compromised cloud VM (jumpbox, historian server) that has VPN connectivity to the OT network
  • Misconfigured cloud storage (S3 bucket, Azure Blob) containing PLC project files or credentials for OT management software
  • Compromised CI/CD pipeline that deploys firmware or configuration updates to OT gateways

These are cloud security problems that have direct OT impact.

Cloud-Side Hardening Controls

Restrict IoT device messaging permissions. AWS IoT Core policies and Azure IoT Hub device policies should follow least privilege. An OT gateway that sends telemetry to the cloud should not have permission to receive arbitrary configuration payloads from the cloud unless that is explicitly required and audited. Review IoT device policy grants in your cloud tenants.

Isolate OT-connected cloud resources. Cloud VMs that serve as jumpboxes or historians for OT environments should be in dedicated VPCs/VNets with no public IP addresses, accessible only through a bastion host with MFA enforced, and with security groups/NSGs that permit outbound connections to specific OT network IP ranges only.

# Example AWS security group for OT jumpbox
Inbound:
  - Port 22 (SSH): Source = Bastion host security group only
  - No public internet inbound

Outbound:
  - Port 44818 (EtherNet/IP): Destination = OT network CIDR only
  - Port 44818 blocked to 0.0.0.0/0 (deny public EtherNet/IP)

Enforce MFA on all access paths to OT-adjacent cloud resources. The Rockwell Studio 5000 software used in the Iranian campaign was authenticated with valid credentials. Multi-factor authentication on the accounts with access to OT-connected cloud environments would have required the attacker to compromise MFA as well as the account.

Monitor CloudTrail/Azure Activity for access to OT-adjacent resources. Define a resource tagging policy that marks OT-connected cloud resources explicitly, then create CloudTrail alerts for any access to these resources from unexpected source IPs, at unusual hours, or by accounts not normally associated with OT operations.

// Azure Activity Log: unusual access to OT-tagged resources
AzureActivity
| where ResourceTags has "ot-connected"
| where CallerIpAddress !in (known_ot_admin_ips)
| where OperationNameValue has_any ("write", "delete", "action")
| project TimeGenerated, CallerIpAddress, OperationNameValue, ResourceId, Caller

Audit cloud storage for OT credentials and project files. S3 buckets and Azure Blob containers used for OT system backups or configuration management sometimes contain PLC project files (.ACD format for Rockwell), historian configuration, and engineering software credentials. These should have strict access controls and should not be publicly accessible. Run S3 public access checks and Azure Defender for Storage detections regularly.

Immediate Actions for the Iranian APT Campaign

If you operate Rockwell Allen-Bradley PLCs with any internet connectivity path:

  1. Use Shodan to check your own exposure. Search for port:44818 rockwell within your registered IP ranges. Any results indicate internet-reachable EtherNet/IP endpoints.

  2. Remove direct internet access to port 44818. There is no legitimate scenario where Allen-Bradley PLCs should accept EtherNet/IP connections from the public internet. Firewall rules should block inbound TCP/UDP port 44818 from all external sources.

  3. Audit recent PLC project file modifications. Compare current PLC project files against known-good backups. Look for changes to output values, setpoints, or HMI display logic. The Iranian campaign specifically modified HMI values to mask actual process state.

  4. Review Studio 5000 and RSLinx access logs. Identify any connections from unexpected source IPs or at unexpected times. Legitimate OT engineering sessions have defined maintenance windows; activity outside those windows warrants investigation.

The CISA advisory has a clear message: internet-exposed OT systems are being actively targeted by nation-state actors willing to cause physical process disruption. Cloud architecture teams working on OT connectivity need to treat the OT/IT boundary as a security control, not just a network topology description.

← All Analysis Subscribe via RSS