A Lesson from the Energy Sector About Blind Trust
At the end of December 2025, a coordinated attack hit the energy sector in a neighboring country. Stories like this tend to fade quickly. A few articles appear, and then silence. But one of the incidents later documented by the national incident response team is worth examining, because it reveals something uncomfortable about the way we build security: our systems don’t fail where we expect them to.
A cogeneration plant that supplied heat to approximately 50,000 residents was partially shut down following an attack that did not come through the internet, did not use sophisticated malware, and did not exploit a spectacular “zero-day” vulnerability. It came from a direction that almost nobody considers a threat: the private data network of the distribution system operator.
What Happened, in Brief
The attacker did not enter the power plant directly but used an indirect route. The entry point was a device in a wind farm: a WAGO PFC200 PLC (programmable logic controller, used to automate industrial processes) equipped with an integrated cellular modem. This PLC was directly exposed to the internet, without two-factor authentication.
From there, through a poorly configured cellular router, the attacker reached a private APN network managed by the electricity distribution operator. This was the central problem: although it was called “private,” the network allowed unrestricted communication between any two devices connected to it, regardless of who they belonged to.
In practice, once inside through this side door, the attacker could “see” and access equipment belonging to completely different companies, with no separation barrier between them. They scanned the network, found an industrial controller protected only by its factory-default password, used it as a pivot point, and from there reached the plant’s operational network.
The investigation team’s conclusion is concerning: this appears to be the first documented case in which an OT network (operational technology, meaning the industrial systems that control physical equipment) was compromised through a private APN network. And the vulnerable configuration that made the attack possible was not an exception; on the contrary, it was a common setup, encountered not only in that country but potentially anywhere.
Why This Matters to You, Even If You Don’t Own a Power Plant
Here’s the temptation: “We don’t operate critical infrastructure, so this doesn’t concern us.” It does concern all of us, and here’s why.
The incident is not, at its core, a story about the energy sector. It is a story about implicitly trusting a network you do not control.
Every modern company has an equivalent of a “private APN”: a service provider, a partner’s network, a communication channel managed by someone else, which we treat as secure simply because it isn’t the “public internet.” A VPN provided by a vendor. An integration with a client’s system.
The “private” label gives us a sense of security that reality does not support. The network in this case was private in the sense that not everyone could connect to it, but once you were inside, nothing prevented you from moving freely.
A few lessons we can take away, beyond the technical details:
Attackers don’t come through the front door; they enter through the weakest connected device and then move laterally. In this case, the entry point (the wind farm) and the final target (the power plant) did not even belong to the same organization. Your security depends on the security of the organizations you are interconnected with.
A default or “factory” password is not secure. An unchanged password on a controller, an exposed administrative port, or an interface that should never have been accessible from that network are the kinds of small mistakes that go unnoticed precisely because they aren’t spectacular. They don’t require sophisticated exploits and they don’t make the headlines; they are simply configuration details that were overlooked, postponed, or forgotten during the rush to install equipment.
What you don’t monitor, you can’t defend. The investigation took more than three months and was complicated by the fact that the attacker covered their tracks: they reset devices, corrupted file systems, and deleted logs. In many organizations, this kind of activity would have gone completely undetected simply because there is no visibility into what is happening between network segments.
An “unexplained” incident is worth reporting. One easily overlooked detail: the affected entity initially believed that the incident was simply an engineer’s mistake during maintenance work. It was only because the response team was aware of other similar incidents that they decided to investigate, ultimately uncovering the attack. How often do we attribute a “strange” failure to bad luck without asking whether something more may have happened?
What You Can Do: Fort Cyber’s Recommendations
The principles below are designed to apply to any organization, not just those in the energy sector. We have grouped them into several key areas.
1. Treat Every External Network as Hostile (Including “Private” Ones)
If you don’t control a network’s configuration, treat it like the public internet. Apply the same segmentation and filtering controls to any connection to a third-party-managed network — whether it belongs to a vendor, partner, or operator.
2. Segment, Segment, Segment
Isolate critical segments. Block unrestricted communication between devices wherever there is no legitimate need for them to communicate. For equipment connected to external networks, use an allowlist: explicitly permit only what is necessary and block everything else.
3. Eliminate Default Configurations and Credentials
Change all factory-default passwords on every device. Disable unused services. Do not leave web interfaces, SSH, or Telnet exposed unless strictly necessary. Minimize the number of ports accessible from outside.
4. Enforce Multi-Factor Authentication (MFA)
The entry point in this incident allowed authentication without MFA. A second factor alone could potentially have stopped the entire attack chain. Apply MFA to all remote access, administrative accounts, and exposed interfaces.
5. Centralized Logging and Monitoring
Collect logs from devices that serve as bridges to external networks and store them centrally, where an attacker cannot delete them. Monitor traffic between network segments and look for deviations from normal patterns.
6. SOC Monitoring for GSM-Connected Devices
Assess whether it is relevant and feasible to implement an endpoint protection solution for devices communicating over GSM. Traffic from these devices can be monitored by a 24/7 SOC provider to identify “unusual” traffic.
7. Assess Your Supply Chain and Interconnections
Include third-party devices, partner integrations, and dedicated connections in your risk assessments. Verify what each partner could access within your network if their systems were compromised.
8. Test Your Defenses Before Someone Else Does
Include external networks, interconnection points, and edge devices in penetration tests, red team exercises, and architecture reviews.
9. Report Anything That Seems “Strange”
Report not only confirmed incidents, but also unexplained failures and unusual system behavior.
Instead of a Conclusion
What we find most striking about this case — if “striking” is the right word to use about an attack — is how ordinary each of the mistakes that made it possible was, considered individually.
An unchanged password. An open port. A network considered secure when it wasn’t. None of these would have made the difference on its own. Together, they opened a path from a wind turbine all the way to the heating system serving an entire city.
Cybersecurity is lost in the details we keep postponing, in the assumptions we never verify, and in the trust we grant because it is more convenient than asking questions.
If this article has made you think about a network within your own organization that you considered “safe simply because it is private,” then it has achieved its purpose. And if you need help, we’re here.
Stay vigilant.
This article is for informational and opinion purposes. It is based on a public analysis of a real incident in the energy sector, published by Poland’s national cybersecurity incident response team (CERT Polska / NASK).
