What happens when AI models take aim at ICS exploits

LLMs have shown great improvement in vulnerability research and exploit development capabilities over the past six months. But it’s one thing to find vulnerabilities in well documented open-source projects and an entirely different skillset to decrypt file systems and reverse-engineer closed-source low-level firmware in highly specialized embedded devices.

That’s why researchers from industrial IoT security firm Forescout set out to test how far AI models have come to replacing the highly specialized knowledge that industrial control system (ICS) vulnerability researchers possess. Using AI assistance to port a known exploit from one model of programmable logic controllers (PLCs) to another took 8.5 hours and still required significant input from the human researcher.

So, while AI hasn’t yet turned ICS zero-day vulnerability discovery into a point-and-prompt affair for unskilled attackers, it could significantly reduce the time that experienced embedded systems hackers need to invest in developing new exploits, especially given the research can be parallelized across multiple agents.

“AI has already lowered the barrier to vulnerability research and exploit development in higher-level software. This experiment suggests that the same progression is beginning to reach low-level embedded systems, although substantial barriers remain,” the Forescout researchers said in their report.

Despite the tested models needing guidance to figure out some aspects of the analysis, they were able to combine reverse-engineering tools such as Ghidra, generate their own Python scripts for analysis, use networking tools to reason about the vulnerability, generate working exploit code, and test it against a live target. And they did all this without source code or debugger access on the PLC.

Porting exploits to other devices

For their test, researchers chose a likely attacker scenario: Porting a proof-of-concept exploit developed for one PLC model to another one that’s affected by the same vulnerability, but for which exploit code doesn’t yet exist.

This is an important challenge because different PLC models from the same vendor or even different manufacturers might share a vulnerable component, with the rest of the firmware being significantly different. Furthermore, vendors sometimes patch a vulnerability reported in one model without comprehensively assessing whether the same flaw affects others in their product line.

For example, back in June, Forescout reported seeing exploit attempts for a vulnerability they found and reported in serial-to-IP converters from Lantronix (CVE-2025-67038). The manufacturer originally released patches only for the EDS5000 and EDS3000 series of controllers, but after in-the-wild exploitation came to light four months later, it identified and released patches for additional device models: G520 series, X300 series, E210 and E220 series.

“I do believe that in case manufacturers do not perform a comprehensive assessment of models affected by a vulnerability, AI can now help attackers to do it and to port exploits to models that may not have been patched,” Daniel dos Santos, VP of research at Forescout, tells CSO.

For their testing, however, Forescout researchers ported an exploit they previously developed for CVE-2021-31886, from one Wago PLC model to a different one the vendor had flagged as affected and had already patched.

The path of least resistance is challenged

Growing AI capabilities in this field are also expected to change the types of issues attackers target. Remote code execution vulnerabilities in PLC firmware can enable deep persistence and lateral movement inside operational technology (OT) networks, but because of their complexity, most real-world attacks against ICSes usually involve lower hanging fruit, such as insecure engineering protocols or vulnerabilities in the web-based HMIs (human-to-machine interfaces) that operators use to control devices.

“The biggest risk is that vulnerabilities that are considered ‘too difficult to exploit’ will become easier to exploit,” dos Santos says. “Threat actors have a sort of ROI calculation when spending time to develop an exploit, and something that helps them create or port exploits changes this calculation: […] RCE can give very granular control to attackers to create persistent implants, execute low-level lateral movement, and so on. These things are not easy but if AI can help here, they become more likely to happen.”

Models will only get better

Forescout started its research a while ago and used what are now older-generation models: Claude Sonnet 4.6 and Claude Opus 4.6 with 1M context, which were released back in February. Since then Anthropic released Opus 4.8 in May, Fable 5 in June, Opus 5 in July, and Fable 5.1 today.

All these models have seen increasing capabilities in security research, especially Fable, which is from the same class as Anthropic’s Mythos, a model so capable at cybersecurity it was shared only with vetted organizations. The latest Chinese open-weight models have also long exceeded the capabilities of Opus 4.6 and are increasingly used for cybersecurity work, in part because frontier models have strong guardrails that can block exploit development work.

“Newer models potentially could have achieved better results,” dos Santos notes. “In some cases, like vulnerability research, we are seeing that a combination of model plus harness is more important than the model per se, but in this case of exploit development a more capable reasoning model might have done better.”

In OT networks, patching is even more complicated than in IT networks because these controllers are used to manage critical processes, so taking them offline for patching requires scheduled downtimes. As a result, ICS asset owners often prioritize patches based on how hard an issue is to exploit and how likely, but AI is challenging those assessments.

Aside from the usual exposure reduction of OT devices by disabling unused services and restricting access to their management interfaces, organizations should now take AI-assisted attack paths into consideration for their incident plans.

“Update tabletop exercises and technical playbooks to include scenarios in which attackers rapidly adapt exploits across device models, abuse exposed management services, move laterally through engineering environments, or cause device instability through failed exploitation,” the Forescout researchers warn.

AI-based exploitation can be unpredictable too and could cause issues the attacker never intended. In Forescout’s experiment, the AI agent tried to deploy a malicious payload after successful exploitation and ended up writing to a region of memory mapped to flash, permanently bricking the device. For a PLC or other ICS device controlling a physical process in an industrial installation, that unintended and unrecoverable crash can be a very dangerous situation.

“The experiment showed how unforgiving low-level embedded exploitation can be,” the researchers wrote. “As AI agents are given more freedom to act against cyber-physical systems, mistakes stop being confined to bad analysis or failed code. They can affect the device itself.”