SURIQ
When more than thirty small water utilities in one state are knocked around inside 48 hours, the number that should worry you is not thirty. It is the coordination. A single operator does not case and breach thirty independent municipal systems by hand in a weekend. That pattern is what it looks like when one shared weakness gets swept across everyone who has it.
Minnesota IT Services (MNIT) confirmed the scope: over the weekend of July 26, more than thirty community water systems had their control technology disrupted in one coordinated operation. In Braham, treatment stopped and the plant dropped offline, so the city told residents to hold down usage until it came back. Plymouth lost cellular links at two of its towers and several wastewater lift stations and switched to running by hand. Maple Plain and South St. Paul saw their automated controls affected, and Maple Plain declared a local emergency. Every affected system was back within hours, and no utility had to put its drinking water under restriction.
Why simultaneity matters more than the plant that went dark
Coverage led with Braham going offline, and that is the visible, frightening part. It is also the wrong end of the story to fix on. A treatment plant dropping is the outcome. The interesting question is how the same thing landed on thirty-plus utilities in the same window.
Simultaneity at that scale almost never means thirty separate, tailored intrusions. It means many operators share something an attacker can reach and abuse the same way: a common remote-access product, an internet-exposed operator interface, a widely deployed controller with a known weak default, or a managed-service provider that touches all of them. You breach the shared thing once and the same technique repeats across everyone who runs it. So the defensive question for every other utility in the country is blunt: what do these Minnesota systems have in common with mine, and am I running it exposed the same way?
MNIT's own framing points here. John Israel, the state's chief information security officer, said the systems shared common characteristics, including their timing, methods of access and the type of infrastructure targeted, and that the pattern matched activity federal partners have seen in other states. That is the language of one repeatable method, not thirty coincidences.
The plant is the last link, not the first
Water and wastewater control gear (the programmable logic controllers and operator screens that actually move valves and dose chemicals) rarely sits naked on the internet waiting to be typed at directly. When it gets touched, the attacker almost always arrived through something more ordinary first: a remote-access tool a contractor uses, an engineering workstation, a historian or SCADA server running plain Windows, a VPN, or a flat network with no boundary between the business side and the plant floor.
That matters for detection, because the control device going dark is the final event in the sequence. Before it, on the systems that bridge business IT and the plant, there is noise you can see: a new remote login at an odd hour, a fresh account or service, credentials being reused across machines, a management tool reaching hosts it never touched before. Those bridge systems are ordinary servers and workstations. You can watch them. The controller you often cannot instrument at all is downstream of the part you can.
This is the same lesson we keep landing on with edge appliances and gateways: the fix and the knowing are two different jobs. We made the point on Ivanti Sentry, where patching the gateway still left you owing a hunt for whoever was already inside, and again across a week of most-exploited bugs where the patch was the easy part. Water utilities inherit the same shape, just with a physical process at the end of it.
CISA says isolate the OT. That is a circuit breaker, not detection.
Alongside the response, the standing federal guidance is to isolate key operational-technology systems so a plant can keep running during an attack. That advice is sound and it saved service here: several utilities dropped to manual operation and kept the water safe.
But isolation is a last resort you reach for once you already know you are hit. Pulling the plant onto manual trades automation for safety; it is the emergency brake, not the smoke alarm. It does nothing to tell you an intruder is on the engineering workstation right now, quietly, before anything trips. The goal is to see the intrusion on the IT side early enough that you are choosing to isolate on your terms, not discovering it because a controller stopped answering. Detection buys you that window. Isolation spends it.
Who did it is still open, and worth stating carefully
No one has claimed the attack and officials have not attributed it. Security firm Tenable noted that the timing and operational pattern were, in its analysis, consistent with the broader CyberAv3ngers activity set and other groups it links to Iran's Islamic Revolutionary Guard Corps, while stressing the incident remains officially unattributed. Treat that as a researcher's read, not a finding. CyberAv3ngers has a documented history, per CISA advisories, of hitting exposed water-sector controllers that run default or weak credentials, which is one more reason the shared-exposure theory is worth taking seriously, but the honest status today is that the responsible party is unconfirmed and the investigation was still active as of July 29.
Small utilities are the archetypal no-SOC target
A town water system is exactly the profile attackers prefer for a mass sweep: critical function, minimal IT staff, a flat network, and remote access set up years ago for a contractor or an after-hours callout. The same constraints that make a full-time security team impossible are what leave the bridge systems unwatched. That is the gap this incident exposes, and it is not a Minnesota gap. Thousands of community water systems across the country fit the same description.
You do not close it by asking a two-person utility to staff a night shift of analysts. You close it by putting detection on the systems that matter (the Windows and Linux hosts, the engineering workstations, the servers that bridge to the plant) and having someone watch the alerts who is not that two-person utility. That is the case for managed detection as a category: alerts mapped to attacker behavior, on the IT layer where the early signal lives, without the customer having to run a security operations center. Suriq is built for exactly that host-and-server layer; it does not instrument the controllers themselves, and no honest vendor should tell a water operator otherwise. The value is catching the intrusion on the bridge before it reaches the process.
What a utility does first
Start with the shared-exposure question, because that is where a repeatable attack repeats. Inventory every path into the plant network from outside: remote-access and remote-management tools, VPNs, vendor connections, any operator interface reachable from the internet. Get them behind authentication that is not a shared or default password, and off the public internet where they do not need to be there. Then turn on and centralize logging for the bridge hosts (the engineering workstations, historians, and SCADA servers running ordinary operating systems) and get eyes on new remote logins, new accounts, and lateral movement between them. If you cannot watch those yourself, that is the specific thing to hand to a managed detection provider this month. Keep the isolation runbook current as your fallback, but do not mistake it for early warning. It is what you do after the alarm, and right now most small utilities have no alarm.