What actually changed between 2024 and 2026, why the playbook you already have will fail against it, and how to read the rest of this book.
Who needs this: Everyone — CISO, Incident Commander, SOC lead, IT director, and the executive who signs the budget | Read time: 18 min | Maps to: CSF 2.0 GOVERN, IDENTIFY (GV.OC, GV.RM, ID.RA)
Hello, cyber warriors. Before we start, a story with no malware in it.
Between 8 and 17 August 2025, an actor tracked as UNC6395 spent ten days quietly exporting records from more than 700 organizations. Cloudflare. Google. PagerDuty. Palo Alto Networks. Proofpoint. Tanium. Zscaler. Not one of them had a vulnerability to patch. Nobody clicked anything. No endpoint agent lit up, because there was nothing on any endpoint to light it up. The attackers had reached Salesloft's GitHub environment months earlier, pivoted into the AWS environment behind the Drift chatbot, and stolen the OAuth refresh tokens that customers had themselves issued to Drift — standing, password-proof, MFA-immune grants of access to those customers' Salesforce, Google Workspace and in some cases Slack data (AppOmni; Cloud Security Alliance).
Then came the part that should keep you up at night. The most valuable thing stolen was not CRM data. It was the API keys, Snowflake tokens, cloud credentials and passwords that customers had pasted into the body of support tickets over the years. A support queue turned out to be a credential vault with no lock on it.
Now open whatever incident response documentation you have and find the step that handles this. Not "contain the threat" — the actual step. There is no host to isolate, no password to reset, no patch to deploy, no malicious binary to submit to the sandbox. The correct first move is to enumerate every OAuth grant in your tenant, revoke the refresh tokens, and go read your own support tickets looking for secrets you wrote down years ago. If your playbook does not have that branch, it is not a slightly outdated playbook. It is a playbook for a different decade.
That is the argument of this chapter. Not that the threat landscape got worse — it always gets worse, that is not news and it does not help you. The argument is narrower and more useful: the specific assumptions that older playbooks were built on have been individually falsified, and you can name them one at a time.
Every playbook written before 2025 assumes you have time to think. You do not.
Mandiant's investigations now put the median hand-off from an initial-access broker to the ransomware operator who buys that access at 22 seconds, down from more than eight hours in 2022. Brokers pre-stage the secondary malware and tunnels during the initial infection, so the operator inherits a finished foothold rather than building one (M-Trends 2026). That window — the one where you noticed a commodity infection and had an afternoon to clean it up before anything serious happened — is gone. It was never a plan, but a lot of us were quietly relying on it.
CrowdStrike measured average eCrime breakout time at 29 minutes, 65% faster than 2024, with the fastest observed at 27 seconds (CrowdStrike 2026 Global Threat Report). Sophos found 88% of ransomware encryption events happened outside business hours (Help Net Security on Sophos), which is not a coincidence and not bad luck — it is target selection. Attackers know when your on-call rotation is one tired person with a phone.
Meanwhile the aggregate dwell-time number is a trap. The global median rose to 14 days from 11, which reads like defense getting worse. Split it and the story inverts: dwell time for internally-detected intrusions improved to 9 days, while externally-notified dwell jumped to 25 days, dragged up by espionage cases and DPRK IT-worker fraud. Internal detection accounted for 52% of activity, up from 43% (M-Trends 2026). We are getting better at finding what we are looking for and no better at all at finding what we are not. Espionage cases sit at a 122-day median.
Actionable takeaway: stop measuring mean time to respond as a single number. Split your metric into internally-detected and externally-notified, and report both to the board every quarter. If the second number is larger than the first — and it will be — that gap is your actual detection debt, and it is the number Chapter 9 exists to close.
Here is the change that reshapes more playbook steps than any other.
Sophos found 79% of ransomware attacks began with an identity-based approach, and 67% of victims confirmed the ransomware incident overlapped with an identity attack. Ninety-seven percent of those organizations had some MFA — just not consistently across VPNs, firewalls and legacy applications (Sophos State of Ransomware 2026). CrowdStrike reports 82% of its detections were malware-free (CrowdStrike). If your triage process starts with "what did the EDR flag," you are searching a room the adversary left years ago.
Four techniques are worth naming, because each breaks a different assumption:
One honest caveat, because you will be asked about it. Verizon's 2026 DBIR reports the opposite headline: vulnerability exploitation at 31% overtook credential abuse at 13% as the top initial vector, for the first time in nineteen years (SecurityWeek). Both findings are correct for their populations. DBIR's dataset is breach-wide and heavily weighted by mass edge-device exploitation events; Sophos, Coveware and Mandiant are looking at ransomware-specific incident response. Translation for your program: exploitation gets you through the perimeter, identity gets you through the company. You need both branches, and Chapters 4 and 10 own them.
Actionable takeaway: rewrite the first trigger in your ransomware playbook. It should not be "malware detected." It should be "an identity event we cannot explain" — a help-desk-initiated MFA re-enrolment, an impossible-travel token use, a new OAuth grant, or a hit on an infostealer credential dump. And your containment step is revoke sessions and tokens first, reset the password second. Reversing that order leaves a valid token in the attacker's hands for the remainder of its lifetime.
Double extortion is the floor now, not the differentiator. The live variable is whether encryption happens at all — and the economics have gone strange.
Coveware's Q2 2026 caseload shows the payment rate for exfiltration-only extortion collapsed to 15%, with the overall payment rate at a record low (Coveware by Veeam). DBIR puts it at 69% of ransomware victims not paying (Help Net Security). Sophos found 48% of encrypted victims paid, with the median demand down 65% over two years to $698K, and — the number that should drive your budget — 66% of encrypted-data cases recovered from backups, up 12 points (Sophos).
That last figure explains the single most important shift in adversary behavior. Mandiant's framing is the sharpest available: the move from data theft to recovery denial. Operators now deliberately target backup infrastructure, identity services, virtualization management planes, AD CS certificate templates and hypervisor datastores. They are attacking your ability to recover, not only your ability to operate (M-Trends 2026).
Read that as a compliment and a warning. Backups started working, so backups became the target.
One number to handle carefully. Coveware's Q2 2026 average payment was $1,880,612, up 176% quarter over quarter, while the median fell 50% to $150,000. The average is distorted by a small number of very large payments, principally a campaign against law firms extorting on exposure of privileged legal records. Do not use the average to set a reserve or an insurance limit (Coveware).
And note who is actually getting hit: 75.8% of Coveware's cases were mid-market, with 101-to-1,000-employee firms the largest single segment. If you have been telling yourself you are too small to be interesting, the data disagrees.
Actionable takeaway: add a recovery-denial pre-check to ransomware triage, executed before you start restoring. Verify the integrity of backup catalogs, the identity plane, hypervisor management and certificate services first. If any of the four is compromised, you are not in a restore scenario — you are in a clean-room rebuild, and Chapter 12 is the chapter you need tonight.
I use AI tooling every day and I will still tell you that most of what you have read about AI attacks in the last year is marketing. Let us separate what has actually been observed from what is being sold.
What is confirmed. In November 2025 Anthropic disclosed GTG-1002, a campaign it assesses with high confidence to be Chinese state-sponsored, in which its own model was used agentically against roughly 30 targets — technology firms, financial institutions, chemical manufacturers, government agencies. The model performed 80–90% of the campaign, with humans intervening only at decision gates, after operators bypassed safeguards by role-playing as authorized penetration testers and decomposing the attack into individually innocuous tasks (Anthropic). In May 2026 Sysdig observed the second confirmed agentic intrusion, hands-on in a live cloud environment: after exploiting a notebook application, the agent enumerated container escape primitives on its own, mounted the Docker socket, read host credentials, and replayed a projected Kubernetes service-account token to dump the cluster secret store (Sysdig).
Note what that second one did not need: an exploit for the privilege escalation. The agent used only the access its runtime already carried.
On social engineering, the losses are real and named. Engineering firm Arup lost approximately US$25.6 million across 15 wire transfers in a single day after an employee's scepticism about a phishing email was overcome by a video conference in which every other participant was AI-generated (CNN). Three comparable attempts were stopped: WPP, where staff caught a voice clone of the CEO in a Teams meeting (OECD AI Incidents); Ferrari, where an executive challenged a CEO voice clone with a shared-secret question about a recently recommended book (AI Incident Database); and LastPass, where an employee flagged the anomalous channel rather than detecting the fake.
Every one of those three saves came from a human process check, not from detection technology. Not one. That is your control, and it costs nothing.
Vishing is now structurally significant rather than anecdotal: voice phishing was the #2 initial infection vector at 11% of Mandiant's 2025 investigations (M-Trends 2026). The FBI's IC3 recorded $20.877 billion in total 2025 losses across 1,008,597 complaints — the first year over a million — with BEC alone at $3.047 billion, and introduced "AI-related" as a formal crime descriptor for the first time, logging 22,000+ complaints and roughly $900 million in losses (FBI).
And now the counterweight, which belongs in your program's stated assumptions. Mandiant's own conclusion from more than 500,000 hours of 2025 incident response is that 2025 was not the year breaches directly resulted from AI, and that most intrusions still stem from human and systemic failures (M-Trends 2026). And VulnCheck found that of 1,061 vulnerabilities attributable to AI-assisted discovery, only 14 — 1.3% — have been confirmed exploited in the wild (VulnCheck). AI is inflating your patch queue far faster than it is inflating your actual risk.
Actionable takeaway: budget for AI in two places and no others this year. First, a verification procedure for any voice or video instruction that moves money or grants access — a call-back to a number from your own directory, plus a challenge phrase, for every payment or access request above a stated threshold. That is a policy change, not a purchase. Second, an inventory of the AI systems and agents already in your environment, because you cannot defend what you have not counted. Chapter 7 owns the rest; Chapter 14.9 owns the deepfake playbook.
Vulnerability exploitation reached 31% of breaches in DBIR 2026 (SecurityWeek), and exploits were the top initial infection vector in Mandiant's data for the sixth consecutive year at 32%.
Our remediation is going backwards while that happens. Across 13,000 polled organizations, only 26% of CISA KEV-listed vulnerabilities were fully remediated, down from 38%, and median patching time rose to 43 days from 32 (Help Net Security on DBIR 2026).
The speed on the other side is measurable. VulnCheck's first-half 2026 data shows 23.43% of KEV entries had evidence of exploitation on or before the day the CVE was published, and the median time from CVE publication to KEV listing fell from 120 days to 80 (VulnCheck). Nearly one in four times, the disclosure is the news that you are already late.
Concentration makes it worse. The UK NCSC handled 429 incidents in its 2024/25 reporting year, of which 204 were nationally significant — up from 89 the year before, with 18 rated highly significant. Three vulnerabilities alone drove 29 of them: Ivanti Connect Secure CVE-2025-0282, Fortinet FortiManager CVE-2024-47575, and Microsoft SharePoint CVE-2025-53770 (NCSC Annual Review 2025).
And here is the structural point that most vulnerability programs still get wrong. When CISA issued Emergency Directive ED 25-03 for the Cisco ASA campaign — CVE-2025-20333 and CVE-2025-20362, which chain to full unauthenticated device control — it did not simply require patching. Agencies had to collect and transmit memory images, because the actor had modified device ROM to persist across reboot and upgrade. CISA had to re-issue guidance two months later because "patched" devices remained compromised (CISA ED 25-03). The F5 directive, ED 26-01, followed the same shape after nation-state actors spent at least twelve months inside F5's own network exfiltrating BIG-IP source code and undisclosed vulnerability information (CISA).
Actionable takeaway: for internet-facing edge appliances, treat patching as a containment step and not a remediation step. Assume compromise on any KEV-listed edge device that was exposed, and follow the patch with credential rotation, configuration review and — where the vendor advisory supports it — memory capture. Cheap version for a small team: you may not be able to image a firewall, but you can rotate every credential and certificate that device held, review its config against a known-good copy, and check for added SSH keys and non-standard ports. That takes an afternoon and catches the persistence technique used by the Salt Typhoon campaign across 600+ organizations (CISA AA25-239A).
Third-party involvement appeared in roughly 48% of breaches — an approximately 60% year-over-year increase — and only 23% of third-party organizations had fully remediated their MFA issues (SecurityWeek).
The developer supply chain in particular stopped being a theoretical concern. Shai-Hulud, first seen 15 September 2025, was the first true self-replicating worm in npm: it harvested secrets from CI/CD pipelines and cloud metadata endpoints and republished itself into packages under compromised maintainer accounts, prompting a CISA alert (CISA); its November successor reached 25,000+ malicious repositories (Microsoft Security). In March 2026 an actor backdoored a widely-used security-scanning GitHub Action, which LiteLLM's CI auto-installed, which stole LiteLLM's PyPI publishing tokens, which shipped malicious wheels to everyone downstream — a full transitive compromise across GitHub Actions, Docker Hub, npm, PyPI and OpenVSX in five days (Resecurity; LiteLLM). And the Nx "s1ngularity" attack of August 2025 was the first documented weaponization of developer AI agents as an attack tool: malicious package versions detected locally installed AI coding CLIs and invoked them with permission-bypassing flags to enumerate secrets across the filesystem, harvesting 2,349 credentials from 1,079 developer systems (The Hacker News; GitGuardian).
None of these had a customer-side vulnerability to patch. All of them required customer-side action.
Actionable takeaway: create a playbook trigger you almost certainly do not have — "a vendor has disclosed a breach" — whose first three steps are: enumerate every standing token, OAuth grant and API key that vendor holds; revoke and reissue them; then hunt in your own logs for that vendor's identity acting outside its normal pattern. Chapter 11 owns the program; Chapter 14.5 owns the playbook.
If you keep one page from this chapter, keep this one. The left column is not wrong; it is insufficient.
| Domain | 2024–25 posture | 2026 requirement | So what — what breaks if you stay left |
|---|---|---|---|
| Patching | Vulnerability management by CVSS score and monthly cycle | KEV- and exploitation-driven prioritization with tracked SLAs per tier; edge appliances assumed compromised on KEV listing | 23.43% of KEVs are exploited on or before publication day; a 43-day median patch time means the decision was made for you |
| Identity | MFA enforced for humans; annual access review | Phishing-resistant MFA, ITDR, machine and AI-agent identity inventory, token-revocation containment, help-desk verification procedure | AiTM kits and OAuth consent make MFA irrelevant and passwords un-resettable; 79% of ransomware starts at identity |
| Ransomware | Containment-focused; backups exist | Restore testing is non-negotiable; documented clean recovery path; recovery-denial pre-checks on backup, identity, hypervisor and AD CS | Operators now target the recovery path first; an untested backup is a hypothesis, not a control |
| AI | Emerging concern, watch-and-see | AI system inventory, AI risk controls, agent identity governance, post-quantum planning | Agentic intrusion is confirmed twice over; agents inherit standing privilege and need no exploit |
| Playbooks | Static approved PDF, reviewed annually | Adaptive playbooks with explicit decision trees, versioned as code, SOAR-integrated, exercised on a schedule | 22-second broker-to-operator hand-off; nobody reads a 60-page plan at 03:00 and infers the next step |
| Regulatory reporting | One breach clock, usually 72 hours | A parallel multi-clock matrix — 4h, 12h, 24h, 72h, four business days — keyed to different triggers | The 24-hour clocks make a serial notification process fail by construction |
| Supply chain | Annual vendor questionnaire, SOC 2 on file | Standing-token and OAuth-grant inventory, SBOM, pinned CI dependencies, vendor-breach IR trigger | 48% of breaches involve a third party and there is usually nothing on your side to patch |
| Cloud | Misconfiguration scanning, CSPM dashboards | Control-plane logging, CIEM, service-account token audit, "who could this token reach" scoping | 35% of cloud incidents involve valid account abuse; the Sysdig chain used no exploit for escalation |
| Detection | Signature and malware-centric alerting | Behavioral and identity-centric detection, detection-as-code, ATT&CK coverage measured | 82% of detections are already malware-free; a malware-first triage funnel misses four-fifths of reality |
Actionable takeaway: print this table, take it to your next leadership meeting, and mark each row red, amber or green with evidence — not opinion. The red rows are your roadmap, and Chapter 21 sequences them.
Now the uncomfortable part, and I want to be careful here. Every organization below published or testified to what went wrong, at real cost to themselves, so the rest of us could learn from it. That deserves respect, not commentary. These are the most valuable documents in our field.
The policy is universal; the enforcement never is. Change Healthcare's attackers used compromised credentials against a Citrix remote-access portal that did not have MFA enabled, despite company policy requiring MFA on all external-facing systems (Healthcare Dive). Colonial Pipeline's initial access was through "a legacy virtual private network profile that was not intended to be in use," on an account without MFA (Blount testimony). The British Library's published review states it plainly as lesson 3: MFA was in place for all end-user technologies, but not on certain supplier endpoints (British Library review). The shape repeats exactly: the exception is always at the seam with a third party or a legacy system, and a playbook cannot fix it. A preparation checklist that requires periodic enumeration of exceptions can.
The distribution list is a control, and it rots. GAO's Equifax report records that the Apache Struts vulnerability was not identified on the online dispute portal because the recipient list for the patch notice was out of date, so the notice never reached the people who would have installed it. A follow-up scan a week later did not detect it either. Separately, an expired digital certificate meant traffic was not being inspected throughout the breach (GAO-18-559). Two controls that were "in place" on paper and dead in practice.
Safety controls get quietly retired after operational pain. The Cyber Safety Review Board found that Microsoft had stopped its infrequent manual rotation of consumer signing keys in 2021 following a major cloud outage linked to the manual rotation process — a security control abandoned because it caused an incident. The Board concluded the resulting intrusion, which reached mailboxes at 22 organizations and 500+ individuals, "should never have happened" (CSRB report). Every organization has at least one control it silently stopped performing after it broke something. Find yours.
Small intrusions get closed too early. The British Library's lesson 4 is the one I quote most often: an in-depth security review should be commissioned after even the smallest signs of network intrusion, because it is relatively easy for an attacker to establish persistence and thereafter evade routine precautions (British Library review). Mandiant's data agrees from the other direction — "prior compromise" is now the #1 ransomware initial vector at 30%, doubled from 15% (M-Trends 2026). The intrusion you closed last quarter is a leading indicator.
Risk accepted in small pieces is still risk. British Library lesson 7: the Library's processes appropriately escalated out-of-appetite risks, but were less effective in modeling the amount of low-level risk being carried in aggregate. Fifty accepted exceptions do not add up to fifty small problems. Chapter 16 covers aggregation.
The common thread across all five is not incompetence. It is that a document approved in peacetime described a world that had drifted. Actionable takeaway: give every playbook a last_tested date in its header and a rule that an untested playbook reverts to Draft status. If your document control system cannot enforce that, put the playbooks in git where a CI check can. Chapter 2 shows you how; Chapter 18 shows you how to generate the test dates.
Chapter 15 owns the detail, every clock and every trigger. Here is the shape, so you know what you are walking into.
The change is not that deadlines got shorter. It is that there is no longer one deadline. A single ransomware incident at an EU-regulated financial firm with US operations and personal data in scope can simultaneously run DORA's 4-hour initial notification, NIS2's 24-hour early warning, GDPR's 72 hours, an SEC materiality determination on a four-business-day fuse, US state clocks with a 30-day floor, and — if a payment is made — a fresh 24-hour clock triggered by the business decision, not by the attack.
Five status points worth knowing today, 5 September 2026:
One more, six days away as I write, that gets missed because it does not look like a security regulation: the EU Cyber Resilience Act's Article 14 reporting obligations apply from 11 September 2026. If you manufacture a product with digital elements sold into the EU, an actively exploited vulnerability in your product starts a 24-hour clock — regardless of whether your own network was touched at all (European Commission).
Actionable takeaway: capture four separate timestamps for every incident — when you became aware, when you reasonably believed an incident occurred, when you determined it was material, and when any payment was disbursed. These diverge by days, and different regimes run from different ones. A single "incident start" field in your ticketing system cannot carry all four, and your contemporaneous log is the only evidence of when each state arose.
Three reading paths. Pick the one that matches why you opened this.
Path 1 — Build a program. Read in order, Chapters 1 through 21, and treat Chapter 21 as the sequencing authority rather than doing the domains in the order they appear. Order matters more than coverage here: identity (Chapter 4) precedes detection (Chapter 9), because detections on a compromised identity plane produce confident nonsense; recovery (Chapter 12) precedes response tooling (Chapter 17), because automating a response you cannot recover from is an expensive way to be wrong faster.
Path 2 — Respond tonight. Go straight to Chapter 13 for incident command and severity, then to the specific scenario playbook in Chapter 14, then to Chapter 15 for the notification clocks. Read Chapter 15 in parallel with the technical response, not after it — the clocks do not wait for your forensics. If you have five minutes and an active incident, the sequence is: declare, name an Incident Commander, open the right playbook, start a written timeline.
Path 3 — Prove coverage. Start with Chapter 3 to map your program against the CISO MindMap, then Chapter 16 for framework crosswalks and board metrics, then Appendix A — the master checklist assembled from every chapter — as your evidence register.
The checklist codes. Every chapter ends with testable control statements carrying a domain code and number: LAND-01, IAM-07, RES-12. They are stable identifiers, so you can cite one in an audit response or a remediation ticket and it will still mean the same thing next year. Each is written so an auditor can mark it true or false.
The tiers. Each item carries [IG1], [IG2] or [IG3], using CIS Implementation Group semantics. IG1 is essential cyber hygiene — the minimum any organization needs, achievable without a dedicated security team, and where a small organization should finish everything before starting anything in IG2. IG2 assumes dedicated security staff. IG3 is for organizations facing targeted, sophisticated adversaries. The tiers are cumulative (CIS Implementation Groups). Where a control is expensive, I say what the cheap version is — because a control you cannot afford is not a control, it is a wish.
The checklist below is different from every other one in this book. It is not a control set; it is a triage tool. Each unchecked box points you at the chapter you most urgently need. Answer honestly — nobody is auditing this one, and lying to yourself here costs more than lying to an auditor.
Actionable takeaway: work the checklist below before you read another chapter, and write the result down with a date on it. Then read the chapters your unchecked boxes name, in the order they appear. Not the chapters that sound most interesting. The ones you failed.
Stay patched, stay paranoid, and remember: the attacker does not need to be sophisticated if your exception list is long enough.
Readiness self-assessment. Each unchecked box names the chapter you need most. Work top to bottom — the order reflects what fails first.
[IG1] [ID.AM] [CIS 1] [CIS 2][IG1] [PR.AA] [CIS 5] [CIS 6][IG1] [PR.AA][IG2] [RS.MI][IG1] [RC.RP] [CIS 11][IG2] [RC.RP][IG1] [ID.AM] [CIS 7][IG2] [PR.AA] [GV.SC][IG2] [GV.SC] [CIS 15][IG1] [PR.AT] [CIS 14][IG2] [ID.AM][IG2] [RS.CO]last_tested date and a status, and any playbook untested for more than 12 months is marked Draft rather than Active. If false, read Chapter 2 and Chapter 18. [IG2] [RS.MA] [CIS 17][IG1] [RS.CO] [CIS 17][IG2] [DE.CM] [ID.IM]