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 to adapt a working cyberattack tool from one industrial controller model to another, and confirmed the transfer succeeded.
• The final stage of the experiment consumed over $500 in API costs across a session lasting more than eight hours.
• The AI permanently destroyed one physical test device by accidentally overwriting its core memory chip.
• Researchers had to intervene repeatedly to correct the AI's errors, raising questions about how dangerous this becomes as AI needs less human supervision.
• The experiment followed a wave of real attacks on programmable controllers used by water utilities across the United States.

Forescout's Vedere Labs has now put a number on a fear the industrial-security world has carried for a while: yes, an AI can adapt a working exploit from one piece of critical-infrastructure hardware to a related model. It costs hundreds of dollars, takes most of a working day, and might kill the hardware. That's the good news. The trajectory is the problem.

What exactly did the researchers do?

Vedere Labs started with a known attack tool targeting a WAGO 750-852, a type of programmable logic controller (PLC), a small industrial computer that runs physical equipment such as water pumps or factory machinery. The original flaw, catalogued as CVE-2021-31886, is a buffer overflow: software fed more data than it can hold spills into unintended memory and executes attacker-supplied instructions. It lives in a networking component called the Nucleus FTP server and requires no password to trigger.

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

The team gave Claude Code access to a terminal, technical reference files, a reverse-engineering tool called Ghidra (software that disassembles firmware to show how it works), and the physical controller itself.

How did it go, in practice?

Bumpily. Early attempts sent the AI chasing wrong leads and researchers had to redirect it. Work stalled until the team moved from Claude Sonnet 4.6 to the more capable Claude Opus 4.6 and told the model to ask for help whenever it was uncertain about a firmware detail. That's a failure mode anyone who has mentored a junior engineer will recognise: going quiet rather than admitting you're stuck.

The turn came when the AI worked out why its injected code kept getting wiped before it could run, then changed its approach. After that single insight, Claude produced two separate working attack payloads within 12 minutes. Getting the first foothold is the hard part; iteration afterwards is fast.

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

Should people running water or industrial facilities be worried?

More than before, though not in a panic-today way. Forescout noted that an experienced researcher could have completed the initial port faster, cheaper, and without destroying the hardware. Right now, this still needs a skilled human watching closely.

But Forescout's own framing cuts through any comfort: the more important question is what happens as the amount of expert oversight required keeps falling. A single human researcher can only parallelize so much work; AI could reduce the marginal cost of adapting one known exploit across many related targets at once. That matters because PLCs from the same manufacturer routinely share firmware components across product lines. We covered the scale of that exposure on 6 August, when Forescout counted 4,407 industrial controllers reachable from the open internet, a number that should give any operations team pause.

The experiment was conducted in the wake of attacks on water-sector PLCs. Our 26 August story put a number on that wave: over 100 internet-connected water systems targeted in a single month.

If you're in operations at a water utility or a plant, the practical steps are unchanged but now more urgent. Segment your control hardware so it can't be reached directly from the internet. Replace any controllers still running software affected by CVE-2021-31886. Treat any unexpected device restart or unresponsive controller as a potential security event, not a routine fault.

If your PLCs are reachable from outside your internal network, you already have a larger problem than any AI is creating.