Risk working example

About 15 min read

Example

The Risk phase applied to the three threaded cases. Uncover produced the evidence; Risk produces the priority and the recommendation.

Case A · The finance-team intrusion verdict

Previously in Uncover: the finance-team evidence pull. The whole case on one page: Case A in the case files.

Working example

Turning evidence into a defensible priority

Uncover delivered: phishing-driven intrusion, execution on two hosts, and dlin's stolen session cookie replayed into the cloud finance reporting platform from a hosting-provider address. Possible PCI and candidate GDPR exposure were flagged during Scope for compliance to determine. The escalation tripwire has been met since 09:24 UTC, so the criteria already put this case at P1; in a correctly run case this record is written under IR's clock. Risk begins at 13:05.

Step 1. Score impact

High. Execution on two hosts. An attacker-held session reached the cloud finance reporting platform, which stores EU vendor-contact records and feeds the vendor payment workflow. Whether PCI DSS is in play depends on whether the platform touches card data at all, which compliance owns; GDPR is a candidate regime, and the data protection officer (DPO) decides whether it applies. If it does, the 72-hour clock runs from awareness, meaning a reasonable degree of certainty that personal data was compromised, not final confirmation, and the candidate moments are already in the record (09:42 regulated data in reach, 11:05 replayed session found). Impact answers “if this is real, how bad”, so it is High before the vendor’s logs say what the session did.

Step 2. Score likelihood and confidence

High, at high confidence. Independent sources agree: the EDR process tree and decoded cradle, the proxy’s record of the transfer and beacon, the identity provider’s and the platform’s records of the replayed sign-in, and the message trace. The alternatives (an authorized exercise, an admin script) were tested at Alert and ruled out, and nothing found since contradicts the chain. Likelihood estimates how probable it is that the activity is malicious; confidence, recorded beside it on the shared rubric, says how well the evidence supports that estimate. Here both are High.

Step 3. Combine via the matrix

High impact × high likelihood = P1. The escalation criteria put the case there independently: criterion 1 confirmed at 09:24, criteria 2 and 3 at 11:05. The cell and the criteria agree, so Risk recommends escalating immediately. The call itself belongs to the Escalation decision, which records it; Risk’s work is the record that makes the decision defensible.

The RATM record behind the two axes

The two axes reduce from the four RATM dimensions (priority matrix). The record as written in the case:

Asset criticality: High. laptop-finance-09 is a user-class endpoint, but the compromised identity reached the cloud finance reporting platform, which stores EU vendor-contact records and feeds the vendor payment workflow: a regulated-data store in confirmed reach. Threat actor intent: Medium. Finance-role lure, a four-day-old C2 domain, session theft and replay within 90 minutes; one campaign hash match, attribution low. Attribution is unconfirmed, so per the calibration note the score stays Medium with the upgrade path recorded. Exploitation & scope: High. Execution confirmed on two hosts, session cookies stolen on both, dlin’s replayed against the platform from 198.51.100.23 at 10:41; host-to-host movement refuted. Business impact: Medium, upgrade path recorded. What the replayed session did is unknown until the vendor’s in-app logs arrive, and unknown is not low. It becomes High if those logs show vendor records or payment instructions read or changed. Accounts payable is already verifying bank-detail changes out of band.

Reduction: impact is the higher of asset criticality (High) and business impact (Medium), so the impact axis: High. Threat actor intent and exploitation & scope, read against the multi-source evidence, give the likelihood axis: High, with confidence: High recorded beside it. The Medium intent score does not drag likelihood down, because likelihood estimates whether the activity is malicious, and the confirmed exploitation answers that; intent speaks to who and why.

Your turn: write the Risk verdict block for this case (impact, likelihood and confidence, each with a rationale; the cell and priority; any override; the recommended move) before you open the next step.

Step 4. Document the verdict

The Risk verdict records:

Impact: High. Execution on two hosts; an attacker-held session on a platform holding EU vendor-contact records.
Likelihood: High. Confidence: High. Multi-source evidence; alternatives tested and ruled out.
Matrix cell: High/High. Priority: P1. Criteria confirmed: 1 (09:24), 2 and 3 (11:05). Depth: Level 2, because regulated data was plausibly accessed by the replayed session.
Credential exposure: dlin and Finance user 2 are credential-exposed until their passwords are reset, their sessions revoked, and their MFA methods reviewed.
Open questions: the replayed session’s in-app activity (vendor logs pending); whether Finance user 2’s stolen cookie has been used; mobile device activity may be unmonitored.
Detection gap: the rule missed the identical chain on laptop-finance-12, because its network leg reads only the web proxy and that laptop was off the corporate network without the VPN.
Recommended response (the Escalation decision makes the call): escalate to IR now. Preserve first: memory and EDR triage collection on both hosts, identity-provider sign-in and session exports, proxy logs held. Then the SOC’s pre-authorized, reversible actions: isolate both hosts, block sign-in and revoke all sessions and refresh tokens for both users, and ask the platform owner to end the session on the platform side. With IR approval: password resets for both users, a purge of the message from all four mailboxes, and blocks on the domain and both IP addresses. Notify compliance and legal.

Step 5. Hand off to the Escalation decision

Risk’s deliverable is a one-page record the Escalation decision can act on: impact and likelihood justified separately, confidence labeled, the cell and the confirmed criteria shown, open questions named, recommended response sketched. The Escalation decision makes the call. The receiver (the on-call IR lead, or the next tier if the case is tiered up) has everything they need to start.

Step 1 of 5

Key takeaway

Risk turned a morning of detection and investigation into a one-page record of priority and recommendation. The record is what travels to Escalation. The reasoning behind it is what defends the case six months later, including the honest note that the criteria called for this escalation at 09:24.

Case B · Scoring the Cursor IDE benign true positive

The first walkthrough produced a P1 escalation. The Cursor case from Uncover went the other way. Risk’s job there is to score a High-impact, Low-likelihood case honestly and recommend a move that makes the eventual close durable. Previously in Uncover: confirming the benign true positive. The whole case on one page: Case B in the case files.

Working example

Scoring a High-impact, Low-likelihood case

Uncover concluded that the Cursor Helper (Plugin) alert was a bundled Cursor extension doing its documented job on an EDR-monitored, MDM-managed macOS endpoint, with the extension layer inventoried and clean. Two visibility gaps (TLS metadata only to vendor endpoints, no USB device control) were named and bounded. Risk now scores the case and recommends the move.

Step 1. Score impact

High. Impact is scored on the premise that the activity is real. This device holds source code and developer secrets, and the user’s SSH keys reach the build environment and the CI runners that build the customer-facing product. Asset criticality scores the highest-value asset in confirmed reach, and that is a revenue-affecting supply-chain path, so a genuine implant here, or a malicious extension riding the IDE, would be a High-impact compromise. The benign-looking evidence does not discount this score; that belongs entirely to likelihood. Scoring impact honestly is what keeps the closure defensible: the case closes because the likelihood collapsed, not because the asset stopped mattering.

Step 2. Score likelihood and confidence

Likelihood: Low. Multiple corroborating sources point to a bundled IDE extension doing its documented job: the binary matches the MDM-recorded vendor release, the child ran vendor code from inside the signed bundle, every destination is on the vendor’s allowlist, the extension, Model Context Protocol (MCP) and workspace-task inventories are clean, the coding agent’s commands trace to the user’s own prompt, peer prevalence matches, and there is no persistence, no credential-path access, no privilege escalation. The Empire-style surface similarity is the only signal in the other direction, and it is explained: the rule correctly matched behavior that is also the IDE’s documented operating mode.

Confidence: High. Direct evidence from EDR, corroborated by independent sources (the proxy and the MDM inventory), with the alternatives tested and ruled out: a malicious or newly updated extension, an MCP server or workspace task, an agent command the user did not ask for, credential theft. The two gaps are peripheral to the verdict question (what ran and where it connected), so “unknown is not Low” does not apply to them; each gets a reopen trigger instead.

Step 3. Combine via matrix

High impact, Low likelihood: the High/Low cell, P3 on the high-impact clock, with confidence High recorded beside it. P3 does not mean close now. It means keep working to a named re-score trigger, within hours for this cell, then decide. The trigger Scope already set fits: the four-hour forward watch on the host, ending 18:03.

The methodology also requires Risk to name what could change the score.

Technical alignment. Behavior aligns with known, approved developer tooling. Activity is likely part of normal operations.
Process integrity. No tampering, no code injection, no unauthorized privilege escalation observed.
User role. Activity executed by a developer within the scope of normal job duties using approved tools.
Endpoint health. Security agents active, unmodified, reporting normally.
Reopen triggers. A helper child running code from outside the app bundle, or an extension not on the approved list; a destination outside the vendor allowlist; reads of credential paths; LaunchAgent, LaunchDaemon or login-item writes; a new MCP server config; an agent command with no matching user prompt, or one that reaches outside the workspace; the same behavior on a non-developer host; a Cursor binary with a non-Anysphere signature.
Recommended move. Keep the case open to the forward watch; if it comes back clean, a documented close. Risk recommends; the Escalation decision decides.

What a less experienced analyst could miss: that “I cannot prove a negative” is not a reason to keep the case open past its trigger. The two gaps are permanent; no additional hours of querying will fill them. This case stays open for exactly one named reason, the High/Low cell’s forward watch, and closes on its result. The defensible move is exactly what this step does: name the gaps, note that nothing corroborates them, and record what new signal would reopen the case. Holding a case open to avoid signing an uncertain close is not rigor; it is the queue quietly absorbing the analyst’s discomfort.

Step 4. Document the assessment

The risk statement for the case record

Risk statement: the observed behavior overlaps with known adversary techniques, particularly the Empire framework’s macOS agent pattern, and its realistic modern form runs inside the signed IDE: a malicious extension, a rogue MCP server, or a coding agent steered by content it reads. If it were malicious, impact would be High: the host’s SSH keys reach the build environment that produces the customer-facing product.

The evidence makes that unlikely. A bundled Cursor extension, running in the signed extension host, indexed the workspace and connected only to the vendor’s allowlisted endpoints. The extension, MCP and workspace-task inventories are clean, and the coding agent ran only what the user asked for; there is no persistence and no credential-path access; the same behavior appears across the peer population; the endpoint telemetry is complete for the question. Likelihood is assessed as Low, at High confidence.

Two visibility gaps are accepted: TLS metadata only to vendor endpoints, and no USB device control on this host class. Neither bears on what ran or where it connected.

Cell High/Low, P3. Recommended move: keep working to the named re-score trigger, the forward watch on the host ending 18:03 UTC, then a documented close if it is clean. Reopen triggers are recorded in the case.

Assessed by the Tier 1 analyst (day shift), 15:10 UTC; confidence High.

This is what a defensible benign-true-positive assessment reads like. Not “dismissed.” Structured, evidenced, signed.

Step 5. Hand off to the Escalation decision

The Escalation decision receives a scored case and a recommendation, not a verdict to rubber-stamp. The methodology still treats this as a formal handoff because Documentation will draw from it and because the record is the artifact that defends the case if the same alert fires again.

Assessment: detection true positive; activity authorized (benign true positive), pending the re-score; High impact, Low likelihood, High confidence; High/Low, P3.
Recommended move: keep working to the forward watch (ends 18:03 UTC); documented close if clean.
Open questions for the program: is TLS-metadata-only visibility to AI-tool vendor endpoints, with no USB device control, acceptable for the developer-workstation population? This is a program-level question, not an investigation-level one.
Detection-engineering feedback: rule logic unchanged; it fired on exactly what it describes. Alert enrichment requested (extension ID, child command line, destination set). Pattern-entry proposal to follow if the close holds, keyed to the Cursor build, the bundled extension ID and the destination set.

Step 1 of 5

Two shapes of Risk verdict

The two scenarios show the two main shapes Risk produces. A high-impact, high-likelihood verdict recommends immediate escalation and resource mobilization. A High-impact, Low-likelihood score lands at P3: the case stays open to a named re-score trigger, then closes with documented reasoning, because the likelihood is where the benign evidence belongs. Both are correct outputs; both deserve the same rigor in their documentation.

Case C · Scoring the token theft after the escalation tripwire

Case C arrives at Risk differently: the escalation tripwire fired at the end of Alert, at 09:22, and IR has owned the case since 09:28. The decision to escalate is already in the record as an early escalation decision. Risk still runs, in minutes, as scoping support, because the verdict record tells incident response how hard to pull, and it is the scored record the case keeps. Previously in Uncover: pulling the evidence on the hijacked session. The whole case on one page: Case C in the case files.

Working example

Scoring a live identity compromise

Uncover delivered at 10:16: adversary-in-the-middle (AiTM) session theft confirmed on rvega's account, an inbox-hiding rule and an OAuth consent made from the replayed session, about 1,800 messages read by the app and logged one by one, including billing threads, payment searches at 09:18, no outbound mail, one more user credential-exposed and reset, tenant sweeps recorded. Reversible containment has held since 09:27; the grant was removed and both passwords reset with IR's approval. Risk scores the case.

Step 1. Score impact

High. Customer personal data has already been read at volume (the app’s reads are logged message by message: a completed data access, not a hypothetical), the mailbox feeds live payment conversations that make wire fraud the natural next move, and a GDPR assessment is open with compliance. Impact does not wait on whether the attacker gets further; the collection that already happened carries the score.

What a less experienced analyst could miss: the pull of “no wire went out, we caught it in time” toward a downgraded score. Interrupting the fraud is a containment win, not an impact discount: roughly 1,800 messages of customer data were read by an attacker-controlled app, a completed unauthorized access. Whether that is a notifiable GDPR breach is compliance’s determination, made against the awareness timestamp already on record, and the answer does not depend on whether the attacker ever got to spend the data.

Step 2. Score likelihood and confidence

High. The 08:53 sign-in through a hosting IP a minute after the click, the 09:03 replay of the session it produced with no authentication ceremony, and the tenant audit records carrying that session from the same VPS IP leave no benign explanation standing, and none survived Uncover. Confidence is recorded beside it on the shared rubric: high, because the evidence is direct, corroborated by independent sources (the identity provider (IdP) log, the tenant audit, the gateway record, rvega’s own account), and the alternatives are ruled out. The kit-family identification stays at medium.

Step 3. Combine via the matrix

High impact × high likelihood: the cell is High × High, P1, and the recommended move is escalate. That matches the decision recorded at 09:22, when the escalation tripwire fired; Risk does not reopen it. The value Risk adds here is the record of the response order, because identity containment has a sequencing trap.

Why the response ordering matters more than the score

Don’t count on a password reset for containment: whether it ends existing sessions depends on the IdP and how the reset is done, and it never removes the consent grant. Explicit revocation is the version you can verify. The record shows the order the case actually ran, preservation first:

Preserve the sign-in records, the mailbox audit, the rule definition, the app’s service principal and grants, and a snapshot of rvega’s MFA methods and devices (09:22-09:24).

Disable the account and revoke all sessions and refresh tokens (09:24-09:25). Already-issued access tokens can stay valid for an hour or more (a random 60 to 90 minutes by default on Microsoft Entra ID) where continuous access evaluation is not enforced, so the check is that the attacker’s session stops presenting: it was refused at 09:31.

Disable the app’s sign-in for “Mail Backup Sync” (09:26): a separate action in a separate admin surface, reversible, with the grant left in place as evidence.

Disable the inbox rule (09:27), already exported.

With IR’s approval, remove the app’s delegated grant and app-role assignments while keeping its service principal disabled, so the application ID stays blocked (09:38), then reset rvega’s password, because the kit relayed it, and review her MFA methods (09:40).

Steps 1 to 4 are on the pre-authorized list because each can be undone. Step 5 cannot, so it waited for IR. The MFA review in step 5 is one item of the identity-persistence sweep, which covers every anchor an attacker may have left on the account. The instinctive order, a password reset first and everyone relaxing because “the password was changed,” leaves the consent grant in place and the session unverified.

Step 4. Document the verdict

Verdict: true positive on the detection; malicious on the activity.
Impact: High. Customer data read message by message by an attacker-controlled app; payment-fraud staging interrupted before any outbound message.
Likelihood: High. Confidence: High (independent sources, no surviving benign hypothesis); kit-family identification medium.
Cell and priority: High × High, P1. Also P1 by criterion since 09:22. Two persistence paths, the session and the consent grant, both cut and verified.
Recommended move: escalate, already recorded at 09:22.
Open questions: GDPR determination owned by compliance (candidate awareness timestamp 09:22 on record); whether the relayed passwords are reused on other services; whether the lure reached other estates; the AiTM proxy’s own capture scope lies outside any log the SOC holds.
Recommended next steps for IR: keep the app blocked by application ID tenant-wide (its sign-in disabled so no new tokens issue), restrict user consent to verified publishers or route it through admin-consent review, hunt rules for the proxy IP, the VPS ASN , and the lure domain, and phishing-resistant MFA with token protection for customer-facing roles.

Step 5. Hand off to the Escalation decision

Same one-page shape as the finance case, with one addition: the verdict names why the timing mattered. Every minute before session revocation was a minute of live mailbox access, and the case cut it at 09:25, ten minutes after the alert, instead of an hour later. The Escalation decision record carries the P1 beside the 09:22 decision, with the ordered containment list and its verification times.

Step 1 of 5

Key takeaway

The token-theft verdict took minutes and came after the escalation, and that is the point: when the escalation tripwire has already fired, Risk does not reopen the decision. It scores the case for the record, confirms the cell agrees with the escalation tripwire, and documents the preserved, ordered, verified identity containment that keeps the response from being theater.

Next up

Transition to the Escalation decision

The handoff contract: what Risk passes to Escalation decision, and how to know the case is ready.

Read the handoff

Technical details verified 2026-10-13. Product names, defaults and retention change; check your own tenant.

Edit this page on GitHub Report a correction