AI Took Eight Hours and $500 to Copy a Hacking Tool Onto a Second Industrial Controller

Key points

• Forescout's Vedere Labs used Anthropic's Claude AI to copy a working cyberattack tool from one industrial controller model to another, confirming the transfer succeeded.
• The final stage of the experiment consumed more than $500 in AI processing fees across a session lasting over eight hours.
• The AI bricked, meaning permanently destroyed, one of the physical test devices by accidentally overwriting a critical memory chip.
• Researchers had to step in repeatedly to correct the AI's mistakes, raising questions about how dangerous this work becomes as AI needs less human hand-holding.
• The experiment followed a wave of real attacks on programmable controllers used by water utilities across the United States.

A team of security researchers just answered a question the industrial-security world has been quietly dreading: can artificial intelligence help criminals copy a working cyberattack from one piece of critical infrastructure hardware onto a related model? The short answer is yes. The longer answer is that it currently takes a skilled human minding the AI every step of the way, costs hundreds of dollars, and may destroy the hardware in the process.

What exactly did the researchers do?

Forescout's Vedere Labs started with a known attack tool targeting a WAGO 750-852, a type of programmable logic controller (PLC), which is a small industrial computer used to run physical equipment such as water pumps, valves, and factory machinery. The original flaw, catalogued as CVE-2021-31886, is a buffer overflow, meaning the software can be fed more data than it can hold, causing it to spill into unintended memory and execute attacker-supplied instructions. The vulnerability sits in a networking component called the Nucleus FTP server and requires no password to exploit.

The goal was to take that tool and make it work on a related but different model, the WAGO 750-831, then push further and build a command-and-control implant, software that lets an attacker send ongoing instructions to a compromised device.

They gave the AI assistant Claude Code access to a terminal, technical reference files, a reverse-engineering tool called Ghidra (software that pulls apart firmware to reveal how it works), and the physical controller itself.

How did it go, in practice?

Bumpily. Early on, the AI chased several wrong leads and researchers had to redirect it. Progress stalled until the team swapped Claude Sonnet 4.6 for the more capable Claude Opus 4.6 and told the model to ask for human help whenever it was unsure about a firmware detail.

The failure mode here is familiar to anyone who has watched a junior engineer go quiet rather than admit they are stuck.

The breakthrough came when the AI worked out why its injected code kept getting wiped before it could run, then adjusted. After that single insight, Claude produced two separate working attack payloads within 12 minutes. One thing the post-mortem will say: the hard part is getting the first foothold; iteration afterward is fast.

The follow-up attempt went worse. In a separate session aimed at building the command-and-control implant, the AI tested increasingly complex payloads and one of them wrote to a section of the controller mapped to flash memory, the permanent storage chip that holds the device's core software. That bricked the PLC outright.

Should people running water or industrial facilities be worried?

The honest answer is: more than before, but not in a panic-today way. Right now, pulling off this kind of attack still needs a skilled researcher watching the AI closely. Forescout itself noted that an experienced human could have done the initial port faster and cheaper, without destroying the hardware.

But the researchers' real point is about trajectory. As AI models improve and the amount of expert supervision needed falls, the cost of adapting one known attack to dozens of related devices could drop sharply. That matters because PLCs from the same manufacturer often share firmware components across product lines.

If you work in operations at a water utility or a manufacturer, the practical steps are unchanged but now more urgent: network-segment your control hardware so it cannot be reached directly from the internet, replace any controllers still running software affected by CVE-2021-31886, and treat any unexpected device restart or unresponsive controller as a potential security event rather than a routine fault.

Operational takeaway: if your PLCs are reachable from outside your internal network, you have a larger problem than any AI can create.