OmniTrust Certify · Industrial Cybersecurity Analysis

When the Lights Lie

Iran hacked America's industrial heartland. They exploited one PLC family. We ran a Threat Analysis and Risk Assessment across five. Here is what the comparison shows.

On April 7, 2026, six U.S. federal agencies did something unusual. They published a joint emergency advisory on the same day, under the same document number — AA26-097A — signed by the FBI, CISA, NSA, EPA, the Department of Energy, and U.S. Cyber Command. The message was blunt. Iranian government hackers had broken into oil, gas, and water infrastructure across the United States, manipulated the control systems running physical equipment, and caused real operational disruption and financial loss. In some facilities, the readouts operators were watching on their screens were simply wrong. The machines were lying.

This was not a theoretical attack. It was not a proof of concept or a red team exercise. It happened. And when you look at exactly how it happened, a single uncomfortable truth surfaces: every step of this attack was a known, documented, predictable threat. The kind of threat a Threat Analysis and Risk Assessment — a TARA — is specifically designed to surface before an adversary does.

That is the obvious lesson. The less obvious — and more useful — lesson is what happens when you run a TARA not just on the product that was attacked, but on its alternatives. Because the attack, once understood, becomes a measuring stick. It tells you exactly which design decisions close the attack lanes and which leave them open. Run that measurement across a market, and you stop writing incident retrospectives and start writing procurement guidance.

The Attack, in Five Steps

The attack chain was precise, patient, and in places invisible to defenders. Attackers operated from leased, third-party hosted overseas infrastructure to mask their origin. They moved through each phase using tools and techniques that, viewed from inside the network, looked like ordinary engineering work.

Figure 1 — The kill chain. Each phase of the CyberAv3ngers campaign, from public reconnaissance to physical-world consequence. Source: CISA AA26-097A (April 2026).

The Threat Actor

The group behind the campaign is CyberAv3ngers, a cyber persona operated by Iran's Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC). They are tracked across the industry under multiple aliases — Storm-0784 (Microsoft), Bauxite (Dragos), UNC5691 (Mandiant). Six of their senior officials were sanctioned by the U.S. Treasury in February 2024. The State Department placed a $10 million bounty on information about their leadership.

Their capability has escalated deliberately. In 2023 they exploited factory-default credentials on roughly 75 Unitronics Vision Series PLCs across U.S. and Irish water utilities. In 2024 they deployed IOCONTROL, a custom modular Linux-based cyberweapon targeting IoT and OT devices over MQTT/TLS with DNS-over-HTTPS evasion. By 2026 they had moved to authentication bypass at industrial scale against the dominant U.S. platform: Rockwell Automation / Allen-Bradley.

The Vulnerability

The technical entry point was CVE-2021-22681, a critical authentication bypass in Rockwell's Studio 5000 Logix Designer engineering software and its family of Logix PLCs. CVSS 9.8.

The flaw is architectural. Studio 5000 uses a cryptographic key to authenticate communications between the engineering workstation and the PLC. That key was insufficiently protected — extractable — meaning an attacker who could reach the PLC over the network could present themselves as an authorized engineering workstation without credentials.

The vulnerability was disclosed in 2021 and never patched. Rockwell issued guidance recommending defense-in-depth controls, but the underlying cryptographic design was never fixed. CISA added CVE-2021-22681 to its Known Exploited Vulnerabilities catalog in March 2026 and ordered all federal agencies to address it by March 26. The advisory confirming active exploitation was published twelve days later. A Shodan search at the time of publication showed nearly 6,000 internet-exposed Rockwell devices.

What the TARA Would Have Found

A Threat Analysis and Risk Assessment, done at the product level, surfaces threats before they become incidents. It asks a simple question about every asset in a system: if an adversary could reach this, what could they do, and what would it cost us? The answer is structured — an asset, a threat category under the STRIDE model, a damage scenario, an attack path, a risk level, and a treatment.

Run against the Rockwell ControlLogix platform with knowledge current to early 2026, the TARA would have surfaced every phase of the CyberAv3ngers attack chain as a known risk, before the CISA advisory named the threat actor.

Figure 2 — Attack vs. prediction. Top row: what CyberAv3ngers did. Bottom row: the TARA finding that corresponds to each step. The bracketed tags reference the eight comparative dimensions defined below.

This alignment is the point of the methodology. Each of the bracketed tags — [D1] through [D8] — refers to a dimension of product design that determines whether a given attack lane is open, partially mitigated, or closed. They are the measuring stick.

The Eight Dimensions

A TARA, applied comparatively, requires a shared frame. Otherwise it produces reports, not insight. For the CyberAv3ngers methodology, eight design variables determine whether a PLC is exposed to the attack class:

  1. D1 — Authentication architecture. Shared key (extractable), certificate-based TLS, operating-system-inherited, or none at all. This is where Rockwell failed: CVE-2021-22681 is a shared-key design flaw.
  2. D2 — Protocol exposure. How many network protocols the device speaks and what authentication each supports. EtherNet/IP on port 44818. Modbus TCP on 502. S7comm on 102. OPC UA. Each has different inherent security properties.
  3. D3 — Firmware update mechanism. Signed vs. unsigned. Vendor-maintained patch pipeline vs. static ROM. Whether a discovered flaw is fixable at all.
  4. D4 — Engineering workstation coupling. A proprietary locked toolchain or open standards. CyberAv3ngers used Rockwell's own Studio 5000 — a legitimate tool, indistinguishable on the wire from authorized maintenance.
  5. D5 — Network architecture assumptions. Designed for air-gap or for managed connectivity. Nearly 6,000 Rockwell devices were internet-exposed because the product assumed a boundary that did not exist.
  6. D6 — HMI data path. Whether the PLC owns the values shown to operators or whether an independent validation layer cross-checks them. The Rockwell HMI showed operators falsified readings; nothing was there to contradict the controller.
  7. D7 — Persistence surface. Can arbitrary binaries run on the controller or is the execution environment locked? Dropbear SSH was deployed as an arbitrary binary on compromised Rockwell endpoints.
  8. D8 — Default credential posture. Factory defaults that work forever or forced credential rotation on first boot. The 2023 Unitronics phase of the CyberAv3ngers campaign was 100% default-credential exploitation.

Each dimension is a question you can ask of every PLC on the market. Each answer is either red (attack lane open), amber (partially mitigated), or green (attack lane closed by design).

Five PLCs, Measured

We generated a deep TARA — 22 or more threats, eight assets, full STRIDE coverage, CVE references, attack paths, damage scenarios, mitigations, residual risk, and traceability — for five PLC families representative of the major design postures in the market:

Each threat in each TARA was evaluated against all eight dimensions and tagged [D1] through [D8] so that findings could be compared across products. The result is the heatmap below.

Figure 3 — Five PLCs across eight dimensions of the CyberAv3ngers attack surface. Red indicates the attack lane is open; amber, partially mitigated; green, closed by architectural design. Findings are sourced from public CVE records, vendor documentation, CISA advisories, and ICS-CERT bulletins.

The heatmap surfaces patterns that prose buries. Rockwell's column is red on authentication, firmware patching, engineering coupling, network assumptions, HMI data path, and persistence — the six dimensions the CyberAv3ngers attack chain traversed. The other products show genuine trade-offs, not marketing gloss.

Siemens and Schneider sit in the middle: their newer firmware addresses the critical authentication flaws, but residual issues remain (CVE-2022-38465 on pre-V2.9 S7-1500 was an architecturally equivalent global-key flaw; CVE-2023-6408 bypassed Schneider's RBAC). Their exposure counts are also non-trivial.

ABB and Phoenix Contact come out greenest, for different reasons. ABB's AC500-S was built with IEC 62443 security levels as a design input and uses a proprietary RTOS that constrains persistence. Phoenix Contact's PLCnext took the opposite path — certificate-based authentication from inception and a Linux base with modern security primitives — and is therefore strong on authentication and network architecture but honestly amber on persistence surface, because a Linux-based controller is inherently a more hospitable environment for arbitrary binaries than a proprietary RTOS.

No product is uniformly green. That is not a failure of the analysis; it is the analysis working.

The Measured Attack Surface

The heatmap tells you what is possible. The bar chart below tells you what is deployed.

Figure 4 — Internet-exposed industrial controllers by protocol. Data from Shodan and Censys scans. The CyberAv3ngers used these same public tools to find their targets. Exposure does not equal compromise, but every exposed device is a candidate.

Nearly 6,000 Rockwell devices were internet-exposed at the time of the CISA advisory — confirmed by the FBI and CISA directly in AA26-097A. The Siemens S7 protocol is on a similar order of magnitude. Modbus TCP, a vendor-agnostic protocol spoken by Schneider, Wago, and others, is the most-exposed of all at over 78,000 devices globally. The ABB and Phoenix Contact figures are not separately enumerable by protocol scan, which is itself a data point: their modern protocol stacks do not carry the same distinctive fingerprints that make earlier generations of PLCs trivially discoverable.

"We have seen both state and non-state actors in Iran pose real risk and show willingness to hurt people through compromising these systems. I fully expect them to keep up the pressure and target those sites they can get access to." — Rob Lee, CEO, Dragos

The exploitation playbook did not stay contained. According to CloudSEK's threat landscape assessment, 60+ hacktivist groups activated within hours of U.S. strikes on Iranian infrastructure in February 2026, many adopting variants of the CyberAv3ngers approach. The attack surface is no longer one group. It is a methodology now held by dozens.

What This Analysis Lets You Do

The comparative TARA turns an incident retrospective into a decision tool. Three uses:

For plant operators and utilities. If you are running Rockwell ControlLogix, the heatmap tells you which attack lanes are currently open in your deployed product and which alternatives address which lanes. It does not tell you to rip and replace. It tells you which compensating controls are most urgent given your deployment reality, and what you would gain by migration.

For procurement and engineering decisions. The same heatmap, read in reverse, is a shortlist filter. If you are selecting a PLC for a new facility, you can weigh the eight dimensions against the realistic threat model for your environment — is internet exposure likely, is your engineering workforce locked into a particular toolchain, can you operate a Linux-based controller — and pick the product whose shape best matches your constraints.

For regulators, auditors, and standards bodies. The comparative form translates directly into regulatory guidance. ISO 21434, IEC 62443, the EU Cyber Resilience Act, and NIS2 all demand structured cybersecurity evidence for connected products. A comparative TARA is that evidence at a portfolio level. It moves the conversation from "did the vendor do a threat analysis" to "how does the vendor's threat analysis compare to the measured state of the attack surface."

Built for This Moment

OmniTrust Certify — written by Ronald P. Reck — generated the five TARAs that this analysis rests on. Each one was produced from a product description, available documentation, and CVE and NVD context, and returned as a structured ten-section document: executive summary, assets, threats with full STRIDE coverage, damage scenarios, attack paths with Mermaid diagrams, impact assessments, risk assessments, mitigations, residual risk, and traceability. Aligned to ISO 21434, IEC 62443, FDA Cybersecurity Guidance, the EU Cyber Resilience Act, and NIS2.

The attack on Rockwell Automation PLCs was predictable. The threat actor was known. The vulnerability was public. The attack surface was searchable on Shodan. What was missing was a structured process that asked the right questions — and the comparative frame that made the answers useful.

That process has a name. It is a TARA. And the time to run one is before the advisory drops.