What happened
On Saturday, August 1, Michigan officials said cyberattacks had affected nine water systems. Officials reported that the systems continued operating safely, local operators addressed the issues and no known impact posed a public-health concern. That disclosure followed malicious activity involving operational technology at more than 30 Minnesota water systems. Minnesota officials stressed that confirmed malicious activity did not mean every affected community lost service, although Braham temporarily relied on stored water after operating controls for its well and treatment plant were shut down.
The July 22 update to joint advisory AA26-097A expanded observed targeting beyond Rockwell Automation and Allen-Bradley controllers to Schneider Electric, Siemens and potentially other PLC manufacturers. The advisory describes access through internet-exposed controllers using legitimate engineering software, extraction of controller project files, changes to PLC logic and manipulation of HMI or SCADA displays. It identifies CompactLogix, Micro850, Modicon M340 and Siemens S7-1200 devices in the wider campaign context.
Attribution posture: U.S. agencies attribute the wider PLC campaign to Iranian-affiliated APT actors, while the FBI has not publicly attributed the Minnesota and Michigan incidents. The cited incident reporting did not publish utility-specific IP addresses, hashes, filenames or controller images for the Minnesota and Michigan cases. That distinction matters: the government campaign attribution supports urgent hunting, but it does not establish that every newly reported utility incident has the same operator or identical technical path. The government advisory publishes 135.136.1.133, 185.82.73.162, 185.82.73.164, 185.82.73.165, 185.82.73.167, 185.82.73.168, 185.82.73.170 and 185.82.73.171 for historical investigation. The published hunt scope includes inbound traffic on ports 44818, 2222, 102, 22 and 502.
Why this matters now
The weekend expansion removes the comfort of treating the Minnesota activity as a single-state or single-provider problem. Water utilities frequently combine legacy controllers, cellular connectivity, vendor engineering access and limited local security staffing. The same operating model also appears in energy, manufacturing, facilities management and distributed infrastructure, so enterprise leaders should examine their own controller exposure and the resilience of utilities supporting critical sites.
Direct internet exposure is the central decision variable. The advisory describes accepted connections made with vendor configuration tools rather than dependence on one newly disclosed software vulnerability. A controller can therefore be current on patches yet remain exposed through insecure architecture, weak authentication or an unnecessary programming mode. Patch dashboards alone cannot demonstrate that project files, alarm logic, shutdown functions or displayed process values remain trustworthy.
For dependent enterprises, public statements that water quality remained safe do not close continuity risk. A short controller outage, loss of trusted telemetry or forced manual operation can still affect production, healthcare, logistics and facilities. CISOs should require procurement and continuity teams to identify critical utility dependencies and obtain scoped assurance rather than assuming public utilities sit outside enterprise risk governance.
The decision for security leaders
Assign a joint OT exposure and integrity review rather than a conventional vulnerability sweep. OT engineering should own safe controller-state verification; security should own external exposure discovery, telemetry review and evidence preservation; operations should own manual-running limits and safety consequences. Every exception allowing remote programming must identify its business owner, compensating controls and expiry.
Separate prevention from compromise assessment. Removing a controller from the internet prevents further direct access but does not prove that its project file, reusable code, credentials or connected engineering workstation remains clean. Require comparison with known-good offline logic, review remote-access records and investigate changes to programming mode, project files, alarms or shutdown functions.
Treat utilities and remote facilities as a portfolio decision. The CISO and continuity executive should prioritise sites where controller loss could halt regulated production, patient care or other safety-critical activity. Where local operators cannot supply evidence quickly, record the assurance limitation and establish temporary monitoring, isolation or operational restrictions.
Evidence of closure
- External scanning proves no controller administrative interface is directly reachable.
- Controller project files match an approved, cryptographically recorded baseline.
- Historical log review documents disposition for every published indicator match.
- A witnessed test demonstrates safe manual operation without remote control services.
The Security.io assessment
The strongest confirmed weekend change is geographic expansion: nine Michigan systems joined a cluster already exceeding 30 Minnesota systems. Reported public-health impact remained limited, but the observed ability to interfere with operating controls makes this a resilience event, not merely a scanning campaign. The absence of utility-specific artefacts prevents a claim that every case is technically identical.
Government attribution is stronger for the wider PLC campaign than for the newly reported state incidents. Security teams should use the published campaign infrastructure and behaviours as hunt inputs without treating an indicator match as automatic proof of attribution. Conversely, a clean search for eight historical IP addresses cannot prove absence of compromise because legitimate engineering tools and other infrastructure can provide the same mechanical access.
Closure requires architecture and integrity evidence. A credible Monday position includes proof that no controller interface is directly reachable, controller logic matches an approved baseline, remote engineering paths are mediated and monitored, and operators can sustain safe service manually. Any organisation unable to produce those artefacts should report an open resilience exposure rather than a completed patch task.
Questions for the morning meeting
- Which sites still require direct remote access to controllers?
- Who can independently verify the integrity of deployed control logic?
- How long can each facility operate safely without remote management?
- Are small utility dependencies represented in continuity planning?