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. 32/Financial services/10 October 2026

An out-of-date mailing list, an expired certificate, and 76 days unseen

US Government Accountability Office, GAO-18-559, 'Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach', August 2018

Not yet reviewed
This one was written here from the source and has not yet been signed off, so it carries no byline. Every factual claim in it comes from the document linked below and can be checked against it. The judgements are ours, and until somebody has been back through them they are marked as unverified rather than presented as settled.

On 10 March 2017 unidentified individuals scanned Equifax's systems for an Apache Struts vulnerability that US-CERT had publicly identified 2 days earlier, found it on the server housing the online dispute portal, and confirmed they could run commands. Beginning on 13 May 2017 attackers used the portal to query other databases, ran approximately 9,000 queries and removed data in small increments over encrypted channels. The breach exposed personal information of at least 145.5 million individuals and lasted about 76 days before Equifax discovered it on 29 July 2017. GAO's account rests on what Equifax officials told it and was not independently assessed.

What worked

Discovery came from routine work: a network administrator checking the operating status and configuration of IT systems found the misconfigured inspection device and replaced its expired certificate. Once inspection of traffic resumed, the administrator recognised signs of an intrusion, Equifax blocked several Internet addresses, and the portal was taken offline on 30 July 2017. GAO notes that logs on the affected systems had not been damaged or erased, which let Equifax reconstruct the attackers' actions and determine what data was compromised.

What failed

Equifax circulated the US-CERT notice to its systems administrators, but the recipient list was out of date, so the people responsible for installing the patch did not receive it. A network scan a week after the vulnerability was identified did not detect it on the dispute portal. The digital certificate on a device installed to inspect network traffic had expired about 10 months before the breach, so encrypted traffic passed uninspected throughout it. Databases were not segmented, which let the attackers move from the 3 databases associated with the portal to an additional 48 unrelated databases, helped by a repository of unencrypted usernames and passwords. Nothing restricted the frequency of database queries.

The number

76 days

the attack ran before it was discovered, while an expired certificate left encrypted traffic uninspected.

What to do instead

Do not route a critical patch notice through an email distribution list: tie advisories to an asset inventory that names an owner for every internet-facing application, and require a positive acknowledgement. Verify patching with authenticated scans, and treat a clean scan for a technology you know you run as a question, not an answer. Monitor certificate expiry on security tooling as closely as on public websites, and alert when an inspection device stops inspecting. Segment databases, keep credentials out of plain-text stores, and rate-limit queries so that thousands of them look abnormal.

NO. 27/Cross-sector/12 September 2026

Twenty-one agencies, eleven countries, and the logs were deleted

CISA Advisory AA25-239A, Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage SystemCVE-2024-21887CVE-2024-3400CVE-2023-20273CVE-2023-20198CVE-2023-46805CVE-2018-0171

Twenty-one agencies from eleven countries put their seals on this advisory, which is the first thing to notice about it. PRC state-sponsored actors have been inside telecommunications backbone routers, provider edge and customer edge routers since at least 2021, and have used those compromised devices and their trusted connections to pivot into further networks. The named sectors are telecommunications, government, transportation, lodging and military infrastructure. The equipment spans Cisco IOS XE, NX-OS and IOS XR, Palo Alto PAN-OS and Ivanti Connect Secure, with Juniper, Fortinet, Nokia, Sierra Wireless and SonicWall suspected. What is taken is call data logs, a limited number of private communications, and material subject to court-ordered law enforcement requests.

What worked

The advisory does not say. It notes a single case in which "The APT actors were stopped before further actions could be taken" and gives no account of how, which is the only defensive outcome in the whole document.

What failed

The evidence, deliberately. This is the entry in this section where the forensic failure is the finding.

The actors modify access control lists to add their own IP addresses, so their traffic is permitted by policy rather than hidden from it. Then they disable logging, stop logs reaching central servers, delete and clear what is on the device, and revert configuration files so the modifications leave no trace. An investigation that starts on the router starts with nothing.

Underneath that sit the ordinary failures the advisory describes as avoidable. Five exploited vulnerabilities, the oldest from 2018, all with patches available. Weak and default SNMP community strings. TACACS+ and RADIUS traffic in cleartext or weakly protected forms. Cisco Type 5 and Type 7 password storage where Type 8 belongs. Management services listening on the internet. Guest Shell enabled on devices that have no use for it, which the advisory notes is "not monitored closely".

The number

21 agencies

from eleven countries co-sealed this advisory, which is a fair proxy for how widely the same actors were found in the same kind of equipment.

What to do instead

Get the logs off the device first, before anything else on this list. The actors’ entire evasion strategy is to control what the router remembers, and it only works while the router is the only place that record lives. Forward to a central server with immutable storage and a retention period long enough to investigate with, at informational level or better, and treat a device that stops sending as an incident rather than as a monitoring gap.

Then move the management plane out of reach. CISA’s wording is to place every management service, SSH, HTTPS, SNMP, TACACS+, RADIUS, SCP and SFTP, strictly into a dedicated out-of-band management network or a management VRF. That one change removes most of what the rest of the advisory describes.

Then patch the five and fix the defaults. CVE-2024-21887, CVE-2024-3400, CVE-2023-20273, CVE-2023-20198 and CVE-2018-0171 are the priority list. Change every weak and default SNMP community string and move to SNMPv3 only. Switch to Type 8 password storage. Require public-key authentication for administrators and disable password authentication where you can. Turn off Guest Shell and Smart Install.

And audit the configuration as a detection rather than as housekeeping. An access control list carrying an address nobody recognises, an unexpected tunnel, a new SPAN or ERSPAN session, a packet capture command, a TACACS+ redirect: each is a specific thing to go and look for, and not one of them will alert on its own.

Sources
NO. 12/Government / Defence industrial base/12 September 2026

A scripting bug in webmail, and ninety days of everybody’s email

CISA Advisory AA26-204A, Russian State-Supported Cyber Actors Conduct Phishing Campaign Targeting Users of Zimbra Collaboration SuiteCVE-2025-66376

Russian state-supported actors have been compromising Western government and commercial organisations running Zimbra Collaboration Suite since at least July 2025. The delivery is an email and the victim clicks nothing. Viewing the message in the Classic webmail client runs the attacker’s JavaScript, exploiting CVE-2025-66376, a cross-site scripting flaw in how Zimbra sanitises CSS import directives. In twelve asynchronous stages the payload takes the last 90 days of mail, the organisation’s Global Address List and whatever else it can reach, and pushes it out over DNS. The sectors CISA names are the Defence Industrial Base, federal and local government, education, energy, law enforcement, media, non-governmental organisations and technology.

What worked

The advisory does not say. It documents the tradecraft and the infrastructure in unusual detail and names no control at any victim that detected or stopped it. That is worth reading as a finding rather than as an omission. Exfiltration base32-encoded into DNS subdomains, sent to servers that are rotated every seven to sixty days, is built to pass the monitoring most organisations actually have rather than the monitoring they describe in an audit.

What failed

Patching, and then the password manager.

The flaw was a zero-day when exploitation began in July 2025. Zimbra released fixes for 10.1.13 and 10.0.18 in November 2025, and CISA says it "continues to be successfully exploited" well after that. Four months with no patch available, then months more with a patch nobody applied.

The second failure is quieter and worth sitting with. The script injects two hidden HTML elements requesting login credentials onto the page, outside the victim’s view, waits five seconds, and reads back whatever the browser’s password manager has autofilled into them. Nothing was tricked. The password manager did the job it was built to do, into a form the user never saw, on a page they had every reason to trust, in a session they had already authenticated. This is the part that a stronger password would not have helped with.

The number

90 days

of mail taken from each compromised mailbox, plus the full Global Address List, harvested in 20 batches of 77 directory lookups each.

What to do instead

Check the version first, because that is the whole of the immediate question. If you are on a vulnerable Zimbra build and cannot patch today, CISA’s interim advice is to move people off the Classic webmail client entirely and onto another mail client until you can. An advisory recommending that users stop using a product’s own interface is telling you how it rates the exposure.

Then assume the reads happened. What was taken is ninety days of mail and the address list, so this is not only a credential rotation. Revoke every Application Passcode and 2FA scratch key, force password changes, and go looking for the evidence: the SOAP request patterns CISA lists in mailbox.log, and localStorage items named zd_comp_YYYY-MM-DD.

Then fix the thing that made the credential theft free. Autofill into an invisible form is browser behaviour, not a Zimbra bug, and the next webmail scripting flaw will use it the same way. Moving authentication to a third-party service that supports passkeys takes the password out of the browser’s hands entirely, which is CISA’s own recommendation here and the only one on the list that survives the next occurrence.

And keep the network data. Every detection CISA offers is netflow or DNS: frequent queries with randomised subdomains, spikes to recently registered domains, outbound volume to virtual private servers. None of it is answerable without packet capture or NetFlow retained long enough to look backwards, which is a decision you make before the advisory rather than after it.

Sources
NO. 01/Federal / Government/4 September 2026

The GeoServer nobody patched, and the EDR alert nobody read

CISA Advisory AA25-266ACVE-2024-36401

Threat actors exploited an unpatched, public-facing GeoServer at a US federal civilian agency eleven days after the CVE was disclosed, then used a second unpatched instance thirteen days later. They held the network for three weeks, deploying the Stowaway proxy, China Chopper web shells and reconnaissance tooling before anyone noticed.

What worked

The EDR did its job. It detected and alerted on the Stowaway proxy tool on the first GeoServer on 15 July 2024, the same day the CVE was added to the KEV catalog. The detection engineering was not the failure here; every technical control that was deployed fired correctly.

What failed

Nobody read the alert. EDR alerts were not continuously reviewed, so a correct detection sat unactioned for seventeen days. The second GeoServer and the web server had no endpoint protection at all. When the agency finally responded, its incident response plan had no procedure for bringing in outside help, so granting the IR team SIEM access needed change control board approval while an active intrusion was in progress.

The number

17 days

between the EDR alerting on Stowaway and anyone acting on it.

What to do instead

Treat an unreviewed alert queue as an outage of the control that feeds it. An EDR nobody watches provides evidence after the fact, not defence, and it should be reported to leadership as coverage you do not have rather than coverage you bought. Separately: write the third-party access procedure before you need it, and rehearse it. Discovering mid-incident that your own change control stands between the responders and the logs is a failure of the plan, not of the responders.

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.