Polish water utility attack: technical account risk

On 10 February 2026, Poland’s Central Bureau for Combating Cybercrime (CBZC) announced the detention of a person suspected of attacking a water and sewage operator’s system. This is an important Polish case because the operator was classified as critical infrastructure, and the official notice disclosed a concrete sequence: unauthorised network access, login to a technical account, data collection and publication on the darknet through anonymising technology.

CBZC said officers located and removed the published data. The suspect was charged under Article 267 §2 of the Polish Criminal Code and Article 107(1) of the Personal Data Protection Act; the Poznań Regional Prosecutor’s Office supervises the case. These are allegations, not a final conviction.

Why the technical account is the key detail

A technical account normally represents a service, integration or remote-maintenance function rather than a named person. That is why it can become dangerous: its password may outlive employee rotations, its permissions are often broader than necessary and interactive logins may not require MFA. If multiple engineers share the same secret, a log proves only that the account acted — not which human used it.

In a water environment, machine identities can connect billing, telemetry, vendor support and management layers. The official announcement does not say the attacker controlled PLCs or altered an industrial process. That must not be inferred. Network and data access are confirmed, and the critical-infrastructure context is enough to make the incident relevant to both IT and OT defenders.

A defensible control model

Start with a complete machine-identity inventory: business owner, purpose, destination systems, last use and secret-rotation date. Disable an ownerless account or document a time-bound exception. Replace static shared passwords with vaulted secrets, certificates or short-lived tokens.

Administrative connections should cross a bastion that records sessions. In OT, enable vendor access for an approved work window, constrain it to a specific host and protocol, then close it. Segmentation should be tested rather than assumed; our internal network segmentation assessment explains the offensive validation process.

At minimum, monitoring should alert on:

• a technical account authenticating from a new source or outside a maintenance window,
• an interactive session for an identity previously used only by a service,
• bulk reads, exports and archive creation,
• traffic to anonymising networks or abnormal outbound volume,
• permission, API-key or authentication-policy changes.

Removing darknet data does not remove the exposure

Taking down a located copy reduces exposure but does not prove that no other copies exist. The operator still has to establish which records were accessed, for how long and whose data was involved, then make legal and communication decisions. That requires intact logs, configuration snapshots and prompt evidence preservation — one reason an incident response plan has to exist before a breach.

The practical lesson is that the label “OT” is not a security boundary. The first target is often an ordinary account, support portal or management system. An assessment should ask whether one compromised machine identity can read data, cross zones and conceal the human operator.

What to check this week

Export every non-human account, find those without strong authentication or rotation, reconstruct their real network paths and compare them with the diagram. Then run an authorised access and benign exfiltration simulation. If it produces no alert, the weakness is not only the account; it is also missing observability. BreachRoad can validate that chain in a controlled assessment.

A phase-by-phase incident model

Without inventing unknown details, defenders can build a useful analytical model. Phase one is network entry through an exposed service, compromised workstation, credential or vendor trust. Phase two is discovery and use of the technical account. Phase three covers data access and staging, and phase four transfer and publication. Each phase needs a distinct control and evidence source.

At the boundary, retain VPN, firewall and authentication logs. For account use, collect directory, PAM and target-system events. For collection, audit queries, file access and volume. For exfiltration, preserve proxy, DNS, NetFlow and endpoint telemetry. If only one layer exists, responders know the outcome but cannot demonstrate the path.

Critical-operator FAQ

Is a password reset enough? No. Revoke sessions, rotate connected secrets, identify every account use and investigate activity across the complete possible compromise window.

Does disconnecting the internet solve it? It reduces part of the risk but can break monitoring and maintenance. Use controlled segmentation with explicit flows, rather than treating a flat network and complete isolation as the only choices.

How should improvement be measured? Track time to detect an abnormal session, ownerless-account count, percentage of automatically rotated secrets and exercise performance when the team must reconstruct full access.

---

Primary sources: CBZC — cyberattack against critical infrastructure, Polish Criminal Code in ISAP.