AI-Assisted Reconnaissance in OT Networks: What Monterrey Tells European Sectoral SOCs

On a Tuesday evening in late April, the Monterrey water authority disclosed eleven days of read-only access to its supervisory control network. The attacker had used a commercial language model to enumerate Modbus endpoints, parse vendor documentation, and assemble a credential dictionary, work that would have required a specialized OT operator forty-eight hours earlier ¹. The implication for European water utilities is direct: the cost of OT reconnaissance has collapsed, and behavioral baselines tuned to manual probing no longer detect the new tempo.

What happened

The intrusion began on 17 April when a commodity infostealer collected credentials from a contractor laptop. Within six hours the attacker had cycled through ten variants of the contractor account against the utility's VPN concentrator. By 18 April the attacker had moved laterally into the engineering workstation segment and started enumerating PLC firmware versions through legitimate Modbus/TCP reads ¹. The Mexican CERT advisory describes the operator's detection timeline as eleven days because the SCADA traffic looked unremarkable: read-only requests within working hours, distributed across normal polling intervals.

The first defensive signal appeared on 28 April when a Schneider Electric ProductCERT vendor sweep identified anomalous firmware enumeration patterns on devices behind the utility's perimeter ². The utility took the supervisory segment offline that evening. Public disclosure followed on 29 April.

Technical detail

Three vectors made detection harder than a textbook unauthorized access case. First, the attacker used a commercial LLM to translate vendor English-language documentation into Modbus function code sequences appropriate for the specific PLC models on the utility's network ³. Second, the attacker's session timing matched normal contractor activity rhythm because the LLM helped pace queries to match the source workstation's typical pattern. Third, no exploit was used; every probe was a legitimate read against a publicly documented register.

The defensive implication for sectoral SOCs is that protocol-aware detection rules grounded in "abnormal command type" no longer suffice. Operators need behavioral baselines that account for query volume, register coverage, and inter-request entropy.

EU context

NIS2 Article 21 places a continuous risk-assessment obligation on operators of essential services. The Monterrey case demonstrates a risk class that most Q1 2026 sectoral assessments did not yet model: low-skill reconnaissance enabled by LLM access. ENISA's 2026 threat landscape report identifies AI-assisted enumeration as an emerging category, but the published guidance treats it as a 2027 horizon ⁴. National competent authorities should expect to update their threat catalog within the next quarter.

For Lithuanian water utilities, the relevant TIS2 obligation is the technical-measures requirement that flowed into bylaw form in March 2026. The Monterrey pattern is in scope under "anomalous read access to industrial protocols" but the existing audit checklist does not yet enumerate LLM-assisted query patterns as a sub-category.

Sectoral implication

Three concrete actions for sectoral SOC managers this quarter:

• Add a detection rule that flags Modbus read volume exceeding three standard deviations from the rolling 90-day baseline for any contractor account, irrespective of working-hours window.
• Audit the vendor documentation accessible from contractor workstations. Several utilities found that vendor manuals downloaded locally during onboarding remained on disk for years, a reconnaissance asset for any attacker who reaches that endpoint.
• Update procurement language for next contract cycle: require evidence of behavioral analytics tuned to AI-assisted enumeration patterns from any managed detection vendor proposing OT visibility services.

The Monterrey utility has not yet published its post-incident root cause analysis. When that document lands, the EU sectoral community should treat it as input for the next round of NIS2 risk-assessment updates.