Attackers who change a PLC's password and IP address are not causing an outage. They are taking a kind of control that survives the outage. Across the more than 30 Minnesota water utilities hit, reporting suggests many cannot prove their own recovery records are still authoritative.
The Week's Signal
Braham, Minnesota (population roughly 1,700) lost its water treatment plant for about two hours on July 27, 2026. Public works crews got it running again manually. What the broader campaign leaves open, for Braham and other affected utilities alike, is whether anyone can still point to an authoritative, unaltered copy of the control logic that ran it.
Braham was one of more than 30 Minnesota community water systems hit by coordinated activity against their operational technology on July 26 and 27. Minnesota IT Services confirmed the intrusion on July 28 and activated incident response, coordinating with state and federal partners. By July 29, reporting had named four affected cities specifically: Braham's plant went fully offline and the city asked residents to minimize water usage; Plymouth disconnected its cellular-connected equipment as a containment step; South St. Paul and Maple Plain reported plant outages, communications failures, or affected automated controls, though public detail on those two sites remains limited.
On July 30, the FBI and EPA issued a joint public service announcement: malicious actors were remotely accessing internet-exposed Rockwell Automation MicroLogix 1100 and 1400 programmable logic controllers (PLCs) and changing their IP addresses and passwords, "resulting in a loss of monitoring and control functionality." The same alert noted that one affected organization discovered modified PLC project files after engineers spotted discrepancies in the ladder logic itself. Operational consequences reported across the campaign included pressure loss and flooding. CISA published its own, separate sector alert the same day, urging utilities to disconnect PLCs from direct internet exposure and route remote access through a VPN or gateway device instead. The following day, CISA went further, urgently requesting that water plants nationwide remove exposed control equipment, and linking the campaign's characteristics to an April 2026 advisory on Iranian-affiliated exploitation of internet-exposed PLCs.
The exposure did not close on disclosure. Secondary coverage on August 3 reinforced and recapped the July 30 PSA's findings, without FBI or EPA adding new confirmed detail beyond what the original alert already covered. That same day, Forescout independently scanned for exposed Rockwell PLCs and found 4,407 worldwide, 2,844 of them in the United States, including 22 in cities that had already been hit, 19 of which shared the same mobile carrier network. By August 6, at Black Hat, Acting CISA Director Nick Andersen said federal officials were still finding water-system PLCs online with default passwords or no passwords set at all, and that roughly a dozen states had by then reported related activity, up from the "at least seven" the FBI cited on July 30. The FBI/EPA alert page itself was still being updated as of August 6, per its own last-modified metadata, rather than superseded by a distinct August 3 document.
The Incident Ledger
Braham. Initial access is undocumented at the device-specific level; no source reviewed documents Braham's exact entry path. What sector-wide FBI/CISA reporting establishes is that the broader campaign moved through internet-facing MicroLogix PLCs reachable without the access controls FBI/EPA guidance assumes. Treat the mechanism as campaign-level inference applied to Braham, not a site-specific finding. Impact: password and IP address reset, loss of monitoring and control, well and treatment plant offline for approximately two hours. Response: public works crews restored operation manually; the city asked residents to minimize water use while service was reestablished.
Plymouth. The city's response is the more informative data point here: staff disconnected cellular-connected equipment on detecting anomalous activity, a containment step that assumes the cellular path was itself part of the exposed surface, consistent with Forescout's later finding that a cluster of exposed devices in affected cities shared a common mobile carrier network.
South St. Paul and Maple Plain. Both reported plant outages, communications failures, or affected automated controls in the July 29 reporting that first named them. Neither city has published a phase-level account of entry or recovery as of this writing; treat their inclusion here as confirmation of scope, not as evidence for the mechanism section below.
An unnamed utility, per the July 30 FBI/EPA PSA. At least one affected organization found its PLC project files had been altered (not just credentials, but the ladder logic controlling the process) and only noticed because engineers spotted discrepancies during review. FBI/EPA reporting does not identify which of the 30-plus affected utilities this was.
Why This One Matters
Most coverage of this campaign reads as a story about exposure: default passwords, internet-facing PLCs, a sector that still hasn't segmented OT from the public internet. That part is true, and confirmed twice over: by CISA's own July 30 alert and by Forescout's August 3 scan, which was still finding exposed devices in already-hit cities just four days after the first federal warning.
The more consequential finding sits inside Rockwell's own recovery guidance, not in the attack itself. Restoring a locked-out MicroLogix 1400 requires a current offline copy of the controller's project file. CSOonline's reporting on August 4 found that many of the small utilities in this campaign could not produce one. If an attacker altered the project file before locking an operator out, and the utility's last saved backup predates that change, the attacker is now holding a more current record of how the plant is configured to run than the utility itself is. That is not a disruption problem. It is an evidence problem, and it does not resolve when the water comes back on. The board gets a boil-water notice. The operator gets a Rockwell recovery procedure the utility cannot complete, because the "before" state it depends on no longer exists anywhere the utility controls.
The Mechanism
The mechanism here is unglamorous, which is part of what makes it repeatable at this scale. Every documented entry point in FBI and CISA reporting is a PLC reachable directly from the public internet, a category Forescout's August 3 scan still found more than 4,400 live examples of worldwide, 22 of them in cities already hit. CISA's own Black Hat remarks on August 6 describe finding these devices protected by default credentials or no password at all, though that is a description of the broader sweep's findings, not a confirmed statement of the entry vector at every site in this specific campaign.
Once inside, the FBI's July 30 alert is specific about what changed: attackers reset device passwords and altered IP addresses, an action that by itself locks out the legitimate operator. The alert's own phrase for the result is "a loss of monitoring and control functionality": both visibility into the process and the ability to act on it. At least one affected organization experienced something further: the same July 30 FBI/EPA PSA describes modified PLC project files, discovered only because engineers noticed the ladder logic itself no longer matched what they expected. That is a change to the control program, not just to the credentials guarding it. It is the detail that makes Rockwell's offline-backup recovery requirement the operative constraint for whoever has to clean this up.
Analytical ATT&CK Mapping
The Prevention Gap
None of this required a zero-day. It required a device that should not have been reachable from the internet, credentials that were never rotated, and a recovery plan that assumed the utility's last saved project file was still the authoritative one. Every one of those is a control most water utilities would say exists: a segmentation policy, a password rotation schedule, a documented recovery procedure. What the Minnesota campaign tested (whether the attacker intended it as a test or not) is whether those controls were true in practice on July 26, not whether they were written down somewhere. A tabletop exercise confirms the recovery plan exists on paper. It does not confirm that the on-file project backup is more recent than the version an attacker is about to overwrite, and this campaign is the evidence that gap is not theoretical.
What To Do Before The Next One
This is not, despite the coverage, only a United States story. Singapore's Cybersecurity Act designates water among the sectors it treats as Critical Information Infrastructure under CSA oversight, and Hong Kong has its own critical-infrastructure regime covering comparably essential sectors, though this issue has not verified its exact provisions closely enough to draw a direct comparison. A regulated water or energy operator in either jurisdiction reading this as an American incident is reading it too narrowly. Rockwell MicroLogix controllers, default-credential exposure, and internet-facing OT are not geography-specific: Forescout's own scan found exposed instances of these devices worldwide, not only in the states the FBI named.
Three things worth doing before the next version of this story breaks somewhere else:
First, know which of your internet-facing OT and IT assets are actually reachable from the public internet right now, not which ones were reachable at the last annual audit. This is the specific gap this campaign exploited repeatedly: Forescout was still finding newly exposed PLCs in cities that had already been publicly attacked, just four days after the FBI's first alert. HELIOS approaches this as continuous external asset discovery, mapping internet-facing infrastructure and flagging changes to that exposure on a minute-level cadence. It answers the honest, narrower question of which devices are visible to the internet and when that changed. It does not answer whether your defenses would hold if one of them were already exposed; that is a validation question this issue's incident does not resolve either.
Second, verify that offline project-file and configuration backups are actually current, and stored somewhere an attacker who reaches the PLC cannot also reach. CSOonline's reporting found many of the small utilities in this campaign could not produce a current offline backup, which is the difference between a two-hour outage and a recovery timeline nobody can put a bound on.
Third, treat "we have a recovery procedure" and "we have tested that the recovery procedure works against the state we're actually in today" as two different claims, and ask which one your last tabletop exercise actually confirmed.