Subject working example

Step 1. Start with the named user

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

• Identity verification. The account is provisioned, matches an HR record, and is in the expected finance role.
• Authentication history. Recent logins look normal until the day of the alert. Then a 09:08 login 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.

Three of the four dimensions agree. The behavior dimension does not. PowerShell on this account is the first concrete signal that the alert is more than a misfire.

Step 2. Expand to non-human identities

Subject does not stop at the named user. Every identity touched by the activity gets profiled.

• 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 session. The root of the process chain that led to the PowerShell invocation. Each Outlook session has its own token, mailbox identity, and audit trail.
• The cloud identity. dlin’s federated SSO identity for the cloud-based finance reporting platform. Has the same recent-login pattern as the on-premises account.

One named user has become five identities: the user account, the host, the machine account, the Outlook session, and the federated cloud identity. The Outlook session is assessed as part of dlin’s own primary investigation, same principal, same token chain, which leaves four distinct entities to profile. Three get full primary depth (dlin, the laptop, dlin’s federated cloud identity); the machine account gets secondary depth. Each one is a potential lateral-movement vector. Each one needs 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. All four identities authenticated normally. No impossible travel, no MFA bypass, no token replay signals.
• 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.
• Relationships. The four identities are tightly connected: same user, same device, same SSO chain. No surprising new connections to entities outside that cluster.

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. dlin’s mailbox in the relevant window shows a recent email with an unfamiliar attachment from an external sender. The sender is a candidate for the originating phishing source.
• Other recipients. The same email pattern landed in three other finance team mailboxes. Two of them opened the attachment. Two more potential compromise candidates.
• Downstream access. The cloud finance platform that dlin can access is connected to a vendor payment workflow. If the compromise extends to the cloud identity, payment systems are in scope for the next phase.

The Subject picture now consolidates: 3 primary entities (dlin, the laptop, the cloud identity) + 3 secondary entities (the machine account, two other finance users who opened the email) + 1 downstream system (the cloud finance platform feeding the vendor payment workflow), plus the external originating sender tracked as the originating threat. That is the map Scope inherits.

Step 5. Hand off to Scope

Subject ends with a structured, defended view of every identity connected to the alert. The entity inventory goes to Scope in the table format the handoff document specifies: name, type, classification, per-dimension verdict.

• High-value paths. The cloud finance platform → vendor payment workflow. Lateral movement here would have regulatory and financial impact.
• Insider risk indicators. None. The pattern looks like external phishing, not insider activity. No anti-forensic signs.

Step 1. Classify the device

Subject begins with what the asset is, not what the alert says. Subject does not have to redo Alert’s parsing, but it does have to attach the activity to a device profile.

• Hardware and OS. Corporate macOS laptop, recent build, FileVault on.
• Management posture. MDM-enrolled, JAMF profile verified, EDR (CrowdStrike) agent reporting normally, Gatekeeper enforced.
• Classification. Developer workstation. This matters because the expected behavior is different from a standard productivity laptop.
• Recent change history. No new admin agents, no recent OS reinstall, no profile drift in the last 90 days.

The device classification reframes the alert. On a finance laptop, the activity is suspicious-by-default. On a developer workstation, scripting and child-process activity are part of the role. The investigation does not stop here; the bar shifts.

Step 2. Read the user identity

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

• Authentication. SSO login at 09:14, 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. Encrypted outbound traffic from an IDE is normal (LSP backends, AI inference, 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, not the absence of one. Subject records it explicitly so Scope inherits a defensible verdict, not a shrug.

Step 3. Evaluate the application

The detection fired on a process. Subject has to assess the process’s identity as carefully as the user’s.

• Binary identity. Cursor Helper (Plugin), signed by Anysphere, notarized by Apple. Hash matches the public release.
• Installation path. /Applications/Cursor.app/Contents/Frameworks/…, the expected location for a vendor-installed Electron application.
• Runtime posture. Electron framework with sandbox disabled at runtime, which is the documented operating mode for the IDE’s plugin host. Not an attacker turning off protections; a vendor design choice.
• Behavioral baseline. The same binary has been running on this laptop and on dozens of peers on the same team for months. No prior alerts on the binary itself.

What an Empire-style attacker would look different on: the binary would either be unsigned or signed by a key that does not match the vendor; the install path would be in a user-writable directory; the behavioral baseline would show first appearance within the last few days. None of those match.

Step 4. Check access scope

Even when the user, device, and application all read legitimate, Subject has to record what the activity actually 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. Explicitly disabled, but only for the plugin helper as documented. Other Cursor processes still sandboxed.
• Paths touched. User home, /tmp, Cursor’s application support directory. No system paths, no other users’ homes, no credential stores.
• Network destinations. Cursor’s vendor endpoints plus a small number of resolved code-completion model hosts. All previously seen, all signed certs, no DNS anomalies.

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

Step 5. Decide the operational risk

The four-dimensions and access-scope checks all return clean. Operational function is the final filter: even when nothing is wrong, the value of the asset informs how much weight Subject gives to remaining ambiguity.

• Business function. Daily development of customer-facing software. Code commits multiple times per day.
• Data sensitivity. Source code, dev secrets, possibly customer-data-adjacent test fixtures. High.
• Lateral movement risk. Moderate. SSH keys to build environments. Persistent terminal sessions to CI runners.
• Persistence potential. High, because developer workstations offer persistence spots that look like normal tooling: shell profiles and dotfiles, LaunchAgents installed by dev tools, IDE extensions, package-manager hooks that execute on every build. On a machine where new tooling appears weekly, an implant in any of those 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. The 08:47 sign-in fits it. The 09:03 session presentation does not.
• 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, and the account’s activity after 09:03 is not. Subject records those as two different 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 session. One session ID, two presentations: corporate laptop at 08:47, VPS at 09:03. Still valid at the time of triage unless revoked. The session, not the password, is the compromised credential.
• The OAuth application. “Mail Backup Sync,” unverified publisher, consented at 09:09 with offline mailbox-read scopes. It holds its own refresh token, which means it keeps access even if every user session dies.
• The inbox rule. Not an identity, but a persistent artifact acting on the mailbox with the account’s authority. Profiled and recorded like one.
• 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 and revoking her sessions feels like containment, but the consented app authenticates on its own grant. It is a separate identity with separate credentials, and it survives every user-focused response action.

Step 3. Apply the four dimensions

• Authentication. Abnormal by definition: the 09:03 presentation reused a token with no authentication ceremony. MFA was satisfied once, by the human, through the attacker’s proxy.
• Authorization. Changed during the window: the consent grant added an application to the tenant with standing mailbox access. Authorization drift is itself evidence here.
• 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 went to four customer-success mailboxes. One other user clicked; her sign-in log shows no foreign session presentation yet.
• 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: 3 primary entities (rvega’s account, the hijacked session, the OAuth application) + 3 secondary entities (the second click-through user, the shared billing mailbox, the inbox rule artifact) + 1 downstream system (the CRM), plus the AiTM domain and 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.