For decades, the most effective security control in a lot of OT environments wasn’t a firewall. It was the fact that reverse engineering a PLC was difficult, miserable, expensive work that only a few hundred people on the planet did well. Nobody wrote that control into a policy, it was just the nature of the beast.
Today, however, we have REA, short for Reverse Engineer Anything. And pretty much anyone with a keyboard and internet connection can leverage it. Adoption has been like wildfire; going from under 10,000 GitHub stars to more than 400,000 in about a month.
To be fair to REA, the tool isn’t the problem. It’s how it is being used, and by whom. Reverse engineering has gone from specialist craft to something you install from npm, equally available to your red team and to whoever is scanning port 102 tonight. The result? Plan as if every device, binary and protocol you run is readable, because for all intents and purposes, it is.
REA is an open-source, MIT-licensed tool, first published on GitHub in April 2026, that lets an AI coding agent drive Ghidra or IDA and report back on what it finds, no source code required. It installs from npm as an MCP server, so coding agents such as Claude Code, Cursor and Codex can call reverse engineering tools directly. It handles firmware, packet captures, native binaries, Android apps, .NET assemblies and websites, and it shows the evidence behind each finding.
Every serious ICS attack of the past decade had reverse engineering underneath it. TRISIS didn’t stumble onto the TriStation protocol by happenstance. What changed in 2026 is that you no longer need specialized knowledge; you literally just have to be able to write a couple of well-placed agent prompts.
| Date | Event | What it shows |
| Oct 2026 | REA stars rise from under 10,000 to about 234,000 in eight days (blacklens.io); now over 400,000, with 100,000+ forks | Agent-driven analysis of binaries, firmware (via Binwalk and Unblob) and packet captures is now a free, packaged workflow |
| Sep 2026 | Forescout Vedere Labs uses an AI agent with Ghidra to port a pre-auth RCE from a WAGO 750-852 to a 750-831 | 8.5 hours and $535.74 to working code execution; payloads followed in 12 minutes; a later attempt bricked the PLC |
| Aug 2026 | Joint advisory AA26-231A (NSA, CISA, FBI, DOE, EPA) | AI-generated Python scripts, disguised as monitoring tools, used against exposed Siemens S7 PLCs from S7-200 to S7-1500 F-series |
| Jul 2026 | FBI and EPA report unauthorized PLC access at 30+ water utilities in at least seven states | Operators locked out of controls; IP addresses changed remotely |
| Apr 2026 | Advisory AA26-097A on Iran-affiliated actors targeting internet-connected PLCs | Water, energy and government facilities named; scope widened in July |
| 2017–2024 | TRISIS, PIPEDREAM, FrostyGoop | Each depended on reverse-engineered protocols or controller logic, built by well-resourced teams over months |
Notice what AI has done is make old weaknesses (default passwords, exposed services, unpatched firmware) cheaper to exploit at scale. Given how many of those are knowingly or unknowingly sitting on the internet, that’s a lot.
Board briefings on this topic tend to land in one of two schools of thought. It’s either “autonomous AI will take down the grid” or “it’s just hype.” Both are wrong.
| Myth | Fact |
| AI agents are autonomously attacking industrial processes today | No fully autonomous AI attack on ICS has been confirmed. Observed use is reconnaissance, script generation and exploit adaptation, with humans steering |
| REA lets anyone hack a PLC in an afternoon | The WAGO port took an expert 8.5 hours of guided sessions. The barrier is significantly lower but not gone |
| AI is finding brand-new ICS vulnerabilities at scale | Yes, it is happening. But many more cases apply known weaknesses (default credentials, exposed services, unpatched firmware) faster and to more targets |
| Proprietary protocols and closed firmware protect us | Obscurity was never a control. It was a cost barrier, and agent-driven decompilation eliminated that. |
| “Hard to exploit” vulnerabilities can wait | Exploit difficulty is the variable AI erodes most. Prioritizing on difficulty alone is no longer a determinant factor. Cogent Research found average exploit development time fell from 125.3 days to 0.5 days between January 2025 and April 2026. |
| The only risk is a malicious AI | Documented AI-caused OT damage was an authorized agent bricking a PLC by mistake |
| Patch the named model and you’re covered | Shared components (for example, the Nucleus RTOS stack) span product families. WAGO lists 19 affected models with no update available |
The short version: Groups that couldn’t spell S7comm last year can now rent the expertise by the token.
Exposure is worst where you find long-lived embedded devices, firmware shared across a whole product family, and a security team of one person who also runs the help desk. The ratings below are our judgment, not an official ranking.
| Sector | Most readable targets | Likely impact | Exposure |
| Water and Wastewater Systems | Internet-facing PLCs, HMIs, telemetry RTUs | Treatment or distribution disruption; already under active attack | High |
| Energy | Substation IEDs, protection relays, DER and inverter firmware, gateways | Faster weaponization of relay and inverter flaws across fleets | High |
| Critical Manufacturing | PLC families, robot controllers, engineering software | Line stoppage, logic tampering, IP theft from controller code | High |
| Chemical | Safety instrumented systems, batch controllers | Interference with safety functions; S7-1500 F-series named in AA26-231A | High |
| Healthcare and Public Health | Medical device firmware, building management | Device unavailability; patient-safety risk | High |
| Food and Agriculture | Small-plant PLCs, remote-managed controllers | Production and quality disruption | Elevated |
| Transportation Systems | Rail signaling, port cranes, traffic and pipeline SCADA | Physical safety and throughput impact | Elevated |
| Dams | Gate and spillway controllers, remote telemetry | Low-frequency, high-consequence events | Elevated |
| Nuclear Reactors, Materials, and Waste | Balance-of-plant and support systems | Strong regulation limits exposure; support systems remain readable | Elevated |
| Defense Industrial Base | Manufacturing OT, supplier firmware | Supply chain compromise and IP loss | Elevated |
| Commercial Facilities | Building automation (BACnet), HVAC, access control | Pivot point into tenant networks; physical disruption | Elevated |
| Government Services and Facilities | Building systems, municipal utilities | Service disruption; named in AA26-097A | Elevated |
| Communications | Network appliances, edge and IoT firmware | Patch-diffing shrinks time to exploit for edge devices | Elevated |
| Information Technology | Commercial software, update and build pipelines | Upstream code read once, exploited across every downstream sector | Elevated |
| Emergency Services | Dispatch systems, radio and vehicle telematics | Degraded response capacity | Moderate |
| Financial Services | Thick clients, mobile apps, embedded secrets | Credential and API exposure; limited physical consequence | Moderate |
Note: A single readable component, such as an RTOS network stack, can expose a dozen sectors at once, and it doesn’t care which vertical your org chart put you in. Software supply chain multiplies everything: code read once upstream gets exploited downstream, everywhere.
Nobody needed AI to invent new tactics. REA-class tooling is making nefarious behavior easier to do, by more people, with less knowledge and with fewer resources. Mapped to MITRE ATT&CK for ICS (and Enterprise where noted):
| Phase | Technique | What REA-class tooling changes | Example |
| Resource development | Obtain/Develop Capabilities: Exploits (T1588.005, T1587.004) | Firmware updates are diffed by an agent to find the fixed flaw and build an n-day exploit in days, not weeks | Patch for one model analyzed to attack unpatched siblings |
| Reconnaissance | Search Open Technical Databases: Scan Databases (T1596.005); Internet Accessible Device (T0883) | Shodan, Censys and ZoomEye results fed straight into agent tooling | AA26-231A actors located S7 PLCs on TCP 102 |
| Initial access | Exploit Public-Facing Application (T0819); Exploitation of Remote Services (T0866) | Exploits ported across device families sharing a vulnerable stack | WAGO 750-831 pre-auth RCE via FTP |
| Initial access | Hardcoded Credentials (T0891); Default Credentials (T0812) | Agents extract embedded keys and passwords from firmware images in minutes | One hard-coded secret exposes every unit in a product line |
| Discovery | Remote System Information Discovery (T0888); Point & Tag Identification (T0861) | Agents decode proprietary protocols from packet captures and engineering project files | Mapping which tags control which pumps or breakers |
| Collection | Program Upload (T0845) | Uploaded ladder logic is read and explained by an agent, revealing process intent | Pulling S7 logic via python-snap7 |
| Evasion | Masquerading (T0849); Standard Application Layer Protocol (T0869) | Scripts built to look and talk like legitimate monitoring tools | AA26-231A scripts disguised as monitoring utilities |
| Execution | Unauthorized Command Message (T0855); Modify Parameter (T0836) | Protocol-aware tooling generated for Modbus, S7comm, DNP3 and CODESYS without deep expertise | FrostyGoop-style Modbus commands, now cheaper to build |
| Persistence | Modify Program (T0889); Module Firmware (T0839) | Logic and firmware modification becomes reachable for mid-tier actors | Malicious changes to reusable PLC code modules (AA26-097A update) |
| Impact | Loss of Safety (T0880); Manipulation of View (T0832); Denial of Service (T0814) | Faster path to safety-system and HMI tampering; failed exploits can brick devices | Agent flash write permanently disabled a PLC |
The good news, such as it is: every row above leaves tracks in network traffic, logic changes or engineering workstation behavior. An AI-written script still has to talk to the PLC. Being able to know what you have, understanding what you are looking at, receiving prioritized alerts with context and being able to arrest and/or preempt an attack will help you catch it, whoever or whatever wrote it.
The average time to develop an exploit fell from 125.3 days in January 2025 to 0.5 days by April 2026
1. Treat government guidance as the floor, not the finish line
CISA’s Cross-Sector Cybersecurity Performance Goals, NIST SP 800-82r3, ISA/IEC 62443, MITRE ATT&CK for ICS, and sector rules such as NERC CIP and TSA security directives define the minimum. Read the joint advisories too. AA26-231A and AA26-097A aren’t press releases; they list indicators you can hunt for this afternoon. Abroad, NIS2 and the EU Cyber Resilience Act raise the bar on operators and product makers. Compliance is where the conversation starts. No adversary has ever checked whether you passed your audit first.
Example: Consider a water utility that meets its compliance checklist but still has a PLC on TCP 102 facing the internet. AA26-231A names that exact condition. Compliance says “pass"; exposure says otherwise.
2. Know behavior, not just make and model
An inventory that lists “Siemens S7-1200, firmware 4.2" tells you what you bought. It doesn’t tell you what that controller talks to, who downloads logic to it and from where, or what normal looks like at 2 a.m. Someone else’s AI is working that out right now. You should probably get there first.
Example: AA26-231A scripts used legitimate libraries and looked like monitoring tools. An asset list would not flag them. A baseline showing a new host issuing S7comm writes outside a maintenance window would.
3. Apply zero trust to OT, deliberately
Assume every device, credential and protocol in your plant has already been read by someone who isn’t you. Segment by function, require authenticated and explicit paths to controllers, enforce least privilege for engineering access, and put human in the loop approval gates on irreversible actions such as firmware and flash writes. That includes your own AI agents.
Example: In the WAGO experiment, no attacker killed the PLC. An authorized agent did it by accident, with one bad flash write. A human approval step would have saved a perfectly good controller.
4. Look past devices to traffic, code and connections
Adversary agents are reading your firmware, your vendors’ code and your packet captures. It would be awkward if they ended up knowing your environment better than you do. Analyze the firmware and software bills of materials of what you run, map every remote access path and vendor connection, and monitor east-west traffic inside the OT network, not just the perimeter.
Example: One vulnerable RTOS network stack sat inside 19 WAGO models with no patch. Only an organization that knew which components were inside its devices could find every affected unit.
5. Triage findings into Now, Next and Never
The same tools will bury defenders in findings, and a 4,000-row spreadsheet sorted by CVSS is not a plan. Sort by reachability and process consequence, not by CVSS or exploit difficulty.
| Bucket | Criteria | Action |
| Now | Reachable from the internet or IT, known exploit or active advisory, or safety consequence | Isolate, mitigate or patch within days |
| Next | Reachable only inside OT, high process consequence, shared component across a product family | Compensating controls now; patch at the next planned outage |
| Never (accept and monitor) | Not reachable, low consequence, or patching risks more than it saves | Document the risk decision; monitor for change |
Example: An unpatched relay deep in a segmented substation network with no routable path is a “Next.” The same relay behind a vendor VPN with shared credentials is a “Now.”
6. Make it an organizational charter, not a security project
If OT security lives only in the security budget, it will get treated like a line item. AI-driven reverse engineering touches procurement, engineering, legal, operations and the board. Write OT cyber resilience into the corporate charter and risk register. Put security requirements in purchase contracts (SBOMs, vulnerability disclosure, patch commitments). Give operations leaders shared accountability for exposure. Run tabletop exercises that assume an adversary can adapt an exploit across your device fleet in a day.
Example: A manufacturer that requires component disclosure from every PLC and drive vendor can answer, “are we affected?” in hours. One that can’t will spend weeks finding out, and the adversary will likely get there first.
AI-driven reverse engineering isn’t a future risk you can schedule for the next fiscal year. It’s on GitHub, in joint advisories and in published lab results, with how-to REA tutorials on YouTube right now. It has made OT attacks easier and cheaper, and it has opened the door for far more people to try.
Sources
- REA project repository, GitHub
- REA: What AI reverse engineering finds in your applications, blacklens.io, Oct 20, 2026
- AI-Ported PLC Exploits: What the WAGO Case Shows, Cloud Security Alliance, Sep 2, 2026
- AI-Generated Exploit Scripts Target Siemens S7 PLCs, Cloud Security Alliance, Aug 22, 2026
- What happens when AI models take aim at ICS exploits, CSO Online, Sep 1, 2026
- AI-Assisted Exploit Development Outpaces Scanner Detection, Dark Reading
- MITRE ATT&CK for ICS
