AI Can Write the Exploit. Spharaka Signal™ Knows the Intent.

What changed in July 2026

Between 26 and 27 July 2026, roughly thirty-six community water systems in Minnesota recorded unauthorised interactions with their monitoring and control equipment. The threat actors used AI-generated Python scripts to reach the controllers. On 19 August, the NSA, CISA, the FBI, the Department of Energy and the EPA issued joint advisory AA26-231A describing the activity against Siemens S7 series programmable logic controllers.

The mechanism described in that advisory is worth reading closely, because it is the part that generalises. Actors scanned the internet for S7 PLCs with port 102 exposed, fed the targeting data into AI tooling, and received functional exploitation scripts built on the open-source snap7 and python-snap7 libraries. Those scripts were then presented as legitimate operational monitoring software.

No part of that chain required a skilled exploit developer. That is the change. The scarce resource in OT attacks used to be expertise in industrial protocols, and that scarcity was doing a great deal of unacknowledged defensive work. It is no longer scarce.

• Attacks ran overnight across dozens of systems, not one target at a time
• The exploitation code was generated, not hand-written by a protocol specialist
• The libraries used are legitimate, widely deployed and carry no CVE
• Minnesota's Department of Health confirmed water quality was unaffected at every system hit in the state

Why a signature library cannot answer this

Most OT security tools capture packets, match them against known bad patterns and raise an alert when a rule fires. Against a documented attack using a catalogued exploit, that works. Against a script iterated specifically to avoid known signatures, it fails, because the tool has no model of what the traffic is trying to do. It only knows what it has seen before.

The Minnesota activity makes the limitation concrete. snap7 is a legitimate open-source library used every day by engineers and researchers. There is no CVE for using snap7. There is no defensible signature that says snap7 equals malicious, because writing one would flag the engineering team alongside the intruder. A signature-only IDS sees a valid S7comm session and passes it.

This is not a gap that a longer signature list closes. Every signature is a description of an attack that has already been seen and documented. When exploit generation costs minutes rather than months, the rate at which novel variants appear outruns the rate at which they can be catalogued.

Detection built on protocol understanding

Spharaka Signal's IDS is not a signature library bolted onto a packet capture engine. It is built on protocol understanding: decoding what a communication is attempting at the semantic level rather than matching it against a list.

Applied to the Minnesota case, the Protocol Conformance engine decodes the PDU negotiation at the start of every S7comm session and compares it against a model of what native Siemens TIA Portal traffic looks like. snap7 produces measurably different negotiation parameters, including different maximum queue depths, different TSAP addressing patterns and different function code sequencing, because it is a different implementation of the protocol.

Those differences are structural. They are properties of the library, not of the payload, which means they cannot be engineered away by making the exploit script smarter. An actor can rewrite the logic, change the timing, obfuscate the intent and vary the targets, and the negotiation still identifies the implementation. That is the property worth building detection on, because it survives the thing that defeats signatures.

Four engines, one event

Protocol conformance is one lens, and one lens is not an architecture. Spharaka Signal runs four detection engines at once, each contributing a different reading of the same event.

The Signature engine matches against a continuously updated library of known threat patterns, CVE indicators and MITRE ATT&CK for ICS techniques, which remains the right instrument for known threats. The Protocol Conformance engine decodes industrial protocol semantics and flags implementations that do not match the expected native stack. The ML Anomaly engine maintains a behavioural baseline for every OT asset, covering which peers it communicates with, at what times and using which function codes, and scores deviations without any rule authoring. The L5 Physics and Process Fusion engine watches the physical process, detecting when a PLC, pump, valve or sensor diverges from what the process model predicts.

That last engine deserves emphasis, because it provides a detection that is independent of whether the network intrusion was visible at all. If an actor reaches the process by a path nobody instrumented, the process itself still departs from its model.

• Signature: known patterns, CVE indicators, MITRE ATT&CK for ICS techniques
• Protocol Conformance: semantic decoding of industrial protocol negotiation
• ML Anomaly: per-asset behavioural baselines, scored without rule authoring
• L5 Physics and Process Fusion: divergence between predicted and observed process behaviour

Correlation as a property of the data, not a task for the analyst

All four engines write their annotations to the same event. When a snap7-based session triggers Protocol Conformance, and the same session originates from an address with no prior communication history with that controller, triggering ML Anomaly at the same moment, those are not two alerts in two consoles waiting for somebody to notice they are the same incident. They are two annotations on one record, available in one query and one timeline.

This is where a native SIEM matters. Signal Console's SIEM is not a separate product ingesting alerts from an external detection system; it operates directly against the same data lake every engine writes to. An analyst investigating a suspected S7 exploitation event sees the correlated timeline immediately: the conformance flag, the anomaly score, the workstation that initiated the session, the firmware version of the target controller, the CVEs applicable to that firmware from the ContentDB vulnerability database, and the reachability graph showing what else is accessible from the compromised device.

An investigation that previously took forty-five minutes of manual pivoting across a network monitor, a vulnerability scanner and a SIEM arrives pre-correlated. The analyst still makes the response decision. The assembly work is already done. Against attacks that complete their impact phase in minutes, that recovered time is the difference between containment and a major incident.

Compliance as a byproduct

Every detection is mapped automatically to the corresponding MITRE ATT&CK for ICS tactic and technique, using the ContentDB MITRE knowledge base. This serves compliance as directly as it serves operations.

Regulated operators in energy, water and defence can produce audit-ready incident reports that speak the standardised language of MITRE ATT&CK, map to IEC 62443 requirements and satisfy NERC CIP reporting obligations, without a manual mapping exercise after the fact. The compliance trail falls out of the detection process rather than being assembled as separate documentation work.

The Minnesota incident is a proof of concept, not an endpoint

AI-assisted attack tooling will keep improving. The exploits will get more sophisticated, the target sets broader and the pace faster. The advisory's own priority directive, that internet-exposed S7 controllers should be taken offline, is sound and immediate advice, and any facility whose controllers are reachable on port 102 should act on it today.

It is also not a strategy. Exposure reduction lowers the odds of being found; it does not decide what happens once an actor is inside a segment they are entitled to reach. The platform that holds through this evolution is not the one with the longest signature list. It is the one that understands what it is seeing, correlates across every layer of the attack chain, and puts the relevant context in front of the analyst at the moment the incident opens rather than an hour later.