Colorado water utility intruders changed pumping cycles, disabled alarms; access method undisclosed

Among the conditions the intruders had to satisfy, the write-up lists obtaining "the privileges required to modify device settings, alarms, and pumping cycles" ^[5]. One grant, covering the process and the channel that reports on the process. Of the four confirmed operation categories, two went after the operator's view and reach: remote access and alarms ^[1].

Detection is the part that breaks. The write-up tells administrators that indicators "may include unexpected changes to device settings or pumping cycles, loss of remote access, and disabled alarms" ^[7], and it says public information does not specify what triggered detection ^[8]. Two of those three indicators are the absence of a signal. Alerting on something that stopped arriving needs a component that expected it: a heartbeat, a poll, a scheduled config read.

The hunting guidance points the same way. It asks defenders to check network traffic for "controller write operations, disabled alarms, pumping commands, and unusual OT protocol activity" ^[9], and to check engineering workstations, HMIs and jump hosts for configuration file modifications ^[10]. Both observation points sit off the device whose settings changed. A passive tap on the OT segment keeps working after the controller stops reporting.

The no-impact finding depends on instrumentation. Confirming physical impact, per the same write-up, means correlating unauthorized controller changes against historian data, process variables, alarm states and independent physical measurements, and no such impact was confirmed ^[11]. Alarm state is one of those four inputs. Alarms were disabled somewhere across the two utilities, and the reporting does not map operations to sites ^[4]. In general, the write-up says, tampering with control settings or pumping cycles can produce pressure drops, overflows or treatment process deviations, none of which were confirmed here ^[16].

Nothing in the recommendations will surprise anyone. Keep OT assets off the public internet, restrict remote access with MFA, jump hosts, VPNs and allowlists, compare controller settings against an approved baseline, maintain independent paths for alarms and manual control ^[13]. The author adds a caveat: the affected products and the initial-access methods were never disclosed, so the list is general investigation guidance instead of incident-specific observables ^[12]. At a two-operator utility, all of that presupposes a baseline you can diff, a jump host separate from the engineering workstation, and an alarm path that ends somewhere other than the controller being alarmed on.