You've probably already seen the headline this week: "Hackers Used Claude AI to Attack Mexican Water Utility." It's been recycled across every major security outlet, every LinkedIn feed, and every "AI is dangerous" mailing list since Dragos published its threat report in early May. The headline is technically accurate. It's also missing the point so completely that it qualifies as misinformation by omission.
The real story is more interesting, more technical, and considerably worse for the people who actually have to defend things. So this is AckerWorx's May deep-dive: what genuinely happened in Monterrey, what the security press is getting wrong about it, and why the under-reported detail is the one your CISO should be losing sleep over.
What Actually Happened
Between December 2025 and February 2026, an unidentified adversary ran a campaign against multiple Mexican government organisations, exfiltrating sensitive government data and civilian records along the way. Researchers at Gambit Security recovered the intrusion materials in late February and brought in Dragos specifically to evaluate the part of the campaign aimed at Servicios de Agua y Drenaje de Monterrey (SADM) — the municipal water and drainage utility serving the Monterrey metropolitan area.
The headline-grabbing finding: the attackers leaned heavily on commercial large language models. Anthropic's Claude was the technical executor — intrusion planning, tool development, on-the-fly problem solving. OpenAI's GPT handled victim data processing, Spanish-language report generation, and structured output. Across the campaign, Dragos reviewed roughly 350 artifacts, most of them AI-generated offensive scripts.
The headline almost everyone is missing: the OT breach failed. The attackers got into SADM's enterprise IT network. They identified a vNode industrial gateway and a SCADA/IIoT management interface as high-value pivot points. They attempted password-spray attacks against the OT environment. And the OT defences held.
That last part is being reported as good news. It isn't.
The Detail Nobody Is Quoting
Buried in Dragos's analysis is the artifact that matters: a 17,000-line Python framework the attackers built with Claude's help, called — and this is genuinely the name they used — BACKUPOSINT v9.0 APEX PREDATOR. It contained 49 modules covering reconnaissance, lateral movement, OT-adjacent enumeration, and data exfiltration.
Take a moment with that number. Seventeen thousand lines. Forty-nine modules. Generated, iterated, and operationalised by attackers who, on the evidence, did not need to be world-class offensive engineers to produce it. That is not a script kiddie's toolkit and it is not a state-grade APT framework either. It is something new in the middle: a custom intrusion platform built in weeks rather than months, by operators whose individual skill ceiling has been raised — not replaced — by the LLM doing the heavy lifting.
This is the story. Not "AI did the hacking." The actual story is: the expertise barrier for building bespoke offensive tooling against critical infrastructure just dropped through the floor.
Why "The OT Breach Failed" Is Not a Comfort
Every defender's instinct on reading the report is to find the reassuring detail. Here it is: the attackers never made it from IT into OT. The segmentation worked, password spray was caught or rate-limited, the vNode interface was not successfully accessed.
This is a one-attempt sample size against one utility. That is the entire dataset. Generalising "OT defences held" from this incident to the global ICS estate is the kind of statistical optimism that ends with a Congressional hearing.
Three uncomfortable facts about this:
The attackers got the IT compromise. That's already a serious incident — sensitive utility data is exposed regardless of whether anyone managed to flick a relay.
They correctly identified the OT pivot path. Claude surfaced the vNode SCADA gateway during internal reconnaissance and classified it as high-value. The targeting logic worked. What failed was the final-stage authentication attack, not the campaign architecture.
The framework persists. Seventeen thousand lines of working OT-aware tooling does not evaporate because one engagement ended in a password-spray timeout. It gets refined, retargeted, and reused — possibly traded.
The attackers got the dress rehearsal. The next utility is the live performance.
The Expertise-Barrier Collapse
For years, the comforting consensus on ICS security has been roughly: "OT attacks require rare expertise — vendor-specific protocol knowledge, physical-process understanding, custom tooling. The pool of people capable of doing real harm is small, and most of them are state-employed."
That consensus is now actively wrong. What the Monterrey campaign demonstrates is not that Claude or GPT can replace an expert ICS attacker — they can't, not yet, and the failed OT pivot is part of the proof. What it demonstrates is that an attacker with moderate IT skills, persistent intent, and a paid LLM subscription can now produce a credible, multi-thousand-line, OT-targeting framework that would previously have required either a dedicated red team or a nation-state budget.
The defenders' historical advantage on the ICS side wasn't superior tooling. It was that the bar to enter was high enough that most attackers stayed in IT. That bar just dropped. The pool of credible ICS-targeting adversaries is no longer "a few hundred state operators globally." It is now "anyone who can pay USD 20 a month and articulate the problem clearly."
This is the part that should keep you awake.
An Honest Note About AI Provider Responses
To their credit, both Anthropic and OpenAI have been engaging publicly on misuse and have visible programmes to detect and disrupt malicious use of their models. These programmes are not theatre — Anthropic in particular has published threat analyses on coordinated misuse and has stated repeatedly that controlling model access is core to their cybersecurity posture, in pointed contrast to OpenAI's expanded-access strategy for cyber-defence customers.
The AckerWorx position on this is unromantic: provider-side controls are necessary, insufficient, and getting outpaced. The Monterrey adversary appears to have used commercially available models against terms of service. Detecting that misuse retrospectively, in a forensic report, is not the same as preventing it in flight. The defensive value of provider controls is real but cannot be the load-bearing component of a national-infrastructure threat model.
Defenders cannot outsource their attack-surface management to OpenAI's trust and safety team. Anyone who plans to is building on someone else's roadmap.
What Defenders Should Actually Do This Quarter
The Dragos report comes with a clear recommendation that prevention-only strategies are no longer adequate. Translating that into work-week-sized actions for IT and OT teams:
For IT security teams:
Treat your IT-OT boundary as the actual perimeter. Not figuratively — operationally. The Monterrey adversary was inside enterprise IT for weeks before Dragos was called. Detection time on enterprise compromise is the variable that decides whether OT ever sees the attack.
Hunt for AI-assisted reconnaissance patterns. AI-generated tooling tends to have telltale fingerprints: aggressively comprehensive enumeration, polished error handling, multi-language comments, and a very particular flavour of over-engineering. Your SOC's "this looks AI-written" instinct is a real signal — train it.
Audit credential exposure for OT-adjacent accounts. Service accounts with read access to OT-management interfaces, jump-host credentials, vendor-support accounts. Password spray works because somebody's password was guessable.
For OT security teams:
Inventory your industrial gateways and SCADA management surfaces. vNode, OPC servers, IIoT brokers, historians — the things attackers will ask Claude to find for them. If you cannot enumerate yours in an afternoon, you have already lost the asset-management half of the fight.
Deploy OT-aware detection. Network monitoring tuned for ICS protocols (Modbus, DNP3, S7, EtherNet/IP) is no longer optional. Generic IT IDS rules will not catch a careful OT enumeration.
Strong authentication and segmentation are the load-bearing controls. The Monterrey OT defences held on these two. They are also the controls most often deferred during ICS modernisation projects. Stop deferring them.
For executive and policy readers:
Budget for OT visibility, not just OT prevention. The Dragos finding is explicit: in an AI-accelerated threat environment, you need detection and response, not just hardened perimeters.
Accept that the threat-actor pool just expanded. Threat models that assumed only state actors could mount credible OT campaigns need updating. Mid-tier criminal actors are now operationally relevant on infrastructure.
Demand AI-misuse transparency from your vendors. If your security stack includes AI components, ask hard questions about how the providers detect and respond to abuse — and assume those answers are partial.
The Bigger Picture
Monterrey is going to be cited for the next decade as the inflection point — the first publicly documented case of off-the-shelf AI being used as the operational engine of an attempted critical-infrastructure attack. That framing is correct, and also incomplete. It is not the case that matters because AI was used. It is the case that matters because the attack succeeded at every stage where defences had not been modernised, and only failed where they had.
That is a clearer signal than any threat report. Defences that have been treated as priorities — segmentation, OT-side authentication, industrial detection — worked. Defences that hadn't been — IT-side enumeration containment, AI-augmented activity detection, credential hygiene on OT-adjacent accounts — failed.
The white-hat takeaway is unsentimental: the attackers got better quickly, and most defenders haven't moved. The next time this pattern shows up, it won't be in a Dragos report you read about over coffee. It'll be your incident.
Plan accordingly.
AckerWorx covers cybersecurity, OSINT, and secure software development for the white-hat community. If you work in OT, ICS, or critical-infrastructure security and have ground-truth perspective on any of the above, get in touch via the contact page — corroborating analyses and corrections are always welcome.