Case files: four cases, end to end
On this page
Every chapter of ASSURED teaches its phase on the same cases. That keeps the method concrete, but it splits each case into seven pieces on seven pages. The case files put each case back together: what happened, how it ended on both verdict axes, the priority and the clock it ran on, the decision and when it was made, the records it left, and where in each chapter the long form lives.
How to use the case files
- Before a chapter: read the case card, so the chapter example can show only that phase’s steps.
- After the method: follow one case’s thread through all seven stops in order. The decisions read differently once you know how the case ended.
- To practice: work Case D cold from its learner packet before reading the page, or use the hands-on exercises.
- To teach: the teaching guide walks the threaded cases in session, and the facilitator kit adds a capstone case that shares no surface with them.
All four cases are synthetic: names, hosts, addresses, module names and identifiers are fictional (reserved .example domains, RFC 5737 documentation addresses), and none is drawn from a real incident or codebase.
Cases A, B and C are threaded: each chapter’s worked example carries all three, under the anchors #case-a, #case-b and #case-c. Each worked example is the phase-specific slice of a case, showing only that phase’s steps; this page holds the whole thread, so come back here for what happened before or after the phase you are reading. Case D is the one the threaded cases cannot be. They each end decisively; Case D is a false positive whose activity question stays open, works a P3 to its named triggers, and closes undetermined.
Case A · The finance-team phishing intrusion
A fake invoice page talks a finance analyst into pasting a PowerShell download cradle into the Run dialog, and the stolen browser session is replayed against the cloud finance reporting platform while the case is still being worked.
- Case
- CASE-2026-0303-007, 2026-03-03 ; incident INC-2026-0303-001
- Depth
- Level 1, then Level 2 in Uncover (regulated data plausibly accessed by the replayed session)
- Verdict
- Detection: true positive · Activity: malicious · Status: escalated
- Priority
- P1 High/High at Risk. Escalation tripwire: criterion 1 confirmed at 09:24, at the end of Alert; criteria 2 and 3 confirmed at 11:05.
- Decision
- Escalate, 14:00 UTC. Escalate to IR as a P1: page, warm handoff on IR's bridge, preservation, then reversible containment. The decision came 4 hours 36 minutes late.
- Teaches
- The late P1: a confirmed criterion pages from the phase that confirms it, not after the loop finishes.
- Alert (09:24): The execution chain is confirmed at High confidence: criterion 1 is met and the escalation tripwire should fire. The record flags it; nobody pages.
- Subject (09:38): dlin, laptop-finance-09 and dlin's federated cloud identity are primary. Sign-ins are clean as of 09:33, and the tokens are presumed exposed.
- Scope (09:50): Regulated data in reach is flagged and compliance is engaged at 09:45. The boundary records that the page was not sent.
- Uncover (13:05): 11:05: the replayed session from 198.51.100.23 is found and criteria 2 and 3 are confirmed. A second laptop ran the same chain off-network and raised no alert.
- Risk (13:55): High/High, P1, confidence High. Recommends: escalate now, preserve first, then reversible containment.
- Escalation decision (14:00): Escalate to IR. Paged at 14:01, acknowledged at 14:08, preservation 14:10 to 14:19, hosts isolated and sessions revoked 14:20 to 14:21.
- Documentation : The triage-side event report is finalized and linked to IR's report; the detection gap goes to detection engineering.
What would have changed it
- Paging at 09:24, with preservation and containment by about 09:35, would very likely have made the 10:41 replay fail, because the sessions would have been revoked and sign-in blocked.
- An IR-approved purge in that window would likely have removed the message before the second finance user followed its link at 10:52.
- The replay found at 11:05 added criteria 2 and 3. It was not the trigger: the trigger was already met at 09:24.
Case B · The Cursor IDE Empire-pattern alert
An EDR behavioral rule first written for an Empire-family agent fires when the Cursor IDE's extension host opens encrypted connections from a developer's managed macOS laptop.
- Case
- CASE-20260311-017, 2026-03-11
- Depth
- Level 2 (crown-jewel access by the activity plausible until credential-path reads were ruled out)
- Verdict
- Detection: true positive · Activity: authorized (benign true positive) · Status: closed
- Priority
- P3 High/Low at Risk. Matrix cell: High impact (SSH keys reach the build environment), Low likelihood, High confidence.
- Decision
- Documented close, 18:08 UTC. Documented close after the forward watch came back clean, through the five-item closure check. The SOC manager approved the High-impact close at 18:10.
- Teaches
- The benign true positive: a correct detection of authorized activity, closed durably and fixed on the context side, not by loosening the rule.
- Alert (14:08): A signed, notarized chain; allowlisted destinations; a child running a script from inside the app bundle. No criterion confirmed or suspected; depth set to Level 2.
- Subject (14:22): The installed version and hash match the vendor release. The user's SSH reach into the build environment drives impact; the extension layer stays open.
- Scope (14:30): A narrow boundary, one extension-layer check, a count-only fleet query, and the four-hour forward watch that becomes the P3 trigger.
- Uncover (15:02): Extension, MCP and workspace-task inventory clean, and the agent's commands trace to the user's prompt; eleven peer Macs on the same build show the same behavior. Verdict ready at High confidence.
- Risk (15:10): High impact, Low likelihood, High confidence: High/Low, P3 on the high-impact clock. Recommends: keep working to the forward watch, then close if clean.
- Escalation decision (18:08): 15:11: the P3 hold is recorded. 18:05: the watch is clean and the cell unchanged. 18:08: documented close; no containment, so no handoff packet.
- Documentation : The event report is finalized; the enrichment request and draft entry PTN-031 go to detection engineering, and the rule logic stays unchanged.
What would have changed it
- A helper child running code from outside the app bundle, or an extension not on the approved list, or a new MCP server configuration, or an agent command with no matching user prompt.
- A destination outside the vendor allowlist, or a Cursor binary with a signature that is not Anysphere's.
- Reads of credential paths, or LaunchAgent, LaunchDaemon or login-item writes, or the same behavior on a non-developer host.
Case C · The replayed session on the mail tenant
An adversary-in-the-middle phishing kit captures a customer-success lead's session cookie; the session is replayed from a VPS to hide payment mail with an inbox rule and to consent a mail-reading OAuth app.
- Case
- CASE-20260312-022, 2026-03-12
- Depth
- Level 2
- Verdict
- Detection: true positive · Activity: malicious · Status: escalated
- Priority
- P1 High/High at Risk. Escalation tripwire: criterion 1 confirmed at 09:22, at the end of Alert; high-impact and exfiltration criteria confirmed at 10:08.
- Decision
- Escalate, 09:22 UTC. An early Escalation decision on the escalation tripwire: page IR, preserve, contain reversibly and verify, then the IR-approved resets. Initial packet at 09:28, complete packet at 10:24.
- Teaches
- Ordered identity containment: preserve, contain reversibly, verify, then the approved non-reversible steps.
- Alert (09:22): A session minted through a hosting address 56 seconds after the click, then replayed from a VPS: criterion 1 confirmed, and the escalation tripwire fires at the end of Alert.
- Subject (09:44): Scoping support under IR. A second user's password was relayed through the same proxy, MFA not completed; containment verified at 09:31.
- Scope (09:58): Four primary entities, the inbox rule as an artifact, the CRM downstream. Compliance engaged with 09:22 on record as the candidate awareness time.
- Uncover (10:16): About 1,800 messages read by the app, billing threads included, and two payment searches. High-impact and exfiltration criteria confirmed and sent to IR at 10:08.
- Risk (10:20): High/High, P1, and P1 by criterion. Recommends app blocking, consent restricted to verified publishers, and phishing-resistant MFA.
- Escalation decision (09:22): Records the 09:22 escalation, the two packet passes and the communication record, kept off the compromised mail tenant.
- Documentation : The triage-side record closes and links to IR's open case; compliance works from the message list.
What would have changed it
- An alert on an MFA-satisfied sign-in from a hosting network within two minutes of a recorded link click would have fired at 08:53, ten minutes before the replay.
- A standalone alert on a session re-presented from a new network with no authentication ceremony would have paged at 09:03; a consent-grant alert for unverified publishers would have fired at 09:09.
- The control gaps go to IR's recommendations: push MFA that is not phishing-resistant, no token protection or compliant-device requirement, and user consent open to unverified publishers.
Case D · The burst that never happened
A seven-hour identity-log backlog arrives in 54 seconds and fires a password-burst rule; under the data error sits one real, unexplained sign-in attempt that carried the user's current password.
- Case
- CASE-2026-0923-004, 2026-09-23
- Depth
- Level 1 throughout
- Verdict
- Detection: false positive (data) · Activity: undetermined · Status: closed
- Priority
- P4 Medium/Low at Risk. P2 on the first scoring (09:40), handed back by Tier 2 (10:27), P3 on named triggers (10:41), P4 on re-score (18:06).
- Decision
- Documented close, 18:20 UTC. Documented close with the activity verdict still undetermined: gaps named, the exposure removed (password changed), reopen triggers written.
- Teaches
- The data false positive, the open P3, the handback, and a close on an undetermined verdict.
- Alert (08:19): Event time against ingest time shows an arrival, not a burst: false positive (data) at High confidence. The activity question stays open.
- Subject : Three strands: her phone blocked by policy, her laptop's normal success, and three attempts from a new hosting address, the third with her current password.
- Scope : One identity, one indicator, a 24-hour forward watch, and a written boundary on evidence quality: every identity rule was blind, then mistimed, overnight.
- Uncover : Who typed her password at 05:48? The ledger keeps two hypotheses open; the user is unreachable until evening.
- Risk (10:41): First pass read missing evidence as High (P2). After the handback: Medium/Medium, confidence Low, P3 on three named triggers.
- Escalation decision (18:20): The P2 escalation comes back with a reason; at 18:06 the re-score reads Medium/Low, P4, and the case closes undetermined through the closure check.
- Documentation : The pipeline fix, the connector-lag alert, the re-run of the blind window, and the handback counted by reason in the monthly report.
What would have changed it
- The phone's blocked refreshes coming from 203.0.113.163 would have put her phone and the 05:46 device on one network: benign-confirmed by mid-morning, without the P3.
- A plain "no, I didn't try to sign in anywhere" would have made likelihood High on evidence: Medium/High, P2, escalate within 4 hours, with the password change first.
- An approved push, a second password success or an MFA method added from a new address would have confirmed criterion 1, and the escalation tripwire would have made the case P1.
The four cases side by side
| Case | Depth | Detection | Activity | Priority | Clock | Decision | Records |
|---|---|---|---|---|---|---|---|
| Case A | Level 1, then Level 2 in Uncover | true positive | malicious | P1, High/High | P1: page immediately. Declared at 14:00, 4 hours 36 minutes after the tripwire was met | Escalate, 14:00 UTC | Nine-section handoff packet (complete 14:40); Event report, linked to IR's report; Detection-gap feedback: the rule's network leg read only the web proxy |
| Case B | Level 2 | true positive | authorized (benign true positive) | P3, High/Low | P3 on the high-impact clock: a four-hour forward watch, 14:03 to 18:03, as the named re-score trigger | Documented close, 18:08 UTC | Event report under the decision header, with known-good indicators; Alert-enrichment request (extension ID, child command line, destination set); Draft pattern entry PTN-031, keyed to the exact tuple |
| Case C | Level 2 | true positive | malicious | P1, High/High | P1: paged at 09:22, IR acknowledged at 09:28, inside the 15-minute fallback | Escalate, 09:22 UTC | Initial packet at the warm handoff (09:28) and the complete nine-section packet (10:24); Item-level message list to compliance (10:22); Event report, linked to IR's case |
| Case D | Level 1 throughout | false positive (data) | undetermined | P4, Medium/Low | P3: re-score within 24 hours on named triggers, then P4: documented close within the queue SLA | Documented close, 18:20 UTC | Alert report with the hypothesis ledger and both priority changes; Tier 2 handback receipt and the shift-handover line; Tuning request DE-0418 (parser fix and connector-lag alert) |
None of the four is a typical day on its own. Together they cover the outcomes a queue produces: an escalation that came late, an escalation that came on time, a benign true positive closed durably, and a false positive whose activity question never fully closed.
Key takeaway
A case is the unit the method works on, and its facts should not change between chapters. Read a case’s card first, follow its thread through the phases, and check the decision against the clock the band set. The interesting question is rarely what the verdict was; it is when the case could have known, and what it did at that moment.Technical details verified . Product names, defaults and retention change; check your own tenant.