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. 31/Education / Culture/6 October 2026
One terminal server outside MFA, and a server estate encrypted or destroyed
British Library, 'Learning lessons from the cyber-attack: British Library cyber incident review', 8 March 2024
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 28 October 2023 a ransomware attack claimed by the Rhysida gang exfiltrated some 600GB of files from the British Library, encrypted or destroyed substantial portions of its server estate and locked all users out of the network. The first detected unauthorised access was at a Terminal Services server installed in February 2020 for trusted external partners and internal IT administrators, where access was not subject to MFA. The Library paid no ransom, the data was dumped on the dark web, and the rebuild of its infrastructure was still under way when the review was published.
What worked
At 00:21 on 26 October the Library's monitoring system automatically blocked suspect activity, and the IT Security Manager was alerted at 01:15. A different software system identified and prevented the encryption attack from executing on the laptop and desktop estates. Cloud-based email, finance, HR and payroll systems functioned normally throughout. The review says enhanced encryption protected the unedited Electoral Roll database, PCI DSS controls meant no credit card data was compromised, and backups unaffected by the attack were confirmed in December.
What failed
MFA was introduced in 2020 for cloud applications, but connectivity to the Library's domain and on-premise servers was left out of scope for reasons of practicality, cost and impact on ongoing programmes; the risk was raised and, in the review's words, perhaps under-appraised. After the 26 October alert the block was extended, a vulnerability scan came back with no results, and the account was given a password reset and unblocked later that day; the review now believes this was hostile reconnaissance. The legacy network topology allowed the attackers wider access than a modern design would have, and older defensive software on the server estate could not resist the attack. The 440GB that left the estate at 1.30am on 28 October was identified by Jisc only after the Library alerted it. Destroyed servers meant that secure copies of the collections had no viable infrastructure to be restored to.
The number
600GB
of files copied and exfiltrated, just under half a million documents, then dumped on the dark web when no ransom was paid.
What to do instead
Put MFA on every remote access route, supplier and administrator routes first, and give any exception made for cost or convenience a named owner and an expiry date. Treat a blocked intrusion as the start of an investigation: a password reset followed by an unblock is not a review. Segment the network so that one terminal server cannot reach the whole estate, and manage third-party access through privileged access management. Keep immutable offline backups, and also make sure there is somewhere clean to restore them to. Report accepted low-level risks to senior management in aggregate, a weakness the review identifies in the Library's own risk process.
One engineer's laptop, and a 2FA-backed session that reached production secrets
CircleCI, 'CircleCI Jan 4, 2023 security incident report' (circleci.com/blog, dated 12 January 2023)
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.
Malware on a CircleCI engineer's laptop, compromised on 16 December 2022, stole a valid, 2FA-backed SSO session. The engineer's regular duties included generating production access tokens, so the intruder reached a subset of production systems, carried out reconnaissance on 19 December and on 22 December exfiltrated customer environment variables, tokens and keys. CircleCI learned of the intrusion after a customer reported suspicious GitHub OAuth activity on 29 December, and told all customers to rotate their secrets on 4 January 2023.
What worked
A customer's report on 29 December started the investigation, and by 4 January CircleCI had established the scope and the entry path. The report says the company's authentication, security and tracing tools allowed it to diagnose and remediate the issue comprehensively. CircleCI shut down the compromised employee's access, cut production access to a very small group, rotated all potentially exposed production hosts, and revoked or rotated Project API tokens, Personal API tokens, Bitbucket tokens and GitHub OAuth tokens on customers' behalf.
What failed
The malware was not detected by CircleCI's antivirus software. Because the theft was of a session cookie, the second factor had already been satisfied and the intruder could impersonate the employee from a remote location. The exfiltrated data was encrypted at rest, but the intruder extracted encryption keys from a running process. The first warning came from a customer on 29 December, after the last recorded unauthorised activity in production on 22 December. Rotating every customer's GitHub OAuth tokens began on 31 December and was not complete until 7 January.
The number
Fewer than 5
customers had reported unauthorised access to third-party systems when the report was published, yet every secret stored on the platform had to be treated as exposed.
What to do instead
Assume a completed MFA challenge can be stolen as a session cookie and design for it: short session lifetimes, device-bound sessions, and step-up authentication before production access or token generation. One engineer's routine privileges should not include minting production access tokens without a second control. Encryption at rest gives little protection when the keys sit in a process an intruder can read, so hold keys where each use is separately authorised and logged. If you store secrets with a CI provider, prefer short-lived OIDC tokens, restrict inbound IP ranges, and rehearse a full secret rotation before you need one.
Zscaler ThreatLabz, CaptiveCrunch: Midnight Blizzard Weaponizes Hotel Wi-Fi Captive Portals to Steal Microsoft 365 Credentials
Storm-2945 compromised the shared captive portal services that hotels, conference centres and similar venues run, then manipulated DNS and HTTP traffic on those networks to send guests to attacker infrastructure. Zscaler found compromised gateways in several US cities, in India and in Saudi Arabia. What the traveller sees is the sign-in page they were expecting. What follows is Microsoft 365 credential harvesting, device code phishing and malware delivery. The victims here are not the hotels. They are whoever stayed in them, across every sector.
What worked
Zscaler names no control that stopped an instance of this in a customer environment. The write-up lists the product settings that would have, which is a different claim, and the entry below is where the useful reading is.
What failed
Multi-factor authentication, and not because it was absent. The device code pages abuse the Entra ID authentication flow itself. The victim is shown a genuine Microsoft prompt and authenticates the attacker’s session rather than their own, which as Zscaler puts it "can bypass conventional multifactor authentication (MFA)" because no credential is being relayed and nothing is being faked. The user completes a real login. The attacker ends up with a device registered in the tenant.
The second failure is an assumption about the network. A laptop that drops its tunnel on an untrusted network so the captive portal will load is a laptop with no inspection at the exact moment it is talking to a hostile DNS server. That configuration is common because it is often the only way captive portals work at all, which makes it a design tension rather than an oversight, and this campaign is what the tension costs.
The number
500 MB
the per-cycle upload cap built into the CornFlake payload, which also limits itself to 1,000 files a cycle and collects 18 categories of host information.
What to do instead
Treat the captive portal as hostile, because in this campaign it was. The practical control is that the corporate tunnel comes up before anything else and stays up, in full rather than with a local proxy exception, and that DNS goes to your resolver instead of the network’s. Zscaler’s version of this is a list of their own settings, but the principle underneath it ports to whatever you run.
Then block device code flow in Conditional Access. It is the single change here that closes the identity half of the attack. Almost nobody uses the flow for real work, the people who do can be scoped into an exception, and without it the genuine Microsoft prompt that makes this work never appears.
Then alert on new device registrations in Entra ID, because that is what a successful device code phish looks like from your side of the glass. It is one of the few signals in this chain that reaches your tenant at all, given that everything before it happened on somebody else’s network.
And have the travel conversation, which is cheaper than any of the above. A phone hotspot removes the entire attack. Say so before the conference rather than after it.
Akira Hits Safe Mode: Ransomware Rebooting Around EDR
Huntress, 12 August 2026
After gaining access via an exposed SonicWall VPN, an Akira affiliate rebooted the victim host into Safe Mode with Networking to defeat EDR, a first for this ransomware variant in our telemetry. Safe Mode is a boot mode that only loads essential drivers and services, disabling most third-party software. As such, the reboot stopped the Huntress agent and disabled Microsoft Defender's real-time protection; Defender couldn't quarantine the file until the attacker rebooted back to normal mode.
What worked
Huntress records one thing that held. “Eventually, a scheduled Defender scan detected the ransomware binary at 07:43:50 UTC.”
What failed
Huntress groups the failures under four headings: initial access: SonicWall SSL VPN, no MFA; living on the domain controller: recon, the akira way; collection and exfiltration: WinRAR to the cloud; and AnyDesk: the delivery and c2 channel. “The intrusion started where many Akira intrusions start: a SonicWall SSL VPN. Beginning around 03:45 UTC on August 4, 2026, the SonicWall logged a burst of failed logins (Unknown User Login Attempt / "User login denied due to bad credentials") against multiple usernames from several external IPs: a straightforward credential spray.”
The number
10 minutes
This AnyDesk session (including the preceding Safe Mode reboot) lasted less than 10 minutes, showing how well-oiled these Akira intrusions have become.
What to do instead
Catch the credential spray before it becomes a foothold: Alert on bursts of failed VPN logins against multiple usernames from one source. Correlate those failures with a successful login from the same IP or ASN within a short window.
A Citrix portal without MFA, and nine days to ransomware
Written congressional testimony of UnitedHealth Group CEO Andrew Witty, May 2024
ALPHV/BlackCat operators logged into a Change Healthcare Citrix remote access portal on 12 February 2024 using stolen credentials. The portal had no multi-factor authentication. They moved laterally for nine days and deployed ransomware, disrupting roughly a third of US healthcare transactions and ultimately affecting around 190 million people.
What worked
Very little on the technical side, and the honest reading of this case is that the containment decision was the only thing that went right: the systems were taken offline decisively rather than being left running while the scope was argued about. That call limited the encryption, and it is why this was a catastrophic outage rather than a total one.
What failed
A single-factor internet-facing remote access portal, reached with credentials the attackers already had. Nine days of lateral movement produced no detection that stopped them. The dependency concentration then turned one company's identity gap into a national outage: pharmacies could not process claims, and providers went unpaid for weeks.
The number
9 days
between the first login on the MFA-less Citrix portal and ransomware deployment.
What to do instead
Enumerate every internet-facing authentication surface and prove MFA on each one, from the outside, by testing it rather than by reading the policy. The gap is almost never the main SSO; it is the legacy portal, the vendor appliance, the acquisition that was never folded in. Then ask the question this case actually poses: if you were unavailable for three weeks, who else stops working? That answer belongs to the business, and it is worth more than another detection rule.
One legacy test account, and the OAuth app that reached production
Microsoft Security Response Center post-mortem, January 2024
Midnight Blizzard ran a low-and-slow password spray against a legacy, non-production test tenant in late November 2023 and compromised an account that had no MFA. From there they abused a legacy OAuth application holding elevated permissions into the corporate Exchange Online tenant, and read the mailboxes of senior leadership, legal and the security team itself until detection on 12 January 2024.
What worked
The disclosure. Microsoft published the attack path, named the actor, described the OAuth pivot in technical detail and shipped defender guidance while the eviction was still running. As a piece of post-incident behaviour it set the standard the rest of the industry gets measured against.
What failed
A non-production test tenant was treated as low-risk, and the identity in it was therefore exempt from the MFA policy applied everywhere else. The real failure is the trust relationship: a legacy OAuth application in that throwaway tenant held Office 365 Exchange Online full_access_as_app against the corporate environment, which grants read on any mailbox. The password spray was deliberately low-volume to stay under the alerting thresholds, and it did.
The number
0
MFA factors on the legacy test account that led to the leadership mailboxes.
What to do instead
Inventory the OAuth applications and service principals that cross a tenant boundary, and treat each one as a production identity regardless of which tenant it lives in. "Non-production" describes the workload, never the blast radius of the credentials inside it. Then check your password-spray detection against low-and-slow volumes specifically: a threshold tuned for a noisy spray does not fire on a patient one, and patience is free.
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.
