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. 28/Technology/27 September 2026
One service account password in a personal Google profile, and 134 customers' support files
Okta Security, 'Unauthorized Access to Okta's Support Case Management System: Root Cause and Remediation', 3 November 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.
From 28 September to 17 October 2023 a threat actor used a service account to reach files in Okta's customer support system associated with 134 customers. Some were HAR files containing session tokens, which the actor used to hijack the Okta sessions of 5 customers. Okta found that an employee had signed in to a personal Google profile in Chrome on an Okta-managed laptop, and the service account's username and password had been saved into that personal Google account, which Okta considers the most likely route of exposure.
What worked
Customers raised the alarm: 1Password reported suspicious activity to Okta Support on 29 September and BeyondTrust on 2 October. The turning point was an IP address supplied by BeyondTrust on 13 October. With it, Okta identified the service account on 16 October, disabled it and terminated its sessions on 17 October, and revoked the session tokens embedded in the HAR files.
What failed
For 14 days of active investigation Okta did not identify the suspicious downloads in its own logs. Its analysts looked at access to support cases, but the actor went straight to the Files tab of the support system, which generates an entirely different log event with a different record ID. The service account's credential was stored in the support system itself and carried permission to view and update customer support cases. Blocking personal Google profiles in Chrome on Okta-managed laptops was a remediation applied only afterwards. A gap in the support system logs also hid the final hours of the actor's access, so further downloaded files were only found on 19 October.
The number
14 days
of active investigation in which Okta did not identify the suspicious downloads in its own logs.
What to do instead
Block personal browser profiles and password sync on managed devices through enterprise browser policy, rather than trusting staff not to sign in. Keep service account secrets in a vault, scope them narrowly, and alert on any use from an unfamiliar network. Before an incident, list every log event type your SaaS vendors emit for file access and test that your hunt queries catch each route to the same data. Treat HAR files as credentials: strip session tokens before they are uploaded and keep token lifetimes short. When two customers report the same oddity within days, assume the common factor is you.
Ransomware that never runs on any of your machines
Datadog Security Labs, Holding blobs for ransom: Four methods for Azure Storage ransomware
Datadog sets out four ways an attacker who already has access to an Azure subscription can encrypt a victim’s stored data without ever deploying ransomware to a host. Two of the four are not theoretical: the first is the route used in a BlackCat deployment in 2023, and the third documents STORM-0501 activity. The other two are researcher demonstrations that Datadog says have not been seen in public reporting. The shape they share is that the attacker turns the platform’s own encryption features against the data, so from the storage service’s point of view every operation is legitimate and authorised.
What worked
Azure’s defaults do some real work and Datadog says so. Microsoft requires soft-delete on any key vault used for customer-managed key encryption of storage, which leaves a window in which a deleted key can be recovered rather than a permanent loss.
What failed
The logs, which is the finding that matters to anybody who would have to investigate this. Datadog is specific twice. Azure resource logs "do not log the x-ms-encryption-key-sha256 header, making usage of CPKs difficult to detect", and "the usage of encryption scopes in storage operations is not logged in storage resource logs". Two of the four encryption routes leave no trace in the logs you would reach for first.
And the protection that does exist can be shortened rather than defeated. The soft-delete retention that would have given you 90 days can be set by the attacker to its minimum of seven before the key vault is linked to the storage account. Ninety days is a recovery window. Seven days is a long weekend.
The number
7 days
the minimum soft-delete retention an attacker can set before linking a key vault to the storage account, in place of the 90 days the default would otherwise have given you to recover the key.
What to do instead
Turn the recovery controls on before you need them, because not one of them can be applied afterwards. Versioning, immutability policies and resource locks on storage, and Azure Defender for Storage for detection. Data that is already encrypted cannot be retroactively versioned.
Then close the logging gap by watching the control plane instead of the data plane. If customer-provided keys and encryption scopes do not appear in storage logs, the observable events are elsewhere: a key vault created and a key generated and then deleted in quick succession, a customer-managed key configuration pointing at a tenant that is not yours, a soft-delete retention being shortened, protection features being removed. Datadog lists each of those, and they are the detections that survive the gap.
Then take long-lived credentials out of the picture. This is an identity attack with a storage outcome, and all four methods begin from access somebody already held. Short-lived, narrowly scoped tokens is the control at the real entry point rather than at the visible one.
And rehearse the recovery. A cloud storage account is exactly as restorable as the versioning and immutability you configured in advance, and nobody wants to find out which they have during the incident.
Industrial-scale extraction, through the API you sell
CISA Advisory AA26-251A, China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies
CISA says China-based AI companies have been systematically extracting the capabilities of US frontier models by querying them at scale, taking "billions of tokens across millions of exchanges/requests" from variants of Claude, GPT, Gemini and Grok since at least late 2024. The route is not an intrusion. It is the product’s own inference API, reached through accounts "not registered to legitimate users" and through premium subscriptions bought in bulk and shared across teams of developers, with automated failover between pathways whenever one gets blocked. Individual campaigns run from days to months, at query volumes in the thousands to millions per domain.
What worked
The advisory does not name a control that held. It does record that blocking happened and was routed around, which is a finding in itself: somebody was detecting this and acting on it, and the answer was an automatic switch to another pathway.
What failed
Account identity first. The accounts were not registered to real people, so there was nothing to revoke that could not simply be created again, and any verification weak enough to automate sets the effective rate limit to infinity.
Then the commercial relationship, which is harder. The premium subscriptions were bought legitimately and then shared across teams, and no technical control sees that, because from the platform’s side it is one paying customer using an allowance they paid for. The prohibition lives in the terms of use, which is a contract rather than a control.
The part worth sitting with, for anybody running an API product, is that this is not an attack in the sense the rest of this section means. Every request was well formed, authenticated and paid for. What made it an incident was volume, pattern and intent, none of which is visible in a single call.
The number
billions
of tokens taken across millions of requests from US frontier models since at least late 2024, in campaigns running days to months at thousands to millions of queries per domain.
What to do instead
If you sell inference, your abuse detection has to work on the shape of a customer rather than the shape of a request. CISA’s first recommendation is monitoring of anomalous prompts, accounts, networks and behaviours together, and the word carrying that sentence is "together". A campaign like this looks ordinary at every individual layer and only appears when you join them.
Then make the block cost something. The most practical detail in the advisory is that blocking triggered automated failover between pathways, which means a block that is instant and unambiguous is a block that trains the client. Responses that degrade rather than refuse, and that cannot be attributed to one request, are much harder to build a failover around.
Then treat account registration as a security boundary and not a signup funnel. Fraudulent accounts were the way in, and everything downstream inherits whatever that check was worth.
And for everyone who does not sell an API, the transferable part is smaller and more useful. This is a product being used exactly as designed, at a volume and for a purpose nobody intended, by a customer who paid. Nothing in a normal security stack points at that. Work out who in your organisation would notice, and whether they have the data to.
Eight years on, the routers are still answering to the community string in the manual
CISA Advisory AA26-194A, Improve Router Hygiene to Protect Against Russian State-Sponsored TargetingCVE-2018-0171CVE-2008-4128
FSB Center 16 actors continue to take networking equipment worldwide, and CISA frames this as a hygiene problem rather than an exploitation one. Two routes carry it. Cisco Smart Install, still reachable on TCP 4786 and still unpatched against CVE-2018-0171. And SNMP agents answering to common or default community strings over SNMPv1 and SNMPv2, which have no meaningful authentication to begin with. What the actors take is configuration, pulled out over TFTP, and the credentials inside it. The sectors named are Communications, the Defence Industrial Base, Energy, Financial Services, Government Services and Facilities with state and local called out specifically, and Healthcare and Public Health.
What worked
The advisory does not say. Like the other hardening documents in this series it describes the exposure and the fix without naming a victim, a detection or a control that held.
What failed
Age, in two directions.
Cisco fixed CVE-2018-0171 in 2018 and CISA is still telling people to disable Smart Install in 2026. SNMPv1 and SNMPv2 were never designed to authenticate anybody, and the community string that gets accepted is frequently the one printed in the manual. Neither of these requires research, tooling or a novel idea.
The deeper failure is the class of device. Routers and switches sit outside most endpoint detection coverage, outside most patch cadences and outside most asset inventories, and a foothold there is underneath the layer that everything above it trusts. The advisory also raises end-of-life hardware, where there is no patch to apply and the honest answer is that somebody has to buy something. That is the part of this that does not get fixed inside a change window.
The number
8 years
since Cisco fixed CVE-2018-0171, which CISA is still naming in 2026 as a live route into critical infrastructure networks.
What to do instead
Disable Smart Install on every device, today. It is a provisioning feature that almost nobody uses past the first day, and it listens on TCP 4786 whether you use it or not.
Then deal with SNMP. Move to SNMPv3 with authPriv, turn off v1 and v2, change the community strings that are still the shipped defaults, and grant read-only where read is all that is needed. If you cannot change version yet, take CISA’s interim position: allowlist the object identifiers that can be read, and write an intrusion detection rule for inbound Set-Requests against the sensitive ones.
Then close the management plane. Access control lists on the management protocols, and block the ports at the edge: UDP 69 for TFTP, TCP 4786 for Smart Install, UDP 161 and 162 for SNMP, TCP and UDP 10161 and 10162 for SNMPv3. A router that answers management protocols from the internet is a router somebody else is also administering.
Then look for what they leave behind. CISA’s detection guidance is to monitor for local account logins on network devices and for credentials that do not match your naming convention. That is a cheap, specific check, and in most organisations nobody has ever run it against the network gear.
And put the end-of-life list in front of whoever signs for capital spend, with this advisory attached to it. On those devices the recommendation is replacement, and pretending otherwise just moves the risk onto next year.
Credentials from 2020, and 165 tenants with nothing in the way
Mandiant / Google Cloud Threat Intelligence, UNC5537
From April 2024, UNC5537 used credentials harvested by commodity infostealer malware to reach more than 100 Snowflake customer tenants, with around 165 organisations ultimately notified. Mandiant found no compromise of Snowflake's own infrastructure: every case was a customer tenant configured without MFA and without network allow-listing.
What worked
Attribution and notification. Mandiant and Snowflake identified the pattern across tenants, tied it to a single actor and got victim notifications out while the campaign was still running, which is what turned a slow drip of unexplained data theft into a campaign defenders could act on.
What failed
The shared responsibility line, in both directions. Customers left single-factor authentication on tenants holding their most sensitive data, and some of the credentials had been circulating in infostealer logs since 2020 without ever being rotated. Mandiant found that 79.7% of the accounts used in the campaign had prior credential exposure. The platform, for its part, did not require MFA by default, and a default that permits this outcome is a product decision as much as a customer one.
The number
79.7%
of the compromised accounts had credentials already exposed in infostealer logs, some dating to 2020.
What to do instead
Treat every corporate credential that has ever appeared in an infostealer dump as burned, and rotate on exposure rather than on schedule; ninety-day expiry does nothing about a password stolen on day two. For any SaaS tenant holding regulated or bulk data, require MFA and restrict access to known network ranges, then verify both from an unmanaged device. If you sell the platform, make MFA the default: this campaign is the argument that a permissive default eventually becomes your incident regardless of where the responsibility line is drawn.
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.
