Experts got Claude to port a PLC exploit, but it cost $536 and 8 hours, and a later AI-generated payload accidentally destroyed the hardware.

Forescout researchers just answered a question that’s been hanging over industrial security for a while: can AI actually port a working exploit from one PLC to a different model with no source code and no debugger access? Their report says yes, but the answer comes with a price tag, a lot of researcher hand-holding, and a permanently destroyed piece of hardware.

The starting point was CVE-2021-31886, a pre-authentication buffer overflow in the Nucleus FTP server that the team had already exploited on a WAGO 750-852 PLC in earlier research. The goal this time was porting that working exploit to a related but distinct model, the WAGO 750-831, using Claude Code with access to a terminal, Ghidra, and the actual physical device.

“The exploit depended on target-specific parameters, including function addresses, offsets, and memory locations. Our goal was to use AI to port the exploit to a similar, but not identical PLC model: the WAGO 750-831. Beyond simply porting the existing RCE, we also wanted to test whether AI could help extend it into a more capable command-and-control implant on the constrained PLC.” reads the report. “We began this research with three inputs:

• The working RCE exploit for the WAGO 750-852 PLC.
• A firmware binary file for the other PLC, the WAGO 750-831 (V01.04.16), which the original security advisory flagged as vulnerable.
• A physical WAGO 750-831 PLC running that firmware.”

This was a much harder task than the software exploits AI has handled before. Working with embedded firmware is difficult when there’s no source code and no debugger to help explain what’s happening.

Finding the vulnerability took a few attempts, but it wasn’t the hardest part. Claude tested the live FTP server, analyzed the firmware with Ghidra and wrote its own Python scripts to help with the analysis. It eventually crashed the PLC, confirming that the buffer overflow could be triggered.

The real challenge was going from a crash to actually running attacker-controlled code. That required much more work, and progress slowed down at that point.

The turning point came when Claude figured out why its injected shellcode kept disappearing before it could run. Normal FTP command processing was zeroing out the exact memory buffer holding the malicious payload right after the login command completed, and the fix meant deliberately avoiding that normal completion path entirely.

“Claude determined that the exploit path could preserve the shellcode by avoiding the normal command-completion path. Omitting the ‘\r\n’ (CRLF) terminator prevented the relevant processing path from completing in the usual way, leaving the attacker-controlled buffer intact.” continues the report. “Claude then created a test harness that measured PLC uptime after each exploit attempt. The device consistently crashed at the same point regardless of the injected payload, indicating that execution was failing before the payload itself could influence the outcome. This supported the hypothesis that the shellcode was being overwritten during normal FTP processing rather than executed.”

Claude got there with heavy guidance but got there nonetheless.

Once Claude solved that specific problem, things moved much faster. In just 12 minutes, it went from a harmless test payload to two working exploits: one made the PLC send ICMP pings to a remote machine, while the other sent a UDP packet containing the word “PWNED.”

Most of the time and effort went into solving the target-specific issue that was preventing the payload from running. After that, generating the working exploits was relatively easy.

The process still required a lot of time and money. The final exploit-development stage cost $535.74 in API fees during an 8-hour, 32-minute session, and the researchers had to guide Claude through several dead ends, provide disassembly details and switch to a larger context model when the smaller sessions ran out of space.

“The final RCE development stage consumed $535.74 in API usage, based on 2.6k input tokens and 1.3M output tokens. The corresponding session lasted 8 hours, 32 minutes, spread across several days of research. Most of that time was spent identifying the buffer-preservation issue associated with the FTP command-processing path.” states the report. “After achieving the initial RCE, we opened a new Claude Opus 4.6 session to explore whether the working ICMP and UDP payloads could be extended into a command-and-control implant. The prompt began: “I have working PoCs for UDP and ICMP beacons, read them and let’s plan a C2 implant on the PLC”.”

So, for now, this isn’t something an inexperienced attacker can simply hand to an AI and expect to work. It still takes expert guidance, substantial time and a not-so-small bill.

The most telling moment of the whole exercise happened after the exploit already worked. Researchers asked Claude to extend the working ICMP and UDP payloads into a full command-and-control implant, and while probing the PLC’s memory layout to build that, one generated payload wrote to a region mapped to flash storage, permanently bricking the device. Nobody told Claude to break anything; it was doing exactly what it was asked and still destroyed the hardware in the process, which is a genuinely unsettling data point for anyone imagining more autonomous AI agents operating against real physical infrastructure with less supervision.

The biggest finding here may not be that Claude successfully ported the exploit, but how fragile the process still is. Forescout also points to real incidents where attackers disrupted U.S. water utilities by abusing internet-exposed PLCs directly, without needing a sophisticated exploit.

That should still concern defenders. If AI keeps reducing the time, cost and expertise needed to develop more advanced attacks against PLCs, the idea that industrial systems are simply too difficult to hack may not hold for much longer. For now, the research shows that AI still needs expert guidance, but that gap could narrow as the technology improves.

“Recent attacks against internet-facing PLCs show that exposed controllers already create operational risk, even without the kind of RCE developed in this research. The concern is that AI could make more sophisticated exploitation easier to reproduce across those exposed devices. Today, that still requires specialist knowledge and time. But if AI continues to reduce both, vulnerabilities that once looked too difficult or uneconomical to exploit may deserve a different level of attention.” concludes the report. “For critical infrastructure organizations, the immediate implication is simple: do not dismiss vulnerabilities on OT devices merely because exploitation appears difficult today.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, PLC exploit)

CISA urges water utilities to find and secure internet-exposed PLCs after July attacks showed how easily exposed industrial systems can be compromised.

Over 100 internet-exposed systems in the US water and wastewater sector got hit by cyberattacks in July 2026, and CISA’s response wasn’t just an incident report, it was a how-to guide for making sure it doesn’t happen to you next. The agency’s exposure reduction guidance, published August 21, walks through exactly how organizations can find their own internet-facing weak points before an attacker does.

The pattern behind the July attacks was surprisingly simple. Most of the affected systems were programmable logic controllers (PLCs), small industrial computers that control pumps and valves. Many connected directly to cellular modems and had no firewall or gateway between them and the internet. CISA warns that this type of setup can expose PLCs to serious security risks.

“Directly connecting PLCs to the internet through cellular modems can create significant security risks. However, internet exposure reduction does not mean disabling necessary remote access; organizations should remove remote access when it is unnecessary and secure it when it is necessary.” states CISA.

Hackers remotely accessed exposed PLCs, changed device IP addresses and passwords, and in some cases disabled shutdown processes and alarms, creating what CISA called unsafe conditions without notifying the operators running the actual equipment. Iran is the suspected actor behind much of this activity, likely tied to the ongoing war involving the US and Israel, though officials have stopped short of a formal attribution.

CISA presents reconnaissance as an ongoing process. Organizations need to know which systems they expose to the internet and can use tools such as Shodan, Censys, or CISA’s Cyber Hygiene Vulnerability Scanning service to check their own IP ranges from the outside.

The review should also cover ports used by industrial systems. Besides SSH, RDP, and HTTP, CISA highlights protocols such as Modbus, EtherNet/IP, DNP3, BACnet, and OPC UA. Finding one of these ports open does not automatically mean the system has been compromised, but it does indicate an exposure that needs to be investigated and addressed quickly.

Where remote access is genuinely necessary, CISA’s advice is to route everything through a secure, centrally managed gateway rather than connecting straight to a PLC, HMI, or remote terminal unit. Pair that with phishing-resistant multi-factor authentication, unique credentials instead of shared defaults, and active monitoring of traffic in and out, and you’ve closed most of the gap that let this particular wave of attacks succeed in the first place. None of this is exotic security engineering; it’s the same basic hygiene that’s been recommended for years, just finally getting attention because attackers are actually using the gap.

This isn’t an isolated incident CISA is responding to reactively, either. The water sector attacks sit inside a much larger pattern of nation-state interest in US and allied critical infrastructure, from China’s Volt Typhoon reportedly pre-positioning malware inside American infrastructure as a potential wartime disruption tool, to Russian-linked campaigns testing water and energy systems across Europe as part of broader pressure on NATO. If a foreign government is willing to spend years quietly waiting inside a power grid, an exposed PLC with a factory-default password isn’t a minor oversight, it’s an open invitation.

“CISA urges all critical infrastructure organizations to route all necessary remote access through a secure gateway, firewall, VPN, or other centrally managed access solution, rather than connecting directly to a PLC, human-machine interface (HMI), or remote terminal unit (RTU).” concludes CISA. “The July 2026 malicious cyber activity targeting WWS Sector entities demonstrates the consequences of directly exposing PLCs to the internet. Threat actors remotely accessed internet-exposed PLCs, changed device IP addresses and passwords, and caused loss of monitoring and control functionality and, in some cases, operational disruptions.”

If you run anything with the letters PLC, SCADA, ICS, or HMI in its job description, this guidance isn’t optional reading for next quarter. Go run the scan today, because the alternative is finding out the hard way that someone else already ran it for you.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Water Utilities)

NSA, CISA, FBI, DOE, and EPA warn of active AI-assisted attacks against Siemens S7 PLCs across US critical infrastructure sectors.

Five U.S. federal agencies issued a joint advisory this week warning of an active hacking campaign against Siemens S7 Series programmable logic controllers. The advisory, CISA AA26-231A, is co-signed by NSA, FBI, DOE, and EPA and covers every S7 generation, from the S7-200 to the S7-1500 F-series safety controllers.

The advisory is direct about one thing from the first paragraph: this is not a theoretical risk.

“The threat actors are conducting reconnaissance and capability development against U.S.-based Siemens PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools. The actors leverage Internet scanning services to find Internet-exposed PLCs running outdated software or that are otherwise poorly protected.” reads the advisory. “The U.S. critical infrastructure sectors most targeted by this threat activity include Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. This is not a theoretical risk—it is an active threat. “

The key detail is how the attackers try to hide their activity. They make their scripts look like legitimate OT monitoring software, making it harder for security teams to notice them while they map the target environment.

The tools themselves are not custom malware. The attackers use the open-source snap7.dll and python-snap7 libraries, which are legitimate industrial automation tools. These libraries can communicate directly with Siemens PLCs over S7comm on TCP port 102, allowing access to PLC memory, configuration data and ladder logic programs.

“Using AI to generate exploitation scripts represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools. In addition, AI enables adversaries to rapidly leverage additional attack vectors and adapt to defensive measures.” continues the advisory. “Threat actors can easily collect public information about vulnerabilities and weaknesses, find exposed and exploitable PLCs, and use AI-generated scripts to act on that information. If PLCs are exposed to the Internet, they are at high risk for exploitation.”

Researchers warn that a defender who patches a vulnerability may now find the attacker’s tooling already adapted before the change window closes.

The observed activity breaks into two phases. Actors use scanning services like Censys and ZoomEye to locate Internet-exposed PLCs, then run read operations to understand the target environment before any writes happen. The authoring agencies assess this as pre-positioning: the actors are building a map and testing their techniques against specific CPU models, refining as they go, before they’re ready to cause disruption.

The target list covers Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. The Defense Industrial Base is also named, given its use of S7-series hardware. If these actors move from read to write, the potential consequences include process disruption, equipment damage, and safety incidents through manipulation of interlocks or emergency shutdown systems, and cascading effects across interconnected supply chains.

The advisory flags third-party exposure as a specific problem. Asset owners who rely on system integrators or managed service providers for remote PLC access may not know their controllers are reachable from the Internet. If an external support partner holds credentials for your S7 devices and you haven’t recently verified that those connections are segmented and monitored, this advisory is a good prompt to check.

There are several clear signs defenders can monitor. They should look for S7comm connections from devices that are not normally used for engineering, PLC read or write activity outside scheduled maintenance, and scans of multiple IP addresses on TCP port 102. It is also worth checking for Python processes loading snap7.dll on systems where it should not be present. Connections from unexpected countries or locations should also raise an alert.

On the mitigation side, the agencies prioritize inventory first, then patching with Internet-facing controllers at the top of the queue. Block TCP port 102 at the perimeter firewall, require password protection on all controllers, configure protection levels to limit what an unauthenticated or low-privilege session can read or write, and deploy ICS-aware monitoring capable of baselining legitimate S7comm behavior. Disabling the PLC web server where it’s not needed and limiting simultaneous S7comm sessions also appear in the guidance, alongside TIA Portal’s know-how protection and complete restart protection features.

The advisory closes by recommending direct engagement with Siemens ProductCERT for model-specific hardening and patch compatibility verification, which matters in OT environments where a firmware update can interact badly with third-party integrations and can’t simply be rolled back.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

Attackers breached a Polish CHP plant through a Fortinet device and private APN, reaching PLCs and disrupting turbine and water treatment systems.

Poland’s CERT has described a second attack on the country’s energy sector, and this one matters for a simple reason: it shows how an ordinary-looking network design can turn into a route into OT. The target was a smaller combined heat and power plant feeding heat to around 50,000 residents, and the attackers used a private APN as the path in, something CERT says it saw for the first time in this incident.

The report says the intrusion began at a wind farm, where the attackers hit a Fortinet VPN and firewall device exposed to the internet.

From there they found a Teltonika cellular router, used SSH to build a tunnel, reached the private APN managed by the distribution system operator, and then moved toward the plant’s OT network.

“On 29 December 2025, coordinated attacks targeted the energy sector in Poland, including 30 renewable energy facilities and a large combined heat and power (CHP) plant. These attacks were described in detail in the report published on 30 January 2026*. At the same time, another incident occurred at a smaller CHP plant supplying heat to 50,000 residents.” reads the report published by Poland’s CERT. “The analysis of this incident took more than three months to complete, which is why it was not included in the initial report. To the best of our knowledge, the attack vector used in this case has not previously been observed in any known incidents.”

Once inside, the attackers found a Wago PLC at the CHP plant and used SSH access on that controller to reach the operational network. After roughly a week of reconnaissance, they connected to Siemens PLCs, switched them to stop mode, and set a password that blocked operators from changing the controllers’ state and control logic.

That is where the physical impact started. The steam turbine and water treatment system shut down, the cogeneration process broke, and the plant lost service continuity for a while, though staff restored the affected systems quickly enough to avoid a heat or electricity outage.

“The attacker then damaged the WAGO controller that had been used as a gateway into the network by corrupting its partition table, preventing it from being read by the device. In an attempt to restore the controller, the affected entity performed a factory reset; however, this did not repair the partition table and the device remained unable to boot.” continues the report. “No valuable logs could be recovered from the device during the investigation.”

The report also shows how messy real intrusions get once the attacker is inside the control environment. Moxa serial device servers and Moxa network switches were reconfigured to block legitimate access, ABB and Schneider Electric variable frequency drives were touched as well, and some connection attempts failed or were only partially successful.

“An important aspect of this architecture is that DSOs require all communication between the DSO’s ICT network and the RTU to take place over a serial protocol, in this case DNP3.0. At the compromised facility, a Teltonika RUTX50 router was used, and the DSO’s requirements were met. However, no requirements had been defined regarding the handling of the cellular router’s administrative interface.” continues the report. “As a result, the router was configured with two physical interfaces: a serial link connected to the RTU and a second interface, Ethernet, connected to a VLAN managed by the central firewall that had been compromised by the attacker.”

That is the uncomfortable part. The attackers did not need some exotic zero-day chain to do damage. They used a reachable edge device, a private APN that was already in the path, weak or exposed access points, and enough patience to move from reconnaissance to disruption.

CERT notes that the attackers damaged some devices while trying to cover their tracks, and in the WAGO case the controller could not be brought back by a simple reset. The agency also says this kind of private APN setup is not rare, which is exactly why the finding matters beyond Poland.

“As maintenance work was being carried out at the facility, the entity initially assumed that the process interruption had been caused by an error made by the contractor’s engineers and reported the event for informational purposes only.” continues the report. “However, due to its awareness of other similar events, CERT Polska initiated incident handling under the assumption that the event may have resulted from a cyberattack. Further analysis confirmed this hypothesis.”

The practical lesson is not subtle. Private APNs, edge routers and OT gateways need the same discipline as any other exposed infrastructure, because once an attacker can pivot from a field device into control systems, the difference between “maintenance” and “incident” gets very thin.

The original report is here: CERT Polska Energy Sector Incident Follow-up Report 2025.

In early 2026, ESET linked a late-2025 cyberattack on Poland’s energy system to the Russia-linked Sandworm APT.

“Based on our analysis of the malware and associated TTPs, we attribute the attack to the Russia-aligned Sandworm APT with medium confidence due to a strong overlap with numerous previous Sandworm wiper activity we analyzed,” said ESET researchers. “We’re not aware of any successful disruption occurring as a result of this attack,” ESET researchers said.

ESET researchers uncovered DynoWiper, a destructive wiper malware used in an attempted cyberattack against Poland’s energy sector on December 29, 2025. While no successful disruption has been confirmed, the malware’s architecture shows clear destructive intent. ESET attributes the operation with medium confidence to the Russia-aligned Sandworm APT group, citing strong overlaps in tactics, techniques, and behavior with previous Sandworm-linked wiper attacks analyzed by the team.

The attempted attack occurred during peak winter demand and coincided with the 10-year anniversary of Sandworm’s 2015 cyberattack on Ukraine’s power grid, the first malware-induced blackout that left around 230,000 people without electricity. ESET tracks the DynoWiper malware as Win32/KillFiles.NMO. Subscribers to ESET’s private Threat Intelligence APT reports have already received further technical details and indicators of compromise to aid rapid detection and incident response. The cybersecurity firm also shared an associated IoC hash for defensive use.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Poland)

After attacks hit 30+ Minnesota water systems, CISA urged utilities to remove internet-exposed PLCs and strengthen OT security.

Between Sunday and Monday, July 26 and 27, a coordinated cyberattack hit operational technology (OT) systems at more than 30 community water utilities across the state, according to Minnesota IT Services (MNIT).

“A coordinated cyberattack targeted operational technology at more than 30 Minnesota community water systems on July 26 and 27. Minnesota IT Services (MNIT) immediately activated the state’s cybersecurity incident response capabilities.” reads the statement published by MNIT. “MNIT continues to collaborate with federal, state, local, Tribal, and private-sector partners to investigate the attack, support affected communities, and strengthen the security of Minnesota’s critical infrastructure.”

The agency activated its statewide incident response the moment it learned of the attack, and it’s still active as of this week.

Four cities went public with details: Braham, Maple Plain, Plymouth, and South St. Paul. Braham took the hardest hit of the group; the town of about 1,700 people had its water plant knocked offline entirely after attackers disabled the computerized controls running its well and treatment systems.

State and federal investigators are working to determine attribution, but the timing is hard to ignore: the attacks came four days after CISA updated its advisory on Iranian-affiliated actors targeting programmable logic controllers across US critical infrastructure. No formal attribution has been made, but Tenable researchers assess the operational pattern is consistent with CyberAv3ngers, an Iran-linked group formally tied to the IRGC.

“Federal and state officials have not publicly attributed the Minnesota attacks to any specific actor. However, the operational pattern is consistent with the CyberAv3ngers threat ecosystem, a state-directed group the U.S. government has formally attributed to Iran’s Islamic Revolutionary Guard Corps Cyber-Electronic Command.” reported Tenable.

CISA now warns of a surge in attacks targeting internet-exposed PLCs at water utilities. Attackers have changed passwords and IP addresses to lock out operators, causing boil water notices and forcing some facilities to switch to manual operations. The US agency urges organizations to remove publicly accessible PLCs and other OT systems from the internet immediately.

“CISA is currently observing a significant increase in cyber threat actors targeting programmable logic controllers (PLCs) in the Water and Wastewater Systems (WWS) Sector. CISA urges critical infrastructure owners, operators, and integrators to remove publicly exposed PLCs and other operational technology (OT) from the internet as soon as possible.” reads CISA’s alert. “Threat actors targeting exposed PLCs have modified passwords to lock out operators and disconnected the PLCs by changing their IP addresses. This activity has resulted in boil water notices and sustained manual operations.”

The FBI confirmed that utility companies in at least seven states have reported PLC-related incidents. The attacks aren’t sophisticated in the traditional sense, after remotely accessing internet-facing devices, the actors changed IP addresses and passwords, resulting in loss of monitoring and control functionality. That’s it. Default or weak credentials on internet-exposed hardware, and suddenly operators are locked out of their own systems.

CVE-2021-22681 is a critical Rockwell Automation vulnerability (CVSS 9.8) that remained unexploited for years because industrial control systems are difficult to patch without disrupting essential services. Since March 2026, however, Iranian-affiliated threat actors have actively exploited the flaw, prompting CISA to add it to its Known Exploited Vulnerabilities catalog. Rockwell has confirmed that no security patch is available, making network isolation and other compensating controls essential.

That last sentence is worth sitting with. A CVSS 9.8 vulnerability in controllers that run public water infrastructure, no patch, actively exploited. The compensating control is network isolation, which is exactly what CISA is now urgently requesting.

“These threat actors are targeting water entities of all sizes. Even water organizations with mature cybersecurity processes should validate their external connections, as this targeting activity includes cellular modems installed by operators, vendors, or system integrators that may not be documented or included in routine attack surface scans.” continues the alert. “OT assets exposed to the internet have an increased risk of defacement, configuration changes, operational disruptions, and, in severe cases, physical damage.”

A July 2026 update to CISA’s advisory found that attacks exploiting internet-exposed PLCs have expanded beyond Rockwell Automation to include Schneider Electric and Siemens devices. The advisory also documents attackers stealing PLC project files for the first time and adds new guidance to detect tampering with reusable code modules embedded in industrial control programs.

Exfiltrating project files means the attacker is taking the engineering logic of the plant, the actual programmed behavior of the industrial process, and studying it offline. That’s reconnaissance for a more targeted future attack, not just disruption for its own sake.

The Minnesota attacks resulted in boil water notices and sustained manual operations at affected utilities. Drinking water remained safe in most cases, and contingency procedures held. But the affected cities include Maple Plain, Braham, South St. Paul, and Plymouthm not isolated rural facilities, but communities of real scale. CyberAv3ngers is known for targeting small water and municipal facilities, which experts believe are among the lowest-hanging fruit in US critical infrastructure. Many small and rural facilities lack dedicated cybersecurity resources. That’s the point. These attacks aren’t about technical sophistication. They’re about finding the organizations with the least capacity to defend themselves and demonstrating that the capability to disrupt public services exists and can be exercised.

CISA’s alert specifically notes that even mature organizations should validate their external connections, because the targeting includes cellular modems installed by operators, vendors, or system integrators that may not appear in routine network scans. A modem installed by a contractor for remote access and never documented in the asset inventory is still an attack surface. The practical checklist is short: get PLCs off the internet, segment OT networks from IT networks, change default credentials, and audit every remote access path, including the ones you didn’t authorize.

“CISA recommends organizations implement the following mitigations:

• Disconnect the PLC from the internet. Remote access for operational purposes should go through a VPN or gateway device, not directly to the PLC.
• Enable password protection and change default passwords.
• Allowlist IPs to only allow remote access from known engineering laptops or other critical OT assets.

After disconnecting PLCs from the internet, operators should ensure they have a known clean backup of the PLC image in case they are locked out by a modified password.” concludes CISA. Note: Owners, operators, and integrators of Rockwell Automation MicroLogix 1400 PLCs should see Rockwell Automation’s IMPORTANT NOTICE: Restoring Access to a MicroLogix 1400 Controller When the Password Is Unknown for guidance addressing this activity.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

Coordinated OT cyberattacks hit 30+ Minnesota water utilities, briefly disrupting one plant. Backup procedures prevented major water service impacts.

Minnesota just had its own live-fire lesson in what happens when someone targets water utilities at scale. Between Sunday and Monday, July 26 and 27, a coordinated cyberattack hit operational technology (OT) systems at more than 30 community water utilities across the state, according to Minnesota IT Services (MNIT).

“A coordinated cyberattack targeted operational technology at more than 30 Minnesota community water systems on July 26 and 27. Minnesota IT Services (MNIT) immediately activated the state’s cybersecurity incident response capabilities.” reads the statement published by MNIT. “MNIT continues to collaborate with federal, state, local, Tribal, and private-sector partners to investigate the attack, support affected communities, and strengthen the security of Minnesota’s critical infrastructure.”

The agency activated its statewide incident response the moment it learned of the attack, and it’s still active as of this week.

Four cities went public with details: Braham, Maple Plain, Plymouth, and South St. Paul. Braham took the hardest hit of the group; the town of about 1,700 people had its water plant knocked offline entirely after attackers disabled the computerized controls running its well and treatment systems.

Crews had the plant back up within roughly two hours, filtering and treating water normally again.

Plymouth got off comparatively easy. The city’s IT team disconnected the cellular-connected equipment at two of its water towers as a precaution, and the issue stayed contained to that cellular-connected equipment, according to the city’s own statement. Most of the affected utilities across the state kept running through backup procedures without ever going offline.

Minnesota IT Services is continuing to investigate the coordinated cyberattack against the state’s water utilities while helping affected operators contain the incident, assess the damage, and restore impacted systems. The agency is sharing threat intelligence and response guidance in coordination with state and federal partners, including the FBI, CISA, the EPA, the Minnesota Department of Health, and local utilities. Authorities are still analyzing the scope of the attack, but there is currently no indication that drinking water safety has been compromised, and no Minnesota community has been advised to change its water use.

MNIT’s chief information security officer, John Israel, put out a statement framing the response as proof the state’s investment in cybersecurity partnerships actually paid off.

“Cyberattacks against critical infrastructure require a coordinated, whole-of-government response,” said Israel. “MNIT is working side by side with our partners to share intelligence, support affected communities, and help utilities restore operations safely while strengthening defenses against future attacks. This incident demonstrates why Minnesota has invested in strong cybersecurity capabilities and partnerships. Our response worked as intended, enabling agencies at every level of government to rapidly coordinate, contain the incident, and help prevent more serious impacts to critical services.”

Partners include a mix of state, local, federal, and Tribal entities now working the case together. That list includes Minnesota’s Department of Health, its Bureau of Criminal Apprehension fusion center, CISA, the EPA, and the FBI, all working alongside the affected utilities directly.

The attack has yet to be attributed, and the investigation is still ongoing. The timing lines up close enough with something else to raise an eyebrow, though: four days earlier, CISA and six other federal agencies had updated a warning about Iranian-affiliated hackers exploiting internet-facing programmable logic controllers made by Rockwell Automation, Schneider Electric, and Siemens, across US water and energy infrastructure broadly. Nobody’s confirmed a link between that advisory and what happened in Minnesota, and it would be premature to draw a straight line between the two just because they landed in the same week.

Minnesota’s health department says it hasn’t seen any city ask residents to change how they use their tap water, which is the detail worth holding onto here. Contingency plans, backup procedures, and manual overrides did what they’re supposed to do at a majority of the affected utilities: nothing dramatic happened, because the boring stuff worked. Sometimes the best cybersecurity story is the one where nobody outside the IT department even noticed.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, water utilities)

US agencies warn Iran-linked actors are targeting internet-exposed water and energy control systems, risking disruption.

Federal agencies updated their cybersecurity advisory this week: Iran-linked actors are inside American water and energy control systems, and they’re not just looking around. They’re changing things.

The updated advisory from CISA, the FBI, NSA, and the Department of Energy says these actors are getting into programmable logic controllers, the small industrial computers that run pumps, valves, and safety alarms. Once inside, they can mess with what operators see on their screens. That’s how you get outages nobody saw coming.

“The authoring agencies urgently warn U.S. organizations of ongoing Iranian-affiliated cyber targeting of internet-connected operational technology (OT) devices, including programmable logic controllers (PLCs).” reads the advisory. “These actions disrupted PLCs across several U.S. critical infrastructure sectors through malicious project file interactions and manipulation of data on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays, resulting in operational disruption and financial loss.”

This isn’t new territory. Back in April, the same agencies flagged Iranian hackers going after Rockwell Automation controllers specifically. The updated advisory widens the net. Now Schneider Electric and Siemens equipment is on the list too.

US agencies have expanded guidance on detecting malicious code changes in PLCs after observing attacks targeting Rockwell Automation, Schneider Electric, Siemens, and other internet-exposed industrial controllers.

Attackers access exposed devices via OT ports (44818, 2222, 102, 502) and modems over SSH (port 22), then exfiltrate PLC project files using vendor tools such as Studio 5000, EcoStruxure Control Expert, and TIA Portal. They modify or delete project logic, including Add-On Instructions (AOIs), manipulate HMI and SCADA displays, and disable shutdown and alarm functions, allowing industrial systems to enter unsafe states without alerting operators.

Organizations should follow vendor security best practices, remove PLCs from direct internet access using secure gateways and firewalls, and monitor logs for indicators of compromise and suspicious traffic on OT ports such as 44818, 2222, 102, and 502. Rockwell users should set controllers to Run mode, while suspected victims should contact vendors and federal agencies.

The agencies say potentially any internet-exposed industrial control system could be a target. Here’s the part that should make plant operators lose some sleep. In one case, the hackers didn’t just peek at a system. They rewrote the controller’s programming logic to disable the processes meant to trigger shutdowns and alarms during dangerous conditions.

“At one U.S. victim, the FBI observed the APT actors download a malicious project file to a targeted PLC using configuration software. Analysis indicated the project file retained ladder logic for downstream function but added logic that overrode specific instruction sets responsible for maintaining safe operating parameters in the victim’s environment.

“Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT group disrupted the function of PLCs.” states the advisory. “Organizations across several U.S. critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy Sectors) deployed these PLCs within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.”

Systems could then drift into unsafe territory with nobody watching the warning lights, because the warning lights had been switched off from the inside.

“After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays [T1565].” continues the advisory.” Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.”

The advisory ties the activity to the ongoing conflict between Iran and the US and Israel, framing it as an effort to cause disruption inside the United States. It fits a pattern going back to February, when the war started and Iranian-linked hacking picked up sharply across the region.

Not all of it looks like this. Some of it has been standard espionage and embarrassment campaigns, like the leak of FBI Director Kash Patel’s personal email account. Some of it has been genuinely destructive. The Iranian group known as Handala remotely wiped tens of thousands of employee devices at medical device maker Stryker, and separately claimed a breach at California’s Cal Water, saying it could disrupt the water supply. Cal Water pushed back, saying it found no sign anyone had touched its operational networks.

That’s the pattern worth watching: espionage on one track, disruption on another, and now a wider set of manufacturers exposed on the operational technology side. If your PLC talks to the internet, it’s not a bystander anymore.

Nobody wants their water plant’s alarm system to be the one thing an adversary quietly switches off. Time to check who can actually reach those controllers from outside.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Iran-Linked Actors)