12 minhigh
Review of the July 2026 Cyberattacks Against U.S. Water and Wastewater Systems
A coordinated cyber campaign in July 2026 targeted operational technology at more than 30 Minnesota community water systems and related facilities in at least seven U.S. states. Attackers accessed internet-facing Allen-Bradley MicroLogix 1100/1400 PLCs, changed device IP addresses and passwords to lock out operators, and modified ladder logic, causing loss of water pressure, flooding, and reliance on manual operations. The campaign shares technical characteristics with an Iranian-affiliated PLC-targeting operation documented in Joint Cybersecurity Advisory AA26-097A, but attribution remains unconfirmed. Concurrent pro-Russian hacktivist activity (NoName057(16) and Z-Pentest) targeted Canadian water systems, demonstrating that multiple actor types are exploiting exposed OT infrastructure using legitimate engineering tools rather than advanced ICS malware.
Sens:■ Immediate
Detection / Hunteropenrouter
What Happened
In late July 2026, a coordinated series of cyberattacks targeted the computerized control systems of more than 30 community water systems in Minnesota, with similar attacks reported in at least seven U.S. states. The attackers gained remote access to internet-exposed industrial controllers (devices that operate pumps, valves, and treatment equipment), changed their passwords to lock out legitimate operators, and modified the programming that controls how these systems work. This caused real-world effects including loss of water pressure, flooding, and the need for some communities to rely on stored water and manual operation. No drinking water contamination was confirmed. The attacks did not require sophisticated malware — instead, the attackers exploited devices that were directly accessible from the internet with weak or default security settings. Similar attacks were claimed by pro-Russian hacktivist groups against Canadian water facilities around the same time. Water utilities should immediately remove internet exposure from control devices, strengthen remote access security, verify the integrity of their control programming, and ensure they can operate facilities manually if automated systems are compromised.
Key Takeaways
- Coordinated campaign targeting 30+ Minnesota community water systems on July 26-27, 2026, with related incidents confirmed in at least 7 U.S. states including Michigan
- Attackers exploited internet-facing Allen-Bradley MicroLogix 1100/1400 PLCs without advanced ICS malware, using legitimate engineering software and insecure configurations to modify ladder logic and lock out operators
- Physical impacts included loss of water pressure, flooding, disrupted cellular telemetry, and extended manual operation; no confirmed drinking water contamination occurred
- Attribution remains incomplete — technical similarities to Iranian-affiliated campaign (Joint Cybersecurity Advisory AA26-097A) provide a credible hypothesis, but pro-Russian hacktivists NoName057(16) and Z-Pentest also claimed water-sector attacks in Canada during the same timeframe
- Dark web communities are circulating legitimate PLC training courses, engineering software, and leaked project files, lowering the barrier to entry for opportunistic actors targeting exposed OT systems
Affected Systems
- Rockwell Automation Allen-Bradley MicroLogix 1100 PLCs
- Rockwell Automation Allen-Bradley MicroLogix 1400 PLCs
- Rockwell Automation CompactLogix controllers
- Rockwell Automation Micro850 controllers
- Schneider Electric BMX P34 devices
- Schneider Electric Modicon M340 devices
- Siemens S7-1200 PLCs
- Unitronics PLC and HMI devices
- Cellular modems and remote telemetry units
- HMI and SCADA systems with internet exposure
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attackers identify internet-facing PLCs (MicroLogix 1100/1400) and cellular modems with weak or absent authentication, often sharing common third-party network configurations across multiple victims
- Credential Manipulation: Attackers remotely access exposed PLCs and change device IP addresses and passwords, preventing operators from viewing, monitoring, or controlling connected equipment
- Logic Modification: Using legitimate engineering software (Studio 5000 Logix Designer, EcoStruxure Control Expert, TIA Portal), attackers modify or delete PLC project files including ladder logic, Add-On Instructions, and function blocks
- Impact: Modified control logic disrupts water pressure, pump operations, and telemetry; critical alarms and shutdown logic are disabled; malicious logic may preserve appearance of normal operation while overriding safe operating parameters
- Defense Evasion: Attackers use leased third-party infrastructure and standard industrial protocols (TCP 44818, 2222, 102, 502) to blend with legitimate OT traffic; Dropbear SSH used on victim modems for remote access
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article does not provide specific detection rules, queries, or signatures. It references Joint Cybersecurity Advisory AA26-097A as a source of additional technical indicators and recommends monitoring OT protocol ports (TCP 44818, 2222, 102, 502) and SSH (port 22) for anomalous connections.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The attacks primarily target PLCs, HMIs, and cellular modems — embedded OT devices that typically do not support EDR agents. Visibility depends on network-based OT monitoring rather than endpoint telemetry. Engineering workstations used to interact with PLCs may have some EDR coverage, but the core malicious activity occurs on the OT device layer. |
| Network Visibility | Medium | OT protocol traffic on ports 44818 (EtherNet/IP), 2222, 102 (PROFINET), and 502 (Modbus TCP) could be monitored with OT-aware network sensors or IDS. SSH traffic on port 22 to cellular modems is also detectable. However, distinguishing legitimate engineering access from malicious interaction requires baseline knowledge of authorized connections, expected source IPs, and normal protocol usage patterns. |
| Detection Difficulty | Hard | Detecting malicious PLC interaction requires OT-specific monitoring tools, knowledge of legitimate engineering workflows, and baseline understanding of expected protocol traffic. Many water utilities lack dedicated OT network monitoring. The use of legitimate engineering software and standard industrial protocols makes it difficult to distinguish attacker activity from authorized maintenance without strong identity controls and session logging. |
Required Log Sources
- OT network flow data (ports 44818, 2222, 102, 502, 22)
- PLC audit logs and configuration change logs
- HMI access and authentication logs
- Cellular modem access and connection logs
- Firewall and VPN appliance logs for remote-access paths
- DNS logs for connections to unfamiliar hosting providers
- Engineering workstation process execution logs
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for inbound connections to OT protocol ports (44818, 2222, 102, 502) from external or unfamiliar IP addresses, particularly hosting provider ranges, as this may indicate unauthorized access to exposed PLCs. | Network flow data, firewall logs, OT IDS/IPS alerts | Initial Access | Medium — legitimate remote maintenance or vendor access may generate similar traffic patterns; correlate with approved access windows and known integrator IPs. |
| Consider hunting for PLC password changes, IP address changes, or project file uploads/downloads outside of scheduled maintenance windows, as these were key attacker actions in the July 2026 campaign. | PLC audit logs, HMI event logs, engineering workstation application logs | Execution | Low to Medium — legitimate configuration changes should be tied to change management records; unexpected changes warrant investigation. |
| Consider hunting for SSH connections to cellular modems or RTUs, particularly using Dropbear SSH, as this was identified as an attacker remote-access method on victim infrastructure. | Network flow data, firewall logs, modem management logs | Persistence | Low — SSH to cellular modems is uncommon in normal operations and should be investigated unless explicitly authorized. |
| Consider hunting for modifications to PLC ladder logic, Add-On Instructions, or function blocks that disable alarms or shutdown logic, as these represent high-risk tampering with safety systems. | PLC project file comparison tools, engineering workstation file integrity monitoring, HMI alarm configuration logs | Impact | Low — changes to alarm or shutdown logic should be rare and always documented; any undocumented change is suspicious. |
| Consider hunting for multiple water utilities sharing identical firewall rules, modem configurations, or credential patterns, as the FBI identified common third-party configurations across multiple victims enabling scalable attacks. | Configuration management databases, firewall rule audits, vendor documentation | Initial Access | Low — shared configurations across utilities represent a systemic risk that should be identified and remediated regardless of active threats. |
Control Gaps
- Traditional IT firewalls and IDS may not inspect or understand OT protocol traffic on ports 44818, 2222, 102, and 502
- EDR agents cannot be deployed on PLCs, HMIs, or cellular modems, leaving the core attack surface without endpoint telemetry
- Network segmentation between IT and OT environments may be insufficient, allowing direct internet paths to PLCs
- Authentication on legacy PLCs (e.g., MicroLogix 1100/1400) may be too weak to prevent unauthorized access even when detected
- Third-party integrator access may bypass organizational identity controls if shared credentials or identical configurations are used across multiple customer sites
- Lack of PLC project file integrity monitoring means logic modifications may go undetected until operational anomalies appear
Key Behavioral Indicators
- Inbound connections to OT protocol ports from external IPs or unfamiliar hosting providers
- PLC password or IP address changes outside of authorized maintenance windows
- Unexpected project file uploads or downloads to PLCs
- Controller mode changes (Run to Program/Remote) without corresponding change management records
- SSH connections to cellular modems, particularly using Dropbear SSH
- Disabling of critical alarms or shutdown logic in PLC programs
- Multiple sites sharing identical firewall rules, modem configurations, or credential patterns from the same third-party integrator
- Engineering workstation processes (Studio 5000, EcoStruxure, TIA Portal) executing from unexpected network locations or outside business hours
False Positive Assessment
Medium — Detecting malicious PLC interaction requires distinguishing it from legitimate engineering and maintenance activity. OT protocol traffic, project file uploads, and configuration changes are normal during authorized maintenance windows. Without strong change management records, approved-access lists, and baseline traffic patterns, false positives are likely. However, specific indicators such as SSH to cellular modems, password changes outside maintenance windows, and disabled alarm logic have lower false positive rates.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting — consider immediately removing direct internet exposure from all PLCs, HMIs, RTUs, cellular modems, and engineering workstations by reconfiguring firewalls or disconnecting public IP mappings.
- Consider changing all default, shared, weak, or previously exposed credentials on PLCs, HMIs, modems, and remote-access accounts; enforce unique credentials per device and account.
- If your OT environment uses third-party integrators, consider auditing all remote-access paths, VPN connections, cellular services, and privileged accounts to identify shared configurations or exposed credentials.
- Consider verifying the integrity of PLC project files and running logic against known-good engineering backups, focusing on ladder logic, Add-On Instructions, alarms, shutdown logic, and network settings.
- If applicable, consider placing controller mode switches in the Run position and enabling software-based programming protection to prevent unauthorized logic modifications.
Infrastructure Hardening
- Consider implementing hardened VPN, jump host, or Zero Trust access platforms for all required remote access to OT systems, with multifactor authentication and session logging.
- Evaluate whether IT and OT environments are properly segmented through industrial firewalls and controlled DMZ zones; engineering workstations should not have unrestricted internet access.
- Consider disabling unused services on OT devices including Telnet, FTP, RDP, VNC, unnecessary web administration, and SSH where not required.
- Consider restricting industrial protocol traffic to approved source-destination pairs using OT-aware firewall rules or access control lists.
- Where legacy or end-of-life PLCs cannot be immediately replaced, consider implementing compensating controls such as network isolation, gateway-mediated access, strict allowlisting, and enhanced monitoring with a defined retirement date.
User Protection
- Consider replacing standing remote-access arrangements with time-limited, approved access that requires explicit authorization for each session.
- If your EDR supports host isolation, consider pre-staging isolation procedures for engineering workstations that have access to PLCs in case of suspected compromise.
- Consider maintaining and testing the ability to manually operate wells, pumps, valves, lift stations, and treatment processes when automation or telemetry is unavailable.
Security Awareness
- Consider incorporating OT-specific incident response scenarios into existing training and exercise programs, including safe isolation of affected equipment, transition to manual operation, and coordination with public health authorities.
- Consider briefing operators, engineers, and IT staff on the indicators of PLC compromise (unexpected password prompts, IP changes, alarm behavior changes, ladder logic discrepancies) and the escalation path for reporting them.
- Consider including dark web monitoring for utility names, domains, remote-access systems, PLC families, engineering software, and project files in existing threat intelligence programs; findings involving controller addresses or screenshots of live control systems should be treated as high-priority.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping10 techniques
Tactic
Initial Access
Tactic
Execution
Tactic
Credential Access
Tactic
Lateral Movement
Additional IOCs
- Other:
ProfitServer- Russian hosting provider identified as C2 infrastructure for a custom PLC backdoor called 'FreePalestine' referenced in a dark web forum post by alias DarkSenator; not a direct IOC but a hosting provider name for infrastructure pivot