<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@graph": [
   {
     "@type": "FAQPage",
     "mainEntity": [
       {
         "@type": "Question",
         "name": "What happened in the Tczew hydropower cyberattack?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "On August 10, 2025, unauthorized attackers gained remote access to the control interface of a small hydropower plant near Tczew, Poland. They manipulated turbine RPM, water levels, and other operating parameters, causing power output to drop to zero intermittently for roughly 30 to 60 minutes. No physical damage or wider power outage was reported."
         }
       },
       {
         "@type": "Question",
         "name": "How did attackers gain access to the Tczew hydropower plant?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Public reporting has not produced a complete forensic account, but the working assessment is that attackers reached an internet-accessible remote access or SCADA interface, likely combined with credentials obtained during an earlier intrusion in May 2025. The incident illustrates the risk of exposed OT systems and credential-based remote access."
         }
       },
       {
         "@type": "Question",
         "name": "Was malware used in the Tczew OT cyberattack?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "No malware was identified in the Tczew incident. Once the attackers obtained access to the plant's legitimate HMI or control interface, they could manipulate operating parameters using the same controls available to authorized operators. The attack did not require custom industrial malware or a sophisticated exploit chain."
         }
       },
       {
         "@type": "Question",
         "name": "Why is network cloaking important for OT cybersecurity?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Network cloaking makes OT assets such as HMIs, PLCs, SCADA systems, and remote access endpoints undiscoverable to unauthorized users. Instead of presenting an open port, service banner, or login page to an attacker scanning the internet, a cloaked system does not respond. This can stop opportunistic attacks during the reconnaissance and target-discovery phase."
         }
       },
       {
         "@type": "Question",
         "name": "How can organizations protect OT systems from stolen credentials?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Organizations can reduce credential-based risk by replacing password-dependent access with passwordless, certificate-based authentication tied to verified users and authorized devices. Access should also follow least-privilege policies so that reaching the network does not automatically provide access to HMIs, PLCs, or other control systems."
         }
       },
       {
         "@type": "Question",
         "name": "How could AI increase the risk of attacks like Tczew?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "AI can accelerate reconnaissance tasks attackers already perform, including identifying exposed industrial systems, fingerprinting devices, correlating endpoints with leaked credentials, and interpreting unfamiliar HMI interfaces. AI does not necessarily create a new attack technique, but it can dramatically increase the speed and scale at which vulnerable OT targets are discovered."
         }
       },
       {
         "@type": "Question",
         "name": "Why are small and distributed OT sites attractive cyberattack targets?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Small hydro plants, water systems, pump stations, renewable energy sites, and similar facilities often require remote access but may lack dedicated cybersecurity personnel and monitoring resources. Opportunistic attackers may therefore select targets based on discoverability rather than strategic importance. A small exposed system can be valuable simply because it is easy to find and control."
         }
       },
       {
         "@type": "Question",
         "name": "How can OT operators prevent lateral movement after a cyber intrusion?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "OT operators can combine network cloaking, identity-based access controls, and microsegmentation so users and devices can communicate only with explicitly authorized systems. This limits an attacker's ability to discover additional assets or move from one compromised system to other OT devices."
         }
       }
     ]
   },
   {
     "@type": "HowTo",
     "name": "How to Reduce the Risk of Tczew-Style OT Cyberattacks",
     "description": "A practical eight-step approach to reducing the risk of OT cyberattacks involving exposed SCADA systems, stolen credentials, remote access, lateral movement, and AI-accelerated reconnaissance.",
     "step": [
       {
         "@type": "HowToStep",
         "position": 1,
         "name": "Identify internet-reachable OT systems",
         "text": "Inventory HMIs, PLCs, SCADA interfaces, gateways, VPNs, remote desktop services, and other remote access infrastructure. Determine which systems can currently be discovered or reached from outside the OT environment."
       },
       {
         "@type": "HowToStep",
         "position": 2,
         "name": "Make OT assets undiscoverable",
         "text": "Place critical control systems behind network cloaking so unauthorized scanning receives no useful response. Eliminate exposed ports, login pages, and service banners that allow attackers to identify industrial targets."
       },
       {
         "@type": "HowToStep",
         "position": 3,
         "name": "Eliminate password-dependent remote access",
         "text": "Replace shared passwords and reusable credentials with passwordless authentication tied to verified identities and authorized devices. This reduces the value of credentials stolen through phishing, previous breaches, or reconnaissance."
       },
       {
         "@type": "HowToStep",
         "position": 4,
         "name": "Enforce identity-based least privilege",
         "text": "Grant each operator, engineer, and contractor access only to the specific systems required for their role. Do not treat VPN connectivity or presence on an approved subnet as sufficient authorization."
       },
       {
         "@type": "HowToStep",
         "position": 5,
         "name": "Microsegment critical OT systems",
         "text": "Separate HMIs, PLCs, engineering workstations, safety systems, and other critical assets into tightly controlled segments. Prevent users or compromised devices from moving laterally simply because they have reached the OT network."
       },
       {
         "@type": "HowToStep",
         "position": 6,
         "name": "Secure third-party and maintenance access",
         "text": "Give contractors temporary, narrowly scoped access to only the systems required for a specific maintenance task. Revoke that access when the work is complete rather than leaving persistent remote-access pathways available."
       },
       {
         "@type": "HowToStep",
         "position": 7,
         "name": "Centralize protection for distributed sites",
         "text": "For organizations operating many small plants, pump stations, substations, or renewable-energy sites, apply security controls at the gateway and manage policy centrally. The architecture should scale without requiring a dedicated cybersecurity team at every facility."
       },
       {
         "@type": "HowToStep",
         "position": 8,
         "name": "Design for AI-accelerated reconnaissance",
         "text": "Assume attackers will increasingly automate system discovery, fingerprinting, credential correlation, and target analysis. Do not rely on obscurity or the assumption that a small facility is unlikely to be targeted. Architect the network so unauthorized users cannot discover the OT assets in the first place."
       }
     ]
   }
 ]
}
</script>

June 4, 2025
August 10, 2026
 —  
Blog

One Year After Tczew: The OT Attack That Didn’t Need Malware

One Year After Tczew: The OT Attack That Didn’t Need Malware

On 10 August 2025, someone connected to a small hydropower plant in northern Poland and drove its turbine parameters to their limits until the generator stopped. No malware was recovered. No exploit chain was published. There was nothing to reverse-engineer, because the attack was just a person clicking buttons on a screen that should never have been reachable.

A year ago this week, a run-of-river hydropower plant near Tczew, in Poland’s Pomeranian Voivodeship, a short drive south of Gdańsk, stopped producing electricity. Turbine RPM spiked and collapsed. Water levels swung. Power output dropped to zero, came back, and then dropped again over a window of roughly 30 to 60 minutes.

Nothing broke. Nobody lost power. In grid terms, this was a rounding error: a small plant briefly falling off a national system, unnoticed.

Then the attackers posted the video.

That is what makes Tczew worth a full entry rather than a footnote. The footage, surfaced publicly around 18 August 2025 via the Polish outlet CyberDefence24, showed the plant’s own control interface being operated by someone who had no business being there. Operational parameters are driven to their minimum and maximum values. The generator and rotor were forced to a halt. Polish analysts cross-checked the turbine type, head, and installed capacity visible in the footage against real plants and matched them to Tczew. They then compared the plant’s monitoring data for that day against the video and confirmed the obvious: this was not a simulation, not a staged demo, not a replayed recording from an unrelated site. Someone had real control of a real generating asset, and they wanted the world to know it.

It was also the second time. The same facility had been breached in May 2025. That attempt landed while the plant was offline for maintenance, so the attackers got access without impact. They came back three months later, and the plant was running.

I have written before that the incidents worth studying are rarely the expensive ones. Tczew cost almost nothing. It matters because of what it proves about the floor, not the ceiling. The floor is now this low.

The Incident: What Actually Happened

Public reporting on the technical details is thinner than any of us would like, and it is worth being honest about that up front. Poland has not published a full forensic account. What we have is the video, the plant’s telemetry, and the pattern of everything that came before and after it.

Here is what the evidence supports.

Initial access came through exposure, not innovation. The working assessment across public reporting is an internet-reachable remote access or SCADA interface, most likely an unpatched or weakly protected VPN endpoint, combined with credentials harvested during earlier reconnaissance. That is consistent with the May intrusion serving as the reconnaissance phase and the August visit as the return.

No malware was identified. ICSSTRIVE’s incident record for Tczew lists no malware and no confirmed threat source. This is not a gap in the investigation so much as a description of the attack. There was no implant because none was required. Once an unauthorized operator has an authenticated session against an HMI, the HMI does exactly what it was built to do. The attacker does not need to write code that speaks Modbus. The engineering vendor already wrote it, tested it, and shipped it with a graphical front end.

The manipulation was crude and effective. Parameters pushed to their extremes. Not a subtle process excursion designed to damage equipment over months, not a Stuxnet-style lie told to the control loop. Just sliders to the stops until the machine tripped.

The impact was operational, not physical. The turbine stopped. There is no report of equipment damage, injury, or downstream outage. In Hackopedia terms, Tczew is a single-site, short-duration operational disruption.

And yet.

The Real Payload Was the Video

Every prior entry in the Hackopedia catalog has an associated cost figure, whether it is Maersk’s $300 million or Norsk Hydro’s $70 million. Tczew has no meaningful number. Trying to price it misses the point entirely, because the disruption was not the objective. The recording was.

Pro-Russian hacktivist crews in this ecosystem, groups like Z-Pentest, which emerged in 2024 with a specific focus on OT intrusion against Western water and energy targets; its 2025 offshoot, Sector 16; and the longer-running Cyber Army of Russia Reborn, do not operate the way ransomware crews do. There is no extortion note and no wallet address. Their product is footage (and indirectly, fear). A screen recording of a Western industrial control panel bending to their input, posted to Telegram, is simultaneously a recruiting pitch, a proof of capability for whoever funds them, and a message to the Polish public that has spent three years serving as the logistics corridor for aid to Ukraine.

CISA and partner agencies formalized this pattern in joint advisory AA25-343A in December 2025, describing opportunistic pro-Russia hacktivist operations against critical infrastructure worldwide. The word doing the heavy lifting there is opportunistic. These actors are not selecting targets by strategic value. They are selecting them by discoverability, then filming whatever they find.

That inverts the threat model most operators still run on. The traditional question is “Would anyone bother attacking us?” A 5 MW hydro plant, a rural water district, a municipal fountain, all of them answer no. Tczew shows the question is now “Can we be found?” Because if the answer is yes, strategic value is irrelevant. A small plant is a better target for a propaganda operation than a large one because a small plant almost certainly has no SOC, no OT monitoring, no dedicated security staff, and a remote access setup configured by a contractor years ago that nobody has looked at since.

The attackers were not after Poland’s grid. They were after a screen recording. Tczew had one available.

The Escalation Around It

Tczew did not happen in isolation, and the twelve months since have made that unmistakable.

In the same period as the August attack, Polish industrial automation systems were hit at water treatment facilities in Szczytno, Sierakowo, and Witków, at a sewage treatment plant in Kuźnica, and, in the incidents that read as almost satirical until you think about them for a second, at swimming pools and public fountains. Poland’s deputy prime minister, Krzysztof Gawkowski, told The Times that the country was absorbing roughly 300 Russian cyberattacks per day, three times the rate from the previous year. In Norway, attackers manipulated valves at the Bremanger dam, an incident Oslo later attributed to Russia.

Then the ladder went up.

On 29 and 30 December 2025, Poland’s energy sector faced what its energy minister called the strongest attack on the country’s infrastructure in years: two heat and power plants were targeted directly, along with attempts against the communication links between distributed renewable installations and their distribution operators. Polish reporting suggested the attempt could have cut heat and power to at least half a million homes. ESET obtained the destructive payload, which it named DynoWiper, and attributed it with medium confidence to Sandworm, the GRU unit responsible for the 2015 and 2016 Ukrainian grid blackouts. A follow-up assessment at the end of January 2026 concluded that the intrusion succeeded because of poor security controls at the targeted facilities.

In May 2026, Poland’s Internal Security Agency published a two-year review confirming detected intrusions at five water treatment plants, where attackers were positioned to manipulate industrial equipment and, in the worst case, the safety of the water supply itself.

Read that sequence in order. Hacktivists filming an HMI at a small hydro plant in August. State military intelligence deployed a wiper against heat and power plants in December. Confirmed positioning inside the water supply by spring. The same country, the same eighteen months, and an unbroken escalation from performance to capability to pre-positioning.

The hacktivist crews and the GRU are not the same organization, and I am not claiming they are. But they exploit the same exposure. Tczew was the low-cost, high-visibility end of a spectrum whose other end is DynoWiper. The reconnaissance that produces a Telegram video and the reconnaissance that produces a wiper deployment start with the same question and are answered by the same network condition.

Why the Small Sites Are the Hard Problem

The uncomfortable structural fact behind Tczew is that the assets easiest to reach are the ones least able to defend themselves (which was proven again last week in the US with water utilities).

A national transmission operator has a security team, a budget line, a regulatory obligation, and vendors calling every quarter. A 5 MW run-of-river plant has an operations manager, a maintenance contract, and a remote access path so that when something fails at 2 a.m., someone can log in from home rather than drive out. That path is not a mistake. It is the only economically rational way to run a small distributed asset, and there are tens of thousands of them across Europe and North America: small hydro, wind sites, solar farms, district heating substations, pump stations, lift stations, water districts serving a few thousand people.

Every one of them is remotely managed because it has to be. Every one of them is therefore reachable, unless somebody has done specific architectural work to make it unreachable. And “make it not reachable” traditionally meant firewall rules, VPN concentrators, and jump hosts, all of which require an expert to configure and maintain correctly—precisely the resource these sites do not have.

That is the honest version of the Tczew lesson. It is not that the operator was negligent. The standard architecture for remotely managed small industrial assets produces discoverable, credential-protected control interfaces by default, and credential protection is not protection when the credentials were harvested three months earlier.

The New Threat Horizon: Automating Discovery

I have made this argument about Triton, and I will make it again here, because the mechanism is the same and the target set is much larger.

Everything an attacker had to do to reach Tczew is a search problem. Find internet-exposed industrial endpoints. Fingerprint which vendor and product is behind each one. Determine which have default, weak, or previously leaked credentials. From the HMI graphics, determine which process is being controlled and which parameter, if pushed to its stop, produces a visible physical effect. Today, that work is done by humans with Shodan queries, patience, and a rough working knowledge of what a Kaplan turbine’s control screen looks like. It is not hard work, but it is slow, and slowness is currently the only thing limiting how many Tczews happen per month.

Slowness is the part that automates. Fingerprinting unknown interfaces, correlating exposed hosts with credential dumps, and interpreting an unfamiliar HMI layout to identify the critical control are all pattern-recognition tasks. An adversary who can run that loop continuously rather than manually does not gain a new capability. They gain throughput. The same crews, the same skill level, and ten or a hundred times the target discovery rate.

There is no clever architectural answer to that on the detection side. If your defense is that nobody has gotten around to scanning you yet, your defense has a shelf life.

What AI Changes for OT Security

Tczew is also a useful preview of what happens when artificial intelligence is applied to an already simple attack model. AI does not need to invent a new way into an OT network. It can make existing reconnaissance, credential attacks, target identification, and attack planning dramatically faster.

We explore that problem in The 7 Deadly Sins of AI eBook, a practical look at the ways AI can amplify cyber risk in operational technology environments—and what OT teams can do about it.

For a deeper technical examination, read The Seven Deadly Sins of AI Technology in OT whitepaper, which examines AI-driven threats and the architectural controls that can reduce exposure before an attacker ever reaches the control system.

What We Do About It

Tczew is, in the most literal sense, the easiest incident in the Hackopedia catalog to have prevented. There was no zero-day to patch, no supply chain to audit, no proprietary safety protocol to defend. The entire attack rested on the control interface being findable and the credentials being usable. Remove either condition, and there is no incident.

Make the control interface undiscoverable

This is the whole ballgame for assets like Tczew. Network cloaking means that the HMI, the PLC, and the remote access endpoint return no information to an unauthorized source. No ping response, no open port, no service banner, no login page to brute force or credential-stuff. An attacker scanning Polish IP space for exposed industrial endpoints does not find a hardened target at Tczew. They find nothing at all, and they move on to a site that answers, because opportunistic actors always do.

Note what this defeats. It does not defeat the exploit, because there was no exploit. It defeats the targeting, which is the only phase this class of attack actually has.

Kill credential-based remote access

The May intrusion almost certainly furnished the credentials for August. Passwords, shared accounts, and contractor logins are the ammunition for every incident in this category. Passwordless, certificate-based authentication bound to a specific verified device removes the ammunition. A credential harvested in May is worth nothing in August if there is no credential to harvest.

Bind access to identity, not to network position

Anyone who reaches the plant’s control network must prove who they are on an authorized, posture-checked device, with an explicit path to the specific systems they are cleared to access. Not an IP address on an allowlist. Not membership in a VPN subnet. A verified session or nothing. Whoever operated that HMI on 10 August had network reachability and valid credentials, which, under the deployed architecture, were sufficient. Under an identity-defined architecture, it is not close to sufficient.

Solve it once, at the gateway, for every small site

The economic constraint is real: small distributed assets cannot each staff a security program. The answer is not to demand that they do. It is to put the control at the gateway in front of the asset, deployed once, managed centrally, requiring no change to the PLC, the HMI, the IP scheme, or the protocol. An operator with 200 small sites needs a control they can apply 200 times without adding 200 people. That constraint is not a detail. It is the design requirement.

Go Deeper: Defending OT Against AI-Powered Attacks

As AI lowers the cost of reconnaissance and increases the number of systems an attacker can investigate, OT security has to become less dependent on attackers failing to find you.

BlastWave has two additional resources on that shift:

The underlying principle is the same one Tczew demonstrates: if an attacker cannot discover the asset, cannot use a stolen credential to reach it, and cannot move laterally toward it, automation has far less to work with.

The BlastWave Thesis

A year on, the thing I keep coming back to about Tczew is how little the attackers actually did. They did not defeat a control. They found a screen that answered them, and they used it as designed. The sophistication in this incident lies entirely in the media operation afterward, not in the intrusion.

That is precisely why it belongs alongside Triton, Colonial, and NotPetya rather than in a footnote about hacktivist theater. Triton showed us the highest possible ceiling for OT attack capability, a state research institute spending years reverse-engineering a proprietary safety protocol. Tczew shows us the floor. And the floor is a Telegram channel, a scanner, some recycled credentials, and a plant that answered when it was asked.

Between that floor and that ceiling sits every distributed industrial asset your organization operates. The defenses are not different at each end. Triton’s operators needed to find the safety controllers. Tczew’s operators needed to find the HMI. Sandworm needed to find the heat and power plants in December. Every one of those campaigns began with a system that responded to an unauthorized party asking whether it existed.

The plant near Tczew is still there, still generating, still small enough that nobody outside the industry would have heard of it. It is on this list because someone found it. That is the entire qualification.

In OT, the first control is neither detection nor response. It is refusing to answer the question.

Explore the full Hackopedia at hackopedia.blastwave.com. To understand how AI could accelerate the reconnaissance and attack techniques behind incidents like Tczew, download The 7 Deadly Sins of AI eBook or go deeper with The Seven Deadly Sins of AI Technology in OT whitepaper.

Frequently Asked Questions

What happened in the Tczew hydropower cyberattack?

On August 10, 2025, unauthorized attackers gained remote access to the control interface of a small hydropower plant near Tczew, Poland. They manipulated turbine RPM, water levels, and other operating parameters, causing power output to drop to zero intermittently for roughly 30 to 60 minutes. No physical damage or wider power outage was reported.

How did attackers gain access to the Tczew hydropower plant?

Public reporting has not produced a complete forensic account, but the working assessment is that attackers reached an internet-accessible remote access or SCADA interface, likely combined with credentials obtained during an earlier intrusion in May 2025. The incident illustrates the risk of exposed OT systems and credential-based remote access.

Was malware used in the Tczew OT cyberattack?

No malware was identified in the Tczew incident. Once the attackers obtained access to the plant’s legitimate HMI or control interface, they could manipulate operating parameters using the same controls available to authorized operators. The attack did not require custom industrial malware or a sophisticated exploit chain.

Why is network cloaking important for OT cybersecurity?

Network cloaking makes OT assets such as HMIs, PLCs, SCADA systems, and remote access endpoints undiscoverable to unauthorized users. Instead of presenting an open port, service banner, or login page to an attacker scanning the internet, a cloaked system does not respond. This can stop opportunistic attacks during the reconnaissance and target-discovery phase.

How can organizations protect OT systems from stolen credentials?

Organizations can reduce credential-based risk by replacing password-dependent access with passwordless, certificate-based authentication tied to verified users and authorized devices. Access should also follow least-privilege policies so that reaching the network does not automatically provide access to HMIs, PLCs, or other control systems.

How could AI increase the risk of attacks like Tczew?

AI can accelerate the reconnaissance tasks attackers already perform, including identifying exposed industrial systems, fingerprinting devices, correlating endpoints with leaked credentials, and interpreting unfamiliar HMI interfaces. This does not necessarily create a new attack technique; it can dramatically increase the speed and scale at which vulnerable OT targets are discovered.

Why are small and distributed OT sites attractive cyberattack targets?

Small hydro plants, water systems, pump stations, renewable energy sites, and similar facilities often require remote access but may lack dedicated cybersecurity personnel and monitoring resources. Opportunistic attackers may therefore select targets based on discoverability rather than strategic importance. A small exposed system can be valuable simply because it is easy to find and control.

How can OT operators prevent lateral movement after a cyber intrusion?

OT operators can combine network cloaking, identity-based access controls, and microsegmentation so users and devices can communicate only with explicitly authorized systems. This limits an attacker’s ability to discover additional assets or move from one compromised system to other OT devices.

How To: Reduce the Risk of Tczew-Style OT Cyberattacks

1. Identify internet-reachable OT systems

Inventory HMIs, PLCs, SCADA interfaces, gateways, VPNs, remote desktop services, and other remote access infrastructure. Determine which systems can currently be discovered or reached from outside the OT environment.

2. Make OT assets undiscoverable

Place critical control systems behind network cloaking so unauthorized scanning receives no useful response. Eliminate exposed ports, login pages, and service banners that allow attackers to identify industrial targets.

3. Eliminate password-dependent remote access

Replace shared passwords and reusable credentials with passwordless authentication tied to verified identities and authorized devices. This reduces the value of credentials stolen through phishing, previous breaches, or reconnaissance.

4. Enforce identity-based least privilege

Grant each operator, engineer, and contractor access only to the specific systems required for their role. Do not treat VPN connectivity or presence on an approved subnet as sufficient authorization.

5. Microsegment critical OT systems

Separate HMIs, PLCs, engineering workstations, safety systems, and other critical assets into tightly controlled segments. Prevent users or compromised devices from moving laterally simply because they have reached the OT network.

6. Secure third-party and maintenance access

Give contractors temporary, narrowly scoped access to only the systems required for a specific maintenance task. Revoke that access when the work is complete rather than leaving persistent remote-access pathways available.

7. Centralize protection for distributed sites

For organizations operating many small plants, pump stations, substations, or renewable-energy sites, apply security controls at the gateway and manage policy centrally. The architecture should scale without requiring a dedicated cybersecurity team at every facility.

8. Design for AI-accelerated reconnaissance

Assume attackers will increasingly automate system discovery, fingerprinting, credential correlation, and target analysis. Do not rely on obscurity through low visibility or the assumption that a small facility is unlikely to be targeted. Architect the network so unauthorized users cannot discover the OT assets in the first place.

OT Secure Remote Access
Network Cloaking
Network Segmentation

Russian hacktivists compromised a Polish hydropower plant through exposed ports. BlastWave cloaks OT networks, eliminating reconnaissance, exposed endpoints, credentials, and lateral movement entirely.

Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.