Scope working example

Step 1. Regulatory check

The compromised user dlin has read access to the cloud finance reporting platform, which feeds the vendor payment workflow and stores vendor-contact records, including those of people in the EU. Two regulated classes are plausibly in reach. Cardholder data, and with it the cardholder data environment Cardholder Data Environment (CDE) The system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, plus system components with unrestricted connectivity to them (PCI DSS). Connected-to and security-impacting systems are in PCI scope but are not part of the CDE. An alert touching the CDE sets the regulatory flag in Scope. , is a question only if the platform touches card data at all (virtual-card vendor payments, for example); nothing in the case shows that, so PCI DSS is a possibility for compliance, who own that determination. Personal data of vendor contacts in the EU makes GDPR a candidate regime: whether it attaches is an Article 3 question for the Data Protection Officer (DPO) Data Protection Officer (DPO) The role GDPR (Art. 37-39) requires of some controllers and processors to advise on and monitor data-protection compliance and to act as the contact point for supervisory authorities. In triage, the DPO or privacy lead decides whether a personal-data breach is notifiable; the SOC supplies the facts and the awareness timestamp. or privacy counsel, and the analyst’s contribution is the tag and the timestamp. If the organization is publicly listed, the platform is also a likely SOX-relevant financial-reporting system. “Can reach” is enough to tag the case; nothing on the platform has been seen accessed.

Decisions: Commit two timestamps to the record: the alert (09:11) and the moment regulated data was recognized as in reach (09:42). Tag the case PCI-possible and GDPR-candidate (and SOX-candidate if listed). Engage compliance and the DPO now (09:45) so any notification clock can run in parallel with the technical investigation, and have the platform’s audit logs held past rotation. Because the workflow pays vendors, ask accounts payable to verify any vendor bank-detail change out of band until the case closes.

Step 2. Time window

The alert is a phishing-driven intrusion that fired today, with the stage still beaconing. The Subject phase did not find slow-burn signals. The default window for this threat type is 24 to 72 hours of historical review, with a 4-week look at the primary entities to confirm no prior staging.

Decisions: Set the primary window at 72 hours pre-alert through current time: the top of the default range, widened from Subject’s recommended 24 hours so the window certainly covers the lure’s delivery and any earlier contact or reconnaissance from the sending domain. Set the 4-week extended check on all three primary entities. Retention check: endpoint telemetry keeps 90 days and identity telemetry keeps 1 year; both cover the windows.

Step 3. Entity boundaries

Subject handed over a provisional classification. Scope confirms it against the evidence and makes it binding:

• Primary: dlin (user), laptop-finance-09 (host), dlin’s federated cloud identity. Full investigation depth.
• Secondary: The machine account of laptop-finance-09. Finance users 2, 3, and 4, the other recipients of the same email: baseline check of each mailbox and host, upgraded on any signal.
• Downstream: The cloud finance reporting platform dlin’s identity federates into. Inside the boundary as the system the compromised identity can reach; it gets no entity profile of its own, but its authentication and API logs are pinned to the infrastructure check.
• Originating threat: The external sender (accounts@invoice-records[.]example) and its infrastructure (invoice-records[.]example, 203.0.113.77). Tracked as the adversary side of the case rather than as an entity under investigation; these indicators drive the sweeps below and feed Uncover’s threat-intelligence work.
• Sweeps: Every host that resolved or connected to invoice-records[.]example or 203.0.113.77, and every mailbox that received mail from the sending domain or a link to it, over the 72-hour window. A sweep is a snapshot, so it is re-run before Uncover hands off.
• Out of scope (for now): Finance-team hosts and mailboxes that did not receive the email, unless a sweep finds them.

Step 4. Infrastructure check

What can the SOC see for this case?

• In scope: EDR on the laptop and the three recipients’ hosts, cloud identity ( IdP Identity Provider (IdP) The service that authenticates users and issues the tokens or assertions other applications trust: Microsoft Entra ID, Okta, Google Workspace, Ping. Its sign-in and audit logs are first-class evidence in identity, SaaS and cloud cases, and an IdP compromise reaches every federated app. See Federation and Single Sign-On (SSO). ) logs, web proxy and firewall logs, DNS logs, email gateway message trace, mailbox audit.
• Limited: The cloud finance platform’s in-app activity is in the vendor’s logs; the SOC sees authentication events and aggregate API call counts only. In-app detail needs a vendor request.
• Gaps: The web proxy is enforced only on the corporate network and on VPN, so a laptop off both reaches the internet directly and only EDR sees its traffic. If dlin used the platform’s mobile app on a personal phone, the IdP still logs the federated sign-in, but device and in-app activity on the unmanaged phone is invisible to corporate telemetry.

Decisions: Name the cloud-platform gap and the off-proxy gap explicitly, and submit the vendor request for in-app audit logs now (09:48), so the data arrives in parallel with Uncover’s first queries.

Step 5. Hand off to Uncover

The Scope deliverable is a one-page boundary statement Uncover can pin above their query window:

• Threat type: phishing-driven intrusion with a live C2 beacon.
• Time: 72 hours primary (anchor: the alert at 09:11 UTC), 4 weeks extended for the three primary entities; secondaries on the 72-hour window at baseline depth.
• Primary entities: dlin, laptop-finance-09, dlin’s federated cloud identity. Full depth.
• Secondary entities: machine account; Finance users 2, 3, and 4 (recipients, opens unassessed). Baseline depth, upgraded on any signal.
• Originating threat: accounts@invoice-records[.]example, invoice-records[.]example, 203.0.113.77.
• Downstream: cloud finance reporting platform inside the boundary for reachability; vendor in-app logs requested.
• Out of scope: finance-team hosts and mailboxes that did not receive the email, unless a sweep finds them.
• Sweeps: hosts touching the domain or IP, mailboxes receiving from the sending domain or a link to it; 72 hours; re-run before handoff.
• Regulatory: possible PCI exposure (only if the platform touches card data) and candidate GDPR exposure; both determinations owned by compliance and the DPO, engaged at 09:45; candidate timestamps 09:11 and 09:42 in the record.
• Preservation: %TEMP%\upd.ps1 and its hash held; dlin’s RunMRU value exported; proxy-log cleanup paused for the window; platform audit logs held past rotation.
• Infrastructure gaps: off-network hosts bypass the proxy (EDR only); mobile app activity on the cloud platform may be invisible; vendor request submitted.
• Escalation posture: tripwire flagged at Alert (criterion 1, 09:24); the page has not gone out. A federated session from anywhere but the laptop, or execution on a second host, would confirm further criteria.
• Open questions for Uncover: do the three other recipients’ hosts show the same execution chain; were dlin’s cloud session tokens taken or replayed; what do the vendor’s in-app logs show beyond any federated login?
• Time box: first convergence check at 10:35 UTC, 45 minutes into Uncover: converge, re-scope, or pull in a peer or tier the case up. Escalation to IR runs on the criteria and the matrix, not on elapsed time; here the escalation tripwire is already met.

Step 1. Regulatory check

Scope runs the regulatory pass first, as in every case, and records the answer even when it is “none.”

• Source code: sensitive, not regulated.
• Test fixtures: Subject flagged possibly customer-derived fixtures. The fixture registry for the repositories the IDE indexed lists synthetic data only; no real personal data.
• Vendor processing: code context passes through the vendor’s backend to model providers for AI features. The team runs Cursor with Privacy Mode enforced at the team level under the vendor agreement. Recorded; not a trigger.
• Conclusion: no cardholder data, personal data, or PHI in reach. Regulatory: none triggered, with the reasoning recorded.

Step 2. Time window

Subject’s reads agree, so there is no expanding pattern to chase: the window is sized to test the benign read, not to investigate a compromise.

• Primary window: alert minus 1 hour through alert plus 45 minutes (13:03 to 14:48 UTC). Enough to capture the IDE session that produced the alert, the work around it, and everything up to Uncover’s final pull.
• Forward watch: the host stays under EDR and proxy watch for four hours after the alert, to 18:03. If Risk lands the case at P3, this is the named re-score trigger.
• Identity window: the day’s session from the 09:14 SSO sign-in onward.
• Comparison window: the same user’s prior 14 days of IDE activity, used only for behavioral baselining, not for incident reconstruction.
• Extension trigger: any Uncover finding inconsistent with the benign read (an unexpected extension or MCP server, a destination off the allowlist, credential-path reads, new persistence) re-opens Scope. The window extends back to the earliest related artifact, such as the install date of the extension in question, and the case returns to Risk for re-scoring. A confirmed escalation criterion fires the escalation tripwire at once, from any phase.

Extending the window preemptively would spend time investigating the absence of compromise.

Step 3. Entity boundaries

Scope turns Subject’s per-entity reads into boundaries without growing the entity list.

• Primary subject: the developer’s laptop, Cursor Helper (Plugin) and its child process. Full process telemetry, file activity, and network behavior for this host during the time window.
• User context: the frontend engineer. Authentication and authorization checks for the period; no peer-group expansion required because Subject’s relationship-dimension read was clean.
• Extension layer (one bounded check): Subject validated the host binary. It did not validate the code the host runs. Scope adds one check: the installed extension list (~/.cursor/extensions), the MCP server config (~/.cursor/mcp.json and the workspace’s .cursor/mcp.json), the workspace’s .vscode/tasks.json, and the Cursor version, compared against the approved list and the peer population.
• Fleet prevalence (one query): how many managed hosts run this Cursor build with the same extension-host child and destination set over 30 days. Counts only, no per-host investigation.
• Excluded: per-host investigation of other developer laptops and engineers, and the vendor’s infrastructure beyond observable DNS and TLS. Subject’s read was clean on these surfaces; Scope does not re-open them.

What a less experienced analyst could miss: that over-scoping is the failure mode here. It would look like pulling every developer laptop running Cursor into the investigation, or expanding to investigate Anysphere as a vendor. Both are tempting because the binary is the focal artifact. The methodology says no: Subject already validated the binary and its trust chain, and re-opening that question is wasted work. What Subject did not validate is the code the host runs, so the one bounded extension-layer check stays in. Restraint means the smallest boundary that still answers the verdict question, not the smallest boundary.

Step 4. Infrastructure check

The subject surface of one managed developer workstation is genuinely small, so Scope names each source precisely and Uncover does not improvise.

• EDR (CrowdStrike on macOS): primary. Process tree, file activity, network sockets, signing-status events.
• Corporate egress proxy: this device’s destinations and TLS metadata (destination name, certificate, byte counts), to confirm the traffic went to the vendor’s allowlisted endpoints and not to staging infrastructure. It does not inspect content to those endpoints.
• Identity provider: this user’s authentication events from the 09:14 sign-in onward: resets, MFA changes, new devices, sign-in locations.
• MDM compliance record: enrollment, encryption, OS version, the installed Cursor version and hash, and the extension inventory.
• Threat intelligence: passive only. The vendor domains and the binary’s hash, checked for prior incident associations. No active pivots, no speculative attribution.
• Conditionally in: internal source-control access logs for the user’s repositories during the window (pulled if EDR or the proxy shows bulk repository cloning or a push to an unfamiliar remote), and the IDE’s local agent-activity record for the window, to settle whether terminal commands were typed or agent-run. Both read-only.
• Out of scope: per-host review of peer laptops, the vendor’s own infrastructure beyond DNS and TLS observability, any system the laptop did not actually reach during the window.

Step 5. Hand off to Uncover

The Scope deliverable for the Cursor case is deliberately compact:

• Threat type: Empire-style post-exploitation pattern on a developer workstation, leaning authorized IDE behavior.
• Time: 13:03 to 14:48 UTC primary; forward watch to 18:03; identity from the 09:14 sign-in; prior 14 days for behavioral baselining only.
• Subject: one laptop, one engineer, the extension host and its child, the extensions and MCP servers it runs, Cursor’s vendor endpoints. One count-only fleet query. No other expansion.
• Out of scope: per-host review of peer laptops; the vendor’s infrastructure beyond DNS and TLS.
• Environment: EDR, corporate egress proxy, identity provider, MDM including the extension inventory; threat intel passive only. Source-control reads and the IDE’s agent-activity record conditional.
• Regulatory: none triggered; reasoning recorded in Step 1.
• Infrastructure gaps: the proxy sees TLS metadata only, with no content inspection to the vendor’s endpoints; USB device control is not deployed on this host class. Uncover will note these as bounded confidence reductions, not as expansion triggers.
• Escalation trigger: any Uncover finding inconsistent with the benign read re-opens Scope back to the earliest related artifact and returns the case to Risk; a confirmed escalation criterion fires the escalation tripwire.
• Open questions for Uncover: which extension owned the child, and is it the bundled one its path suggests; do the extension, MCP and workspace-task inventories match the approved list and the peers; do the connections match the vendor’s allowlist exactly; does the installed build match the MDM record; is there any activity in the window the benign read does not explain?
• Time box: first convergence check at 15:15 UTC, 45 minutes into Uncover. Any finding that breaks the benign read ends the box early.

Uncover starts inside narrow rails. The case is shaped to confirm or refute the benign read efficiently, not to manufacture a compromise narrative from absence of evidence.

Step 1. Regulatory check

The mailbox holds customer contract and billing correspondence (names, contacts, account details), some of it about people in the EU. GDPR is flagged as a candidate regime (the Article 3 call is compliance’s), and compliance is engaged now, before anyone knows what the attacker read: by phone at 09:50, because the mail tenant is the compromised system. Whether this is a notifiable breach is compliance’s determination. Scope’s job is to put the candidate awareness timestamp on the record: 09:22, when attacker control of a mailbox holding customer personal data was confirmed. GDPR’s 72-hour clock runs from awareness, meaning a reasonable degree of certainty that personal data was compromised, not from full confirmation of what was read. Customer contracts with data-processing terms and the cyber-insurance policy carry their own notice clocks, and both are noted for compliance. The staging pattern points at payment-redirect fraud: if a fraudulent payment instruction has already gone out, finance and legal need to know on a faster clock than the technical investigation, because a bank recall and a law-enforcement report are measured in hours.

Decisions: tag the case GDPR-relevant, record 09:22 as the candidate awareness timestamp, engage compliance, and put finance on notice (09:52, by phone) that payment instructions from or about the customer-success mailboxes need out-of-band verification until the case closes.

Step 2. Time window

The forward edge of the window was open until containment, which now has a time: the reversible actions completed at 09:27 and the replayed session was refused at 09:31. The backward edge is set by the artifacts: the lure arrived at 08:41 and rvega clicked at 08:52 today, but consent grants and rules can predate the alert that finally exposed them.

• Primary window: 08:00 UTC today through containment plus one access-token lifetime (up to 90 minutes on Microsoft Entra ID defaults), so a token issued before the 09:25 revocation cannot act unseen.
• Extended check: 14 days back across the tenant for consent grants to the same application and for inbox and forwarding rules with the same shape, plus rvega’s authentication-method, device-registration and mailbox-forwarding changes over the same 14 days; and 90 days of rvega’s sign-in history, the same baseline window Alert and Subject read, to confirm today was the first foreign presentation.
• Retention check: the 90-day sign-in baseline comes from the SIEM copy, because the IdP console’s own retention can be shorter (for example, 30 days on Microsoft Entra ID P1/P2). The tenant audit log covers the 14-day lookback, and rvega’s mailbox records item-level mail access (on Microsoft 365, MailItemsAccessed is part of Audit (Standard) and on by default for E3/E5 users), so “what did they read” is answerable from the tenant’s own logs. Confirm that coverage per mailbox before promising an answer: without those records, it becomes an inference rather than a lookup.

Step 3. Entity boundaries

• Primary: rvega’s account, the replayed session, the “Mail Backup Sync” OAuth application, and the second user’s credential-exposed account. Full depth.
• Secondary: the shared billing mailbox and the two remaining lure recipients who did not click. Baseline depth, upgraded on any signal. The inbox rule rides with rvega’s account as an artifact.
• Tenant-wide sweep dimension: any sign-in from the proxy IP, any session presented from the attacker ASN Autonomous System Number (ASN) A globally unique number identifying a network routed under a single operator, such as an ISP, cloud provider, or hosting company. During enrichment the ASN behind an IP address tells the analyst who operates it, which is how a connection resolves to a residential ISP, a corporate egress, or a hosting range with a reputation for abuse. , any session ID seen from more than one network, any consent grant to the same app ID, any inbox or forwarding rule matching the same shape (single-character name, payment keywords, move and mark as read), and any MFA method or device registered from either attacker IP, across all users, 14 days. This is a bounded query set, not an open-ended hunt; it is written into the boundary so Uncover runs it once, deliberately. The per-identity counterpart, for rvega and the second user, is the identity-persistence sweep.
• Downstream: the CRM rvega’s SSO reaches. Inside the boundary as reachable-from-the-session; its authentication logs are already in the infrastructure check, and it gets no deeper look unless the session touched it.
• Originating threat: the lure domain docs-share-portal[.]example, the proxy IP 203.0.113.41, and the VPS IP 198.51.100.77, feeding Uncover’s intelligence work.
• Out of scope: rvega’s laptop beyond the completed EDR check that cleared it, and every SSO-connected application other than the CRM with no sign-in from attacker infrastructure, pending the sweep results.

Step 4. Infrastructure check

• In scope: IdP sign-in and risk logs, the IdP audit log (authentication-method and device-registration events), the tenant unified audit log including item-level mail-access records, message trace, the email gateway’s click and delivery records, CRM authentication logs.
• Limited: nothing that blocks the regulatory question. The app’s reads appear in the tenant audit as item-level records. For the regulatory assessment, every item in any folder the audit shows as synced is treated as accessed; compliance does not wait for item-level detail the platform never recorded.
• Gaps: the AiTM Adversary-in-the-Middle (AiTM) A phishing technique in which a kit relays the victim's real sign-in through an attacker-run proxy, capturing the password and the session cookie the identity provider issues after MFA. The attacker then replays the cookie from their own infrastructure, so MFA is satisfied once, by the victim, and never asked again. Push, SMS and OTP factors do not stop it; phishing-resistant factors (FIDO2 security keys, passkeys) do, because they are bound to the real site's origin. Triage tells: a sign-in from a hosting ASN minutes after the user's own, the same session presented from two networks, and a newly registered lookalike domain in the click path. ATT&CK T1557, ATT&CK T1539. proxy sits outside the environment entirely; what the kit captured beyond the sign-ins the IdP recorded, and where it sent them, is reconstructable only from the gateway’s URL verdict and the kit family’s known behavior, not from logs.

Decisions: point Uncover at the item-level records in the tenant audit, and record the proxy blind spot as a permanent evidence boundary for this case.

Step 5. Hand off to Uncover

• Threat type: AiTM session theft with BEC Business Email Compromise (BEC) Phishing's no-payload variant: an email impersonating an executive, vendor, or counterparty that asks the recipient to move money or change payment details. With no attachment to detonate and no link to rewrite, gateway verdicts stay quiet; the evidence lives in lookalike domains, display-name and reply-to mismatches, and hijacked threads sent from a compromised counterparty's real mailbox. Consistently among the costliest crime types by reported losses in the FBI IC3 Internet Crime Reports (about $3 billion in the 2025 report). staging.
• Time: 08:00 UTC on 12 March 2026 through containment plus one token lifetime; 14-day tenant lookback for grants and rules; 90-day sign-in history for rvega from the SIEM copy.
• Primary entities: the account, the session, the app, the second user’s account. Full depth.
• Secondary entities: billing mailbox, two non-click recipients, with the inbox rule as an artifact. Baseline depth.
• Out of scope: rvega’s laptop beyond the EDR check that cleared it; SSO-connected applications other than the CRM with no attacker sign-in, pending the sweep.
• Tenant sweep (14 days, all users, one pass): proxy-IP sign-ins, attacker-ASN sessions, session IDs seen from more than one network, same-app consents, same-shape inbox and forwarding rules, MFA registrations from either attacker IP, CRM sign-ins from attacker infrastructure. The identity-persistence sweep runs on both primary accounts.
• Regulatory: GDPR flagged; candidate awareness timestamp 09:22 on record; compliance engaged at 09:50; finance on notice at 09:52; contract and insurance notice clocks noted.
• Preservation: sign-in records, the mailbox audit for the window, the rule definition, the app’s service principal and grants, and rvega’s MFA methods and devices exported 09:22 to 09:24, before containment.
• Infrastructure gaps: the AiTM proxy’s own logs and what the kit captured are permanently out of reach (its relayed sign-ins are in the IdP log); nothing else blocking.
• Escalation posture: escalated at 09:22 on the escalation tripwire; IR owns the case. Uncover runs as scoping support, and anything that changes impact (payment-thread access, outbound mail, another exposed account) goes to the IR lead the moment it lands, not at the end of the phase.
• Open questions for Uncover: what did the session and the OAuth app actually read; did the attacker reach payment threads or the CRM; do the tenant sweeps surface other sessions, grants, rules, MFA registrations, or exposed accounts?
• Time box: full sweep results to the IR lead by 10:30 UTC; findings that change impact go at once.