Escalation working example
The first scenario: the finance-team handoff to IR
Handing the finance-team intrusion to IR
Risk said P1. Two confirmed compromises, lateral movement into a PCI-scoped cloud platform via SSO. Escalation now turns the case over to incident response.
Step 1. Confirm criteria met
Pre-defined criteria check: confirmed malicious activity ✓, business-critical systems affected ✓ (PCI-scoped platform), Lateral Movement Adversary traversal from the initial-access host to other hosts inside the environment. Each hop expands the blast radius and adds new entities for Subject analysis. Often piggybacks on legitimate authentication, which is what makes it hard to detect. ✓ (federated SSO from compromised identity). Three triggers, all confirmed during Uncover. No discretion required; escalation is automatic, and as the callout below this example admits, it was overdue.
Step 2. Choose the path
Internal: Tier 2 incident responder, on-call. External: Compliance notified (possible PCI exposure flagged during Scope). Legal counsel looped in (GDPR assessment underway). Cloud finance platform vendor request escalated. No law-enforcement engagement at this stage.
In parallel, the analyst executes the SOC’s pre-authorized immediate actions: disable dlin’s account, isolate the two confirmed hosts, terminate the federated SSO session. The authority comes from the playbook, agreed with IR in advance. Containment beyond that list waits for IR’s strategy.
Step 3. Build the packet
Nine sections, written and attached:
- Summary: phishing-driven intrusion, 2 hosts compromised, federated SSO into PCI-scoped platform, P1.
- Timeline: 09:08 dlin interactive login → 09:11 macro execution and alert fired → 09:23 federated SSO → 14:00 P1 declared.
- Entities: 3 primary, 3 secondary, 1 downstream system.
- Evidence chain: Endpoint Detection and Response (EDR) Security technology that continuously monitors and responds to threats on endpoint devices, providing advanced threat detection and incident response capabilities. , network, identity, mailbox, SaaS. ATT&CK chain documented.
- Risk verdict: high impact, high likelihood, P1.
- Containment taken: dlin’s account disabled, two hosts isolated, federated SSO session terminated, all from the pre-authorized immediate-actions list. Cloud platform queries paused. Containment strategy beyond the list is IR’s.
- Artifacts: file hashes, domain Indicators of Compromise (IoC) Atomic, replayable artifacts that, when observed, suggest an intrusion has occurred or is in progress: file hashes, IPs, domains, registry keys, certificate fingerprints, and similar discrete observables. Behavioral patterns (process trees, sequence of actions) are not IoCs; they live one layer up as TTPs. , screenshot of the originating email, ATT&CK technique chain.
- Open questions: cloud platform vendor response pending; mobile device activity not yet reviewed.
- Communication record: 14:02 SOC manager paged; 14:08 Tier 2 IR notified; 14:18 compliance flagged (possible PCI exposure); 14:22 legal looped in (GDPR assessment); 14:35 cloud finance platform vendor request opened.
Step 4. Notify stakeholders
Tier 2 IR notified directly. Compliance notified with regulatory implications. Legal looped in. SOC manager informed for shift visibility. The vendor request to the cloud platform is sent in parallel.
Step 5. Transition cleanly
The triage analyst stays on standby for questions but does not continue the investigation. The IR responder owns the case from here. The triage record is locked, the handoff packet is the authoritative reference, and Tier 2 begins work from a complete starting point rather than from scratch.
What a less experienced analyst could miss: that “standby” means stop. Running one more query against the compromised hosts after handoff feels helpful, but it forks the record IR just inherited: new access timestamps on evidence, findings that live outside the packet, two investigators pivoting on the same entities without coordination. If a new idea surfaces after the handoff, it goes to the IR owner as a message, not into the environment as a query.
Read the timeline critically: this P1 was declared late
Hold the packet’s own timeline against the criteria page. The federated session into the PCI-scoped platform began at 09:23, and the moment Uncover validated the macro chain, the four-day-old C2 domain, and that session, three canonical criteria were confirmed, hours before the 14:00 declaration. Under the break-glass rule, this case escalates from inside Uncover: IR gets paged at the moment of that third confirmation, the warm handoff happens then, and the Scope → Uncover → Risk work you read in the previous chapters continues under IR’s clock as scoping support. The walkthrough keeps the 14:00 timestamp because it is the honest record of methodical phase-walking on a live intrusion, which is exactly the failure mode the criteria exist to prevent. Learn the packet from this example; do not learn the clock.
Key Takeaway
Escalation moved the case from triage to incident response without losing context. The handoff packet is the artifact that made the transition clean. The IR responder started from the packet instead of re-running the investigation.A second scenario: closing the Cursor benign true positive at triage
Not every Escalation phase ends in a handoff to IR. The Cursor IDE Empire-pattern case that began in the Alert chapter has worked through Subject, Scope, Uncover, and Risk, and Risk produced a defensible low-residual-risk verdict. The Escalation phase still runs, but the outcome is different: a documented close at triage, not a transfer to IR. The methodology demands the same rigor for the close as for the escalation. The two walkthroughs are also written at different depths on purpose: the finance case above is the summary view (what each step produces), while this one is the deep dive, showing the actual content of the record section by section. One reading note: this is a different case on a different day. Its 14:03-15:18 timeline below is unrelated to the finance case’s 14:02-14:35 notification record above, despite the near-identical clock times.
Closing the Cursor case with a documented triage record
Risk concluded: low residual risk, signed vendor binary, behavioral baseline match, no persistence, no credential access, two named telemetry gaps explicitly accepted. Escalation now produces the close-at-triage record.
Step 1. Confirm closure criteria met
Closure criteria check: no confirmed malicious activity ✓, no impact to business-critical systems ✓, no lateral movement ✓, no persistence or credential access ✓, residual risk explicitly bounded ✓. Five criteria. The case meets the bar for documented close, not escalation.
The methodology does not treat “close at triage” as a lesser outcome. It demands the same evidentiary standard: five named criteria, each backed by Uncover findings, each defensible to a peer or auditor.
Step 2. Choose the path
Internal: the detection-engineering team is notified because the rule that fired is over-broad for macOS developer hosts. External: no compliance notification (no regulated data in scope). Manager: SOC manager informed for shift-visibility and review-queue assignment, not for action. User: no user notification; the activity was legitimate, no disruption needed.
The “path” for a close-at-triage is a quieter set of channels than an IR escalation, but it is not zero. Every channel that does receive a notice gets a specific, named reason.
Step 3. Build the closure record
All nine handoff-packet sections, written and attached, same structure as a full escalation, with the verdict reversed:
- Summary: EDR alert on a developer macOS workstation; signed Cursor IDE helper matched an Empire behavioral pattern at the surface, but signature, install path, peer baseline, and absence of persistence all support legitimate IDE behavior. Closed at triage with documented confidence and explicit coverage gaps.
- Timeline: 14:03 alert fired → 14:08 Alert phase complete → 14:22 Subject complete → 14:30 Scope complete → 14:58 Uncover complete → 15:10 Risk verdict → 15:18 closure approved by SOC manager.
- Entities: 1 user, 1 host, 1 vendor binary. No secondary entities required by the evidence.
- Evidence chain: EDR process tree, network destinations, signing chain, MDM compliance record, peer-group baseline. ATT&CK chain explicitly empty, the activity does not map to any technique.
- Risk verdict: medium-high impact if real, low likelihood, low residual risk. Verdict justified in case notes.
- Containment taken: none. The activity was legitimate; no isolation, no account changes, no policy action.
- Artifacts: EDR query, signing-chain validation, peer-baseline comparison, vendor-endpoint TLS metadata. All linked from the case.
- Open questions: none requiring further investigation. One detection-engineering improvement ticket created (rule tuning for macOS developer host class).
- Communication record: SOC manager notified 15:11 (case visibility). Detection-engineering team notified 15:14 (rule-tuning request). No user notification, no compliance notification, no vendor notification.
What a less experienced analyst could miss: what actually makes this close defensible. The 15:18 manager approval distributes accountability; it does not create the defense. If the same alert fires in three weeks and turns out real, the artifact that protects the analyst is this record: five criteria each tied to a named finding, the gaps admitted, the reopening conditions written down. A close that leans on “my lead agreed” instead of the evidence is one personnel change away from indefensible.
Step 4. Notify the right people
Quiet, targeted, and traceable. The SOC manager gets shift visibility. Detection engineering gets the rule-tuning ticket with the specific signal that produced the benign fire. Nobody else needs to be told; loud notifications for a documented benign close train the team to discount future ones.
Step 5. Hand to Documentation
The Documentation phase picks up the closure record and finalizes it as the audit-quality event report. The triage analyst stays available for the closure review but does not continue the case: there is nothing to continue. The detection-engineering ticket becomes a separate workstream owned by that team.
Close at triage is not 'just close'
The Cursor case demonstrates the methodology’s hardest call: deciding not to escalate when the pattern matches but the evidence does not. Done well, this close is more disciplined than a routine escalation, because the analyst is asking the reader to trust the absence of compromise. The closure record built on the nine handoff-packet sections, the explicit Risk verdict, the named coverage gaps, and the detection-engineering feedback are what make the close defensible months later.
A third scenario: escalating the token theft from inside Uncover
The finance case’s callout admitted its P1 was declared late. Case C, the SaaS token theft, shows the break-glass rule working as written: the escalation fires mid-phase, the moment the criteria are confirmed, while the attacker still holds a live session.
Escalating the hijacked session on the trigger
At 10:20, inside Uncover, the evidence chain confirmed active compromise with live persistence: a replayed session still valid, an OAuth grant with standing mailbox access, bulk collection already completed. Risk's verdict took minutes and confirmed P1 with an ordered containment list. Escalation begins mid-investigation, by design.
Step 1. Confirm criteria met
Criteria check at 10:20, against the canonical categories: confirmed malicious activity ✓ (the session join plus attacker tradecraft in the tenant audit), high impact ✓ (a regulated customer-correspondence mailbox, bulk-collected at 09:26), exfiltration ✓ (the OAuth app’s sync pulled that mailbox content out to attacker infrastructure). Three triggers. The live session and standing grant are not a fourth criterion; they are the urgency multiplier on all three. Uncover stops mid-thread; the remaining open items travel with the packet as pending instead of delaying it.
Step 2. Choose the path
Internal: Tier 2 IR paged at 10:21, warm handoff within minutes. External: compliance was engaged during Scope, so the GDPR assessment is already running; finance was warned during Scope to verify payment instructions out-of-band. The vendor request for app read-detail is escalated to urgent.
In parallel, the analyst executes the pre-authorized immediate actions in the order Risk specified: 10:24 all sessions revoked at the IdP, 10:26 the OAuth grant revoked, 10:28 the inbox rule disabled and preserved as evidence, 10:31 credential reset and MFA re-enrollment. The ordering is the containment; the reset alone would have contained nothing.
Step 3. Build the packet
- Summary: AiTM session theft on a customer-success account, BEC staging interrupted after bulk collection, before any outbound mail. P1, live persistence contained at 10:26.
- Timeline: 08:47 legitimate sign-in → 08:52 lure click → 09:03 token replay from VPS ASN → 09:06 hiding rule → 09:09 OAuth consent → 09:14-09:26 bulk sync → 09:15 alert → 10:20 criteria confirmed, escalation fired → 10:24-10:31 ordered containment.
- Entities: 3 primary (account, session, app), 3 secondary, CRM downstream, attacker infrastructure named.
- Evidence chain: IdP sign-in log, tenant unified audit, gateway click record, tenant-wide sweep with recorded negative results. ATT&CK chain documented end to end.
- Risk verdict: high impact (collection completed), high likelihood (no surviving benign hypothesis), P1.
- Containment taken: the four ordered identity actions, all from the pre-authorized list, timestamped. Tenant-wide app-publisher block and ASN hunt rule recommended to IR, not taken unilaterally.
- Artifacts: the session’s two presentation records, the rule definition, the consent-grant event, the sync aggregates, the phishing URL and kit fingerprint.
- Open questions: item-level read detail pending vendor; GDPR determination with compliance; whether any other tenant in the company’s estate saw the same lure domain.
- Communication record: 10:21 IR paged; 10:23 SOC manager informed; 10:27 compliance updated with the collection volume; 10:33 finance re-confirmed on out-of-band payment verification.
Step 4. Notify stakeholders
The notification set is wider than a routine P1 because money and regulated data are both in motion: IR owns the technical response, compliance owns the notification clock, finance owns the fraud-prevention posture. Each got a message scoped to what they own, and each message is in the record.
Step 5. Transition cleanly
IR inherits a contained-but-open case: the attacker is locked out, but what they read, whether the kit harvested the password for later use, and whether other estates saw the lure are all live questions. The triage analyst hands over the packet, walks IR through the containment timestamps, and returns to the queue. The tenant sweep queries transfer with the packet so IR re-runs them on their own cadence instead of reinventing them.
The counter-example to the late P1
Hold this timeline against the finance case’s. Same methodology, opposite clock discipline: 65 minutes from alert to escalation, with containment executing while the packet was still being written. The difference is not analyst speed; it is that the escalation criteria were treated as tripwires during Uncover instead of as a checklist at the end. This is what the break-glass rule looks like when it works.
Key Takeaway
Escalation’s deliverable is the structured record that survives the case, whether the path is “to IR” or “closed at triage.” The finance-team intrusion produced an IR handoff, the Cursor benign true positive produced a close-at-triage record, and the token theft produced a mid-phase break-glass escalation with ordered identity containment. Same chapter, same methodology, three different verdicts.