Security ArtifactsDFIR Intelligence
SearchSign inSubscribe

Observations

What went wrong, and what to do about it

Real breaches, each put through the same four questions: one control that worked, one that did not, one number worth watching, and what should have been done instead. Every entry cites a primary source, because the point of this section is that you can take it to a meeting.

NO. 14/Government / Water utilities/12 September 2026

Controllers on the public internet, still holding the password they shipped with

CISA Advisory AA26-097A, Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure

Iranian-affiliated actors have been reaching programmable logic controllers directly over the internet at US water and wastewater utilities, energy organisations and local municipalities, and changing what those controllers do. CISA names Rockwell Automation CompactLogix and Micro850, Schneider Electric Modicon M340 and Siemens S7-1200, and says other manufacturers are likely in scope. There is no exploit to write about. The devices were exposed, they still held their default authentication keys and passwords, and from there the actors altered project files, manipulated what the operator saw on the HMI and SCADA displays, and disabled shutdown and alarm logic.

What worked

The advisory does not say. It is written as a hardening document rather than an incident narrative and names no detection or control that limited the activity at any victim.

What failed

Everything in front of the controller. CISA’s own account of the exposure is that these were "internet-exposed PLCs" on "devices that lacked sufficient network and/or hardening security controls", still carrying "default authentication keys and passwords".

The more interesting failure is the one that came after. Disabling shutdown and alarm logic while editing what the operator’s screen displays takes out the loop that keeps a plant safe and the loop that tells a person something is wrong, at the same time. The physical process and the picture of the physical process are then free to drift apart with nobody in a position to notice, which is a different category of problem from data theft and does not resolve itself when the intrusion is evicted.

And the pattern is not new. CISA cites the 2023 CyberAv3ngers campaign against US Unitronics devices as the precedent, and the exposure that made that possible is the exposure being used now.

The number

75 devices

compromised in the 2023 CyberAv3ngers campaign against US Unitronics controllers, which CISA cites here as the same exposure being exploited again three years later.

What to do instead

Take them off the internet. Everything else on CISA’s list is secondary to that and the advisory puts it first: put the controller behind a secure gateway, and if it reaches the world through a cellular modem, secure that modem with strong authentication and turn its logging on. That modem is a second internet connection, and it is usually missing from the asset inventory because nobody in IT provisioned it.

Then the two physical steps, which cost nothing and are the ones most often skipped. Put the mode switch in run position. Enable programming protection in the configuration software. A controller sitting in remote-programmable mode with no programming password is a controller that anybody who can reach it can rewrite, and no firewall rule compensates for that.

Then verify the logic rather than the device. If you were exposed, the question is not whether the PLC is patched but whether its project file still says what your engineers wrote. Use the vendor’s integrity tooling to compare against a known-good copy, and check specifically that the shutdown and alarm logic is present and enabled. The manipulated display is precisely why you cannot answer this from the control room.

Then the rest of the list: change the default passwords, add multi-factor authentication where the platform supports it, block Telnet, FTP, RDP, VNC and any web service you are not using, and keep offline backups of the project files that somebody has actually restored from at least once.

Sources
NO. 08/Government / Water utilities/11 September 2026

The same red team against two SOCs, and the alert queue that swallowed one

CISA Advisory AA26-237A

CISA ran two red team assessments at the same time, using similar tradecraft against a government services organisation and a water utility. Both ended the same way: full domain compromise, sensitive business systems reached, cloud resources reached. One of them caught the initial access within minutes and quarantined the hosts, which forced the red team into an assume breach model to carry on. The other never detected anything at all. The two organisations were running comparable tooling, and that is what makes this advisory worth the time.

What worked

Tuning. That is the whole finding, and it is unusually well controlled for a public document, because the same activity was run against both networks. At Organization B it produced a medium-severity alert that somebody triaged, and three workstations came off the network. At Organization A it produced alerts that nobody picked out of the volume. The alert text was "An executable file loaded an unexpected DLL file". No signature, no threat intelligence, no name for the thing. It stood out because Organization B had a baseline and had filtered the routine traffic away from it, so an anomaly could still look like one. B also let its defenders act: they triaged, found the root cause, and took the fix to engineering themselves rather than waiting to be told they were allowed to.

What failed

Organization A, at every layer above the sensor. Its tools were never tuned, so routine business activity and false positives ran at a volume the SOC could not work through, and the intrusion sat inside that volume looking like everything else. Then the organisation finished the job: several SOCs that did not talk to each other, no shared visibility with the system owners, and staff who did not know what they were authorised to do on which segment of the network. With no escalation procedure to fall back on, they defaulted to wait and see. Nobody in that chain did anything unreasonable, which is the uncomfortable part.

Organization B was better at detection and no better at hardening. Its Machine Account Quota was set to 1,000 for every domain user, and a service account held AllExtendedRights over a domain controller, which is a DCSync and then the whole domain. Detection bought time; it did not close the path.

In the cloud they failed identically. Both granted excessive permissions to applications, neither applied Conditional Access to workload identities, and neither had a process for revoking access and refresh tokens after a compromise. That last gap is the one to sit with: it means an actor you have evicted from the network still has the tenant.

The number

20 minutes

the slowest of Organization B's three workstation isolations, against no response at all from Organization A to the same red team activity.

What to do instead

Tune what you already own before you buy anything else. Two organisations, the same tradecraft, opposite outcomes, and the variable was a baseline rather than a product. Go and count what share of last week's alerts your analysts closed without investigating. That share is your actual detection coverage, and it is usually nothing like the coverage on the licence.

Then give your defenders the authority to act on what they find. Organization A's analysts were not short of alerts, they were short of permission, and "wait and see" is what a team defaults to when nobody has written down who may pull a host off the network at two in the morning. Write that down.

Then fix the two cloud gaps both of them shared, because those are the ones that survive eviction. Apply Conditional Access to workload identities and not only to people, and write the token revocation procedure before you need it: refresh tokens outlive the containment you are proud of, and nobody improvises that step mid-incident. While you are there, go looking for long-lived static IAM keys set never to expire. Organization A's were sitting in configuration files in users' home directories, which is where yours will be.

Sources

Named for the doctrine distinction between a lesson observed and a lesson learned: a lesson is not learned until behaviour has changed and somebody has checked. Pretending otherwise is how the same finding turns up in three consecutive post-incident reports.