Listen to this Post

Introduction:
Forescout’s Vedere Labs has demonstrated that a frontier-class AI model can successfully port a remote code execution (RCE) exploit from one programmable logic controller (PLC) model to another—but only with intensive expert supervision, significant financial cost, and a process fragile enough to permanently destroy physical hardware. The experiment, which used Anthropic’s Claude to adapt a CVE-2021-31886 exploit from a WAGO 750-852 PLC to a WAGO 750-831 model, challenges the assumption that industrial control system (ICS) exploits remain the exclusive domain of highly specialized human researchers. While AI is not yet capable of autonomous PLC exploitation, the trajectory is clear: as models improve, the barriers to offensive OT capabilities will continue to fall.
Learning Objectives & Secrets:
- Objective 1: Understand the Current Capabilities and Limitations of AI in OT Exploit Development – Learn how AI can assist with firmware analysis, reverse engineering, and payload generation, but recognize that human expertise remains essential for guiding the model through dead ends, correcting false leads, and providing critical disassembly context.
-
Objective 2 Secret Tip: Master the Art of AI Prompt Engineering for Embedded Systems – Success depends on how you structure the interaction. The researchers switched from Claude Sonnet 4.6 to Claude Opus 4.6 when progress stalled, and instructed the model to request help whenever uncertain about firmware details. Providing the AI with terminal access, Ghidra, and the physical target device—not just firmware binaries—was critical to success.
-
Objective 3 Secret Tip: Anticipate the “Brick Factor” in AI-Driven Exploit Development – The experiment’s attempt to extend the RCE into a command-and-control implant resulted in an incorrect write to flash memory that permanently destroyed the PLC. Always run AI-generated payloads in isolated, non-production environments with hardware you are prepared to lose.
You Should Know:
1. The Experiment: From One PLC to Another
Forescout’s Vedere Labs began with three inputs: a working RCE exploit for the WAGO 750-852 (originally developed in earlier research), a firmware binary for the WAGO 750-831 (version V01.04.16), and a physical WAGO 750-831 PLC running that firmware. The exploit targets CVE-2021-31886, a pre-authentication stack-based buffer overflow in the Nucleus FTP server’s handling of the USER command, which carries a Siemens-assigned CVSS score of 9.8. The vulnerability is accessible over TCP port 21 before authentication, and no patches are available for the affected WAGO controllers.
The team used Claude Code with access to a terminal, the reverse-engineering tool Ghidra, and the live target PLC. The AI confirmed the vulnerability through a combination of live probing and static firmware analysis before generating a payload that crashed the PLC—confirming the presence of the bug. However, converting that crash into controlled code execution proved far more challenging.
2. The Technical Hurdle: Shellcode Disappearing Act
The critical breakthrough came when Claude identified why injected shellcode kept disappearing before execution. On the WAGO 750-831, normal FTP command processing zeroed out 256 bytes of the attacker-controlled buffer—overwriting the malicious payload before it could run. The solution was to avoid the normal command-completion path entirely. Claude adapted the USER and QUIT sequence used against the 750-852 into a USER and CWD sequence, and omitted the `\r\n` (CRLF) terminator. This “prevented the relevant processing path from completing in the usual way,” leaving the shellcode intact long enough to execute.
Step-by-Step Guide: What This Does and How to Use It
This technique demonstrates how AI can assist in porting exploits across embedded systems:
- Firmware Analysis: Feed the target firmware binary into the AI alongside the existing exploit code. Use Ghidra to provide disassembly context when the AI requests it.
-
Live Probing: Have the AI test the live target’s FTP server to confirm vulnerability presence. Monitor for crashes that indicate the buffer overflow is triggerable.
-
Shellcode Preservation: If the target’s normal processing path overwrites your payload, instruct the AI to explore alternative command sequences. In this case, omitting the CRLF terminator and using a USER→CWD sequence preserved the buffer.
-
Payload Generation: Once RCE is established, the AI can generate working payloads rapidly—in this experiment, within 12 minutes.
-
Testing and Validation: Always test in isolated environments. The researchers used a test harness that measured PLC uptime after each exploit attempt to diagnose execution failures.
3. Cost, Time, and Human Involvement
The final RCE development stage consumed $535.74 in API tokens during an 8-hour, 32-minute session for a single exploit on a single target. The researchers note that “one could argue that the same researcher could have achieved the initial RCE port without AI in less time and at lower cost while also keeping the PLC alive”. However, once initial code execution was achieved, the AI generated multiple working network payloads within minutes—suggesting that post-exploitation automation could become increasingly viable as models improve.
4. The Brick: When AI Goes Too Far
A separate session aimed at developing a command-and-control implant demonstrated the risks of allowing AI to operate against physical technology. Claude tested progressively more complex payloads, and one wrote to a flash-mapped memory region, permanently bricking the PLC. This highlights how unforgiving binary exploitation on embedded targets can be—and why human oversight remains essential. The researchers emphasize that this pattern—a complex, labor-intensive process leading to initial execution, followed by rapid iteration—is what justifies cost analysis for scaling such work.
5. Defense and Mitigation Strategies
For organizations operating WAGO PLCs or similar OT devices, the experiment underscores several critical defense measures:
- Do not dismiss OT vulnerabilities because they seem hard to exploit—AI is steadily lowering the barrier.
- Reduce unnecessary OT device exposure—disable or block FTP on port 21 where not required.
- Monitor OT environments for early signs of exploitation—look for anomalous network traffic, unexpected crashes, or unauthorized FTP connections.
- Exercise incident response against AI-assisted OT attack paths—assume attackers may have AI assistance and plan accordingly.
- Use AI defensively but validate its outputs—frontier AI models are now finding vulnerabilities at scale, but human verification remains critical.
- Linux and Windows Commands for OT Network Monitoring
For defenders, the following commands can help detect and mitigate similar threats:
Linux – Monitor FTP Traffic on Port 21:
sudo tcpdump -i eth0 port 21 -1n -v
Linux – Detect Anomalous Connections to PLCs:
sudo netstat -antup | grep -E "(:21|:502|:44818)" Common OT ports: FTP(21), Modbus(502), EtherNet/IP(44818)
Linux – Block FTP Access to PLC Subnet:
sudo iptables -A FORWARD -d 192.168.1.0/24 -p tcp --dport 21 -j DROP
Windows – Monitor for Suspicious FTP Activity Using PowerShell:
Get-1etTCPConnection -LocalPort 21 | Where-Object {$_.State -eq "Established"}
Windows – Enable Advanced Audit Logging for OT Network Connections:
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
7. The Bigger Picture: AI and Industrial Cybersecurity
The Forescout experiment demonstrates that AI is becoming increasingly relevant to industrial cybersecurity research. While the barrier to autonomous PLC exploitation remains high today, the trend line is clear. As models become more capable and independent, the cost and expertise required to adapt exploits across related embedded targets could fall substantially. For critical infrastructure operators, the question is not whether AI can autonomously develop sophisticated PLC attacks today—it cannot—but what happens when increasingly autonomous exploit development meets large numbers of exposed industrial devices. Recent attacks against exposed PLCs in US water and wastewater systems underscore that this is not a theoretical concern.
What Undercode Say:
- Key Takeaway 1: AI can assist with low-level embedded exploit development, but it cannot do so reliably or autonomously. The Forescout experiment required significant researcher involvement, cost over $500 in API fees, and took more than eight hours—all for a single exploit on a single target. The headline isn’t “AI can hack PLCs now”—it’s “AI can hack PLCs badly, expensively, and dangerously.”
-
Key Takeaway 2: The trajectory is accelerating. While today’s frontier models require extensive human supervision, the same progression that lowered the barrier for software vulnerability research is beginning to reach low-level embedded systems. Organizations must prepare for a future where AI-assisted OT attacks become more accessible, and defensive strategies must evolve accordingly.
The experiment’s most telling moment may be the bricked PLC—a reminder that in industrial environments, failed exploits don’t just crash software; they destroy hardware. As AI-assisted offensive capabilities improve, the cost of failure will only increase, and defenders must be ready.
Prediction:
- +1 AI-assisted OT exploit development will accelerate over the next 12–24 months as models become more capable of understanding embedded architectures and firmware layouts, reducing the time and cost required for exploit porting.
-
-1 The barrier to entry for industrial cyberattacks will continue to fall, increasing the risk of AI-assisted attacks against critical infrastructure—particularly in sectors like water, energy, and manufacturing where exposed PLCs remain common.
-
-1 The “brick factor” will remain a significant limitation for AI-driven exploit development in the near term, as AI models lack the nuanced understanding of hardware constraints required to avoid destructive failures.
-
+1 Defensive AI applications will also advance, enabling faster detection of AI-generated attack patterns and more automated incident response in OT environments.
-
-1 Organizations that continue to dismiss OT vulnerabilities as “too hard to exploit” will face increasing risk as AI lowers the technical barrier, potentially leading to high-profile industrial security incidents.
▶️ Related Video (80% Match):
https://www.youtube.com/watch?v=2v2MQdZYvWU
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: https://lnkd.in/p/eS-sr_ft – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅



