Subject working example

Step 1. Start with the named user

The alert names dlin. The Subject phase begins by profiling that user explicitly:

• Authentication. The account is provisioned, matches an HR record, and is in the expected finance role. Recent sign-ins look normal: a 09:08 UTC interactive login with MFA from the usual workstation, followed by the alert at 09:11.
• Authorization. dlin has read access to finance reporting systems and the standard productivity stack. No administrative privileges.
• Behavior. Activity profile is consistent with a finance analyst role. PowerShell is not part of dlin’s normal pattern.
• Relationships. Two contacts are new: an external sender dlin has never corresponded with, and her laptop’s first-ever connection to a four-day-old domain. Step 4 follows both out.

Two of the four dimensions agree with a normal day. Behavior and relationships do not, and they point the same way: the alert is more than a misfire.

Step 2. Expand to non-human identities

Every identity the activity touched gets profiled, not just the named user.

• The host. laptop-finance-09 is a managed corporate device, enrolled in the EDR, with a baseline of activity matching dlin’s role.
• The machine account. laptop-finance-09 is domain-joined, so it has its own computer account that authenticates to domain services independently of dlin. Anything running as SYSTEM on the host speaks as that account, so its recent activity becomes part of the picture.
• The Outlook and browser sessions. Where the chain began: dlin opened the link from Outlook, and Chrome loaded the page that, on the working hypothesis, supplied the command. Each has its own token, identity, and audit trail.
• The cloud identity. dlin’s federated SSO identity for the cloud finance reporting platform. Primary even though the alert never named it: it is the same principal, and a stage running as dlin can reach her browser’s session state.

One named user has become five identities. The Outlook and browser sessions are assessed within dlin’s own primary investigation (same principal, same token chain), which leaves four entities: three get full primary depth from the start (dlin, the laptop, dlin’s federated cloud identity), and the machine account gets secondary depth. Each is a potential lateral-movement vector with its own assessment.

Step 3. Apply the four dimensions

The four dimensions are now applied to every identity in the list, not just dlin.

• Authentication. No impossible travel and no MFA bypass. dlin’s federated identity has signed in from nowhere but the laptop since 09:08 (checked at 09:33). That last result is clean so far, not clean: the stage has been running as dlin for twenty minutes, and anything running as the user can read the browser’s session state, so the cloud identity’s tokens are presumed exposed until Uncover tests it.
• Authorization. No identity exceeded its assigned permissions during the relevant window. Authorization checks pass.
• Behavior. dlin’s user account behaved abnormally (PowerShell). The host’s process baseline shows no prior PowerShell use under this user. The machine account and cloud identity show no unusual activity so far.
• Relationships. Inside the cluster, the four identities are tightly connected: same user, same device, same SSO chain. Outside it, two connections are new: the external sender and invoice-records[.]example. Both become the originating threat.

What a less experienced analyst could miss: applying the dimensions only to the named user. The machine account and cloud identity are easy to overlook because the alert did not name them, but they share trust paths and could expose lateral movement if compromised.

Step 4. Check relationships

The relationship dimension expands beyond the four identities into the systems and people they touch.

• Communication graph. The message trace (pulled at 09:26) shows the email that started it: an invoice-themed message from accounts@invoice-records[.]example, delivered at 09:02:11, with no attachment and one link to a page on invoice-records[.]example, the domain the stage pulled from. The URL had no reputation at delivery, so the gateway let it through. The sender is a candidate for the originating phishing source.
• Other recipients. The same message was delivered to three other finance-team mailboxes. Whether anyone else opened it is not known yet: the trace shows delivery, and opening is an endpoint question for Uncover. Three more potential compromise candidates, and the message is still sitting in their inboxes. Removing it is an IR-approved action, one more reason the tripwire page matters.
• Downstream access. The cloud finance reporting platform that dlin can access feeds the vendor payment workflow and stores vendor-contact records. If the compromise extends to the cloud identity, that platform and its data are in scope for the next phase.

The Subject picture now consolidates: 3 primary entities (dlin, the laptop, the cloud identity) + 4 secondary entities (the machine account and the three other finance recipients) + 1 downstream system (the cloud finance reporting platform), plus the originating threat (the external sender and invoice-records[.]example). That is the map Scope inherits.

Step 5. Hand off to Scope

The entity inventory goes to Scope in the table format the handoff specifies: name, type, classification, per-dimension verdict.

High-value path: the cloud finance reporting platform → vendor payment workflow and vendor-contact records. Lateral movement here would have regulatory and financial impact.

Step 1. Classify the device

Subject begins with what the asset is, not what the alert says.

• Hardware and management. Corporate macOS laptop, FileVault on, MDM-enrolled (Jamf), configuration profile verified, EDR (CrowdStrike) agent reporting normally, Gatekeeper enforced.
• Classification. Developer workstation, where expected behavior differs from a standard productivity laptop.
• Recent change history. No new admin agents, no recent OS reinstall, no profile drift in the last 90 days.

On a finance laptop this activity is suspicious by default; on a developer workstation, scripting and child processes are part of the role. The investigation does not stop here, but the bar shifts.

Step 2. Read the user identity

The four dimensions on the named user, focused on what the role allows.

• Authentication. SSO login at 09:14 UTC, expected location, expected device, FIDO2 second factor. No anomalies.
• Authorization. Frontend engineer, developer group, no admin rights, no production access. Some elevated capabilities granted to specific applications via macOS TCC, all approved.
• Behavior. Spawning helper processes from IDEs is part of this user’s daily pattern, and the user runs the IDE’s coding agent most days. Encrypted outbound traffic from an IDE is normal (extension marketplace and updates, AI features through the vendor’s backend, telemetry, package installs).
• Relationships. Normal communication graph for the team. No new SSO links, no unexpected resource access this week.

All four dimensions agree on legitimate. That is a real signal, and Subject records it explicitly so Scope inherits a defensible verdict, not a shrug.

Step 3. Evaluate the application

The detection fired on a process, so the process’s identity gets the same care as the user’s.

• Binary identity. Cursor Helper (Plugin), signed with Anysphere’s Developer ID, notarized by Apple. The MDM inventory reports the installed Cursor version and its hash, and both match the vendor’s release; EDR reports the bundle signature valid.
• Installation path. /Applications/Cursor.app/Contents/Frameworks/…, where the MDM installed it. /Applications is admin-writable, so the path counts only together with the MDM record of what was installed there.
• Runtime posture. Electron extension host running without the Chromium sandbox, which is how VS Code-family editors run extension code. Not an attacker turning off protections; a vendor design choice. The design choice is also the exposure: whatever extension code runs here runs with the user’s rights.
• Behavioral baseline. The same signed application (Anysphere Developer ID), at the build the MDM deployed to the team’s managed Macs, has run on this laptop for months. No prior alerts on it from this host. How many peers show the same child-process behavior is a question for Uncover.
• Extension layer. The IDE runs code that the binary signature does not cover: user-installed extensions, MCP servers the IDE is configured to start, workspace tasks, and the commands its coding agent runs on the user’s behalf. Subject records this as an open question for Uncover, not as cleared. Binary identity says nothing about extension code.

How abuse inside the signed IDE would differ: the binary would look identical, so the discriminators move to the extension layer: an extension or update new to this host, a publisher no peer uses, an MCP server config that changed, an agent command no user prompt asked for, a child running a script from outside the app bundle, outbound destinations outside the vendor’s allowlist, or reads of ~/.ssh, ~/.aws, the keychain or wallet files. A dropped Empire-style binary would differ more simply: unsigned or wrongly signed, in a user-writable path, first seen in the last few days. None of the binary-level tells match; the extension- and agent-level tells are still unchecked.

Step 4. Check access scope

Even when everything reads legitimate, Subject records what the activity had access to. Scope inherits this directly.

• Privilege level. Standard user context, no sudo or root elevation, no privilege escalation events in the timeline.
• Sandbox status. Disabled for the extension-host helper and the processes it launches, as documented. Renderer and GPU helpers remain sandboxed; the main process, like every Electron app’s main process, runs unsandboxed by design.
• Paths touched. The workspace, /tmp, Cursor’s application support directory, per EDR for the alert’s event window. No system paths, no other users’ homes, no reads of credential paths (~/.ssh, ~/.aws, the keychain). Uncover confirms across the full window.
• Network destinations. Cursor-owned endpoints on the vendor’s published allowlist (*.cursor.sh, *.cursorapi.com). All previously seen from this host, all with valid certificates matching the requested names. No direct connections to third-party model providers.

Access-scope verdict: bounded to the user’s own profile and expected vendor infrastructure, which bounds Scope’s environmental footprint to roughly the same surface.

Step 5. Decide the operational risk

Operational function is the final filter: even when nothing is wrong, the value of the asset sets how much weight the remaining ambiguity gets.

• Business function. Daily development of customer-facing software.
• Data sensitivity. Source code and developer secrets. Subject cannot rule out that test fixtures in the indexed repositories hold customer-derived data; Scope’s regulatory check settles it. High.
• Lateral movement risk. High if real. The user’s SSH keys reach the build environment and the CI runners that build the customer-facing product, a revenue-affecting supply-chain path.
• Persistence potential. High. Developer workstations offer persistence spots that look like normal tooling (shell profiles and dotfiles, LaunchAgents installed by dev tools, IDE extensions and MCP server configs, package-manager hooks that execute on every build), and where new tooling appears weekly, an implant blends in.

Step 1. Profile the named user

• Identity verification. rvega is a provisioned account matching an HR record, customer-success lead, employed four years.
• Authentication history. Stable 90-day baseline: two devices, one city, one ASN, MFA on every new session, read from the SIEM copy. The 08:47 laptop sign-in fits it. The 08:53 sign-in from a hosting IP, a minute after the lure click, does not, and neither does the 09:03 replay of the session it produced.
• Authorization. No admin roles. Mailbox, CRM access via SSO group, and delegate rights on the shared billing mailbox.
• Behavior. rvega has never created an inbox rule by API, never consented an OAuth application. Both happened inside twenty minutes.

The user profile splits in two: the human’s own activity is clean, including the 08:53 sign-in she made in good faith through the proxy, and the account’s activity from the 09:03 replay onward is not. That is two actors sharing one account, which is exactly what a hijacked session is.

Step 2. Profile the non-human subjects

With no host to classify, the entity expansion runs across identity objects instead:

• The sessions. Two, not one. S1, from the 08:47 laptop sign-in, is rvega’s own. S2 was issued at 08:53 through the proxy and replayed from the VPS at 09:03; it was revoked at 09:25 and refused when it presented again at 09:31. The session cookie is the credential that bypassed MFA. The proxy captured the typed password too, so both are compromised: revoking the session contains the attacker, and resetting the password stops them signing in again.
• The OAuth application. “Mail Backup Sync,” unverified publisher, consented at 09:09 from the replayed session with Mail.Read and offline_access. It holds its own refresh token, bound to rvega and the app. A password change does not reliably revoke it; an admin revocation of all her refresh tokens does, but issued access tokens stay valid until they expire and the consent grant stays until someone removes it. Its sign-in was disabled at 09:26; removing the grant cannot be undone, so it waited for IR’s approval and happened at 09:38.
• The inbox rule. Not an identity, but a persistent artifact acting on the mailbox with the account’s authority. Profiled and recorded like one. Exported at 09:23 and disabled at 09:27.
• rvega’s laptop. Checked and explicitly cleared: EDR shows the 08:52 link click opened a browser page, nothing was downloaded or executed. The device is a witness, not a subject.

What a less experienced analyst could miss: the OAuth application. Resetting rvega’s password feels like containment, but the consented app authenticates on its own grant. Revoking her refresh tokens cuts the tokens it already holds; the grant itself survives every user-focused action until someone removes it, ready for the next token the app obtains. It is a separate identity with separate credentials, and it gets its own containment line.

Step 3. Apply the four dimensions

• Authentication. Abnormal twice over: the 08:53 sign-in came through the attacker’s proxy from a hosting IP she has never used, and the 09:03 presentation reused that sign-in’s token with no ceremony at all. MFA was satisfied once, by the human, through the attacker’s proxy. Push approval is not phishing-resistant, and Conditional Access asked for no compliant device or token protection; both are recorded as control gaps.
• Authorization. Changed during the window: the consent grant added an application to the tenant with standing mailbox access. Authorization drift is itself evidence here. The tenant lets users consent to unverified publishers, a third control gap.
• Behavior. The post-09:03 actions (rule creation by API, consent grant, mailbox search patterns) match no prior behavior on this account.
• Relationships. The account’s delegate rights on the shared billing mailbox mean the compromise reaches a mailbox rvega does not own. The new app is a new relationship between the tenant and an external publisher.

Step 4. Expand across the tenant

• Other recipients. The email gateway shows the same “shared document” lure delivered at 08:41 to four customer-success mailboxes. One other user clicked, at 08:54. Her sign-in log shows a sign-in from the proxy IP at 08:54:49 that passed the password check and stopped at MFA, with no token issued. That rules out session theft, not credential theft: anyone who reached the credential step of a phishing kit is credential-exposed until the password is reset, sessions are revoked, and MFA methods are reviewed. Subject reports her to IR at 09:39; her sessions are revoked at 09:41, and with IR’s approval her password is reset and her MFA methods reviewed at 09:44.
• Shared resources. The billing mailbox rvega can act on becomes a secondary entity: nothing has touched it abnormally yet, but the path exists.
• Downstream systems. The CRM is reachable through the same SSO identity. No CRM session from the attacker ASN so far; recorded as an open question, not an assumption.

The map consolidates: 4 primary entities (rvega’s account, the replayed session, the OAuth application, the second user’s credential-exposed account) + 2 secondary entities (the shared billing mailbox, and rvega’s laptop, examined and cleared) + 1 artifact attached to rvega’s account (the inbox rule) + 1 downstream system (the CRM), plus the lure domain, the proxy IP, and the VPS IP tracked as the originating threat.

Step 5. Hand off to Scope

• High-value paths. The billing mailbox and any payment-redirect conversation in it; the CRM through the shared SSO identity.
• Insider posture. None. The human is a victim; the account is the vehicle. Recording that distinction protects the person and keeps the investigation aimed at the attacker.

Step 1. Take the referral, not the story

The case record opens with four facts about the referral and nothing more:

• Reference: IRP-2026-0412.
• Owner: the insider-program lead, who holds whatever HR context exists.
• Window: from the notice date, 2026-09-28, to now.
• Technical questions: the three above, copied verbatim.

Case access is restricted to the two named analysts and the insider-program lead; the case does not sit in the shared queue.

What a less experienced analyst could miss: the urge to ask HR “why”. The reason for the referral, and anything about the person’s circumstances, stays with HR and the insider-program lead. The SOC’s job is to answer the technical questions with observable activity, and the record is defensible precisely because it holds nothing else.

Step 2. Check with legal before widening

The three questions can be answered from logs the company already collects: the source-control audit log, the cloud access security broker (CASB) and proxy logs, and the EDR timeline for jkessler’s laptop (laptop-eng-14). Before pulling anything, the analyst confirms the envelope with legal through the insider-program lead:

• Approved now: review of those existing logs for the referral window, and file-hash comparison between EDR and CASB records.
• Not approved without a further request: opening the contents of any file, reading jkessler’s mail or chat, or collecting anything from outside the window.
• Preservation: legal places the source-control audit log, the CASB and proxy logs, and the EDR telemetry for laptop-eng-14 under legal hold, and the analyst starts a chain-of-custody record for every export.

The questions need nothing beyond the approved set, so nothing further is requested.

Step 3. Apply the four dimensions

• Authentication. Normal: every session in the window is from laptop-eng-14, with MFA, from the usual network. Nothing borrowed, nothing shared.
• Authorization. One finding. jkessler can still read two repositories (payments-core and fraud-models) from a role on another team that ended in June. The access was never revoked.
• Behavior. On 2026-10-06 between 21:58 and 22:31 UTC the account cloned 14 repositories, including both of the left-over ones. Its own 90-day baseline is one to three clones a week. The aggregate baseline for the platform team (no named colleagues examined) puts the 95th percentile at six clones a week. At 22:44 EDR records an archive tool reading the 14 clone directories and writing a 2.3 GB zip file.
• Relationships. From 22:47 to 22:52 UTC the browser on laptop-eng-14 uploads a 2.3 GB file to personal-drive[.]example, a consumer cloud-storage service the device has never contacted before. The CASB logged the upload but did not block it: personal storage was a log-only category. The file hash in the CASB record matches the zip EDR saw written at 22:44.

All three referral questions now have answers, and every answer is a logged event with a timestamp.

Step 4. Correlate and write it down

The two streams meet on one point only: the activity falls inside the window the referral supplied. That correlation sharpens the label; it does not decide the response. The ticket records the technical stream in factual terms:

• Survives review: “On 2026-10-06 between 21:58 and 22:31 UTC, account jkessler cloned 14 source repositories, two of them outside the account’s current team. At 22:44 UTC an archive of those clone directories was written on laptop-eng-14; between 22:47 and 22:52 UTC a file with the same hash (2.3 GB) was uploaded to personal-drive[.]example.”
• Does not belong in any ticket: “Disgruntled engineer stealing code before leaving for a competitor.” It states intent nobody has established and repeats context the SOC should never have held.

Confidence is High on the shared confidence rubric: two independent sources (EDR and CASB) agree, the hashes match, and the leading benign alternative (an approved transfer) is ruled out, because no ticket or approval covers moving source code to personal storage. Company source code has left the company’s control. That is the exfiltration criterion, confirmed.

Step 5. Respond on act, asset and impact

A confirmed criterion trips the escalation tripwire whatever the label: the case is P1. The escalation goes through the insider route, with the IR lead, the insider-program lead and legal on one bridge, because the person is an employee and the case may end in litigation.

• Preserve first: the legal hold from Step 2 already covers the logs; the EDR timeline and CASB records are exported under the chain-of-custody record before anything changes on the device.
• Contain what is still live: uploads from laptop-eng-14 to personal cloud storage move from log-only to block. It is reversible and stops further loss without touching the account.
• Time the rest with legal: the upload has completed, so suspending the account or removing access now would recall nothing and would warn the subject. Removing the two left-over repository grants, the conversation with jkessler, and any request to the storage provider are timed by the insider-program lead and legal.
• Label: recorded as “deliberate transfer of company source code to personal storage; intent not established”. Whether this is insider risk or insider threat is the insider-program lead’s call, made in parallel; the response above did not wait for it.

The Subject handoff’s insider posture reads: referral IRP-2026-0412, owned by the insider-program lead; all three technical questions answered yes, with the evidence above. Nothing about the person beyond the account’s activity.