Alert working example

Step 1. Read the detection

Before anything else, the analyst reads what fired and why. The rule’s logic chains three behavioral signals: an Office process spawning a shell (Outlook → winword.exe → cmd.exe → PowerShell), -EncodedCommand with -NoProfile (a near-universal indicator of automated execution), and outbound traffic to a low-reputation domain within 30 seconds. The rule is a behavioral-analytics rule, not a signature. False-positive rate is documented as roughly 1 in 200 fires; the rule has high precision when the chain is complete.

Three signals in a single chain is far more weight than any one of them would carry alone. The analyst starts from a strong prior before even opening the alert payload.

One modernization note: since Microsoft began blocking internet-sourced macros by default in 2022, this classic chain requires the user to unblock the document or the file to arrive without the Mark of the Web (via an ISO or ZIP container, for example). Much commodity initial access has shifted to LNK smuggling and fake-update lures; the macro chain still appears, it is just no longer the default path.

Step 2. Validate the signal

The four-dimensional validation:

• Technical. The parent-child chain matches a textbook initial-access pattern used by PowerShell Empire PowerShell Empire An open-source post-exploitation framework that uses PowerShell agents on Windows and Python agents on Linux. Empire was widely used by red teams and continues to influence threat-actor tradecraft. Many real-world intrusions still show Empire-style command-line and network patterns. and similar PowerShell-based agents.
• Environmental. Finance analysts on this laptop class do not normally invoke PowerShell. The host’s 30-day baseline confirms it.
• Intelligence. The destination domain is registered four days ago, hosted on a bulletproof provider, low prevalence, and resolves to an IP block previously seen in commodity-phishing reporting.
• Business. dlin has read access to the cloud finance reporting platform via federated SSO. The laptop is the trust pivot for a regulated-data system.

All four context dimensions agree the signal is worth a deeper investigation. None of them is decisive on its own; the combination is.

Step 3. Parse the metadata

Structured extraction from the alert payload:

• Command line. powershell.exe -NoP -W Hidden -EncodedCommand <base64>. The base64 decodes to a small downloader that reaches the suspicious domain.
• Process tree. outlook.exe (PID 5212) → winword.exe (PID 7420) → cmd.exe (PID 8104) → powershell.exe (PID 8128). The winword.exe start time aligns with an attachment-open event in the mailbox audit log.
• Network. 09:11:43 UTC outbound HTTPS to invoice-records[.]com/upd. Self-signed TLS cert. Approximately 18 KB transferred.
• File system. %TEMP%\upd.ps1 written at 09:11:44 UTC. SHA-256 captured.
• 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 delivered a phishing email containing a macro-bearing document; dlin opened the attachment; the macro launched the cmd → PowerShell chain; the resulting agent established outbound C2 to a recently-registered staging domain. The case looks like a textbook Empire-style initial access.

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

Subject inherits a structured starting point:

• Named entities. dlin (user), laptop-finance-09 (host), invoice-records[.]com (external domain), the originating sender (TBD via mail log pull).
• Open questions. Who else got the email? Did anyone else execute the macro? What did the federated cloud session do, if anything?
• Confidence. High on the parent-child chain (complete telemetry, corroborated across process tree, mailbox audit, file system, and network); low on attribution (no actor signature, only TTP-level match to commodity Empire-style tooling). Labels per the shared rubric.

Step 1. Read the detection

The rule that fired is a cross-platform behavioral-analytics rule looking for “process disables its sandbox, spawns helper, opens encrypted outbound socket.” The rule was originally written from an engagement against an EmPyre agent (the Python 2.6/2.7 macOS/Linux sister agent to PowerShell Empire, merged into the framework in Empire 2.0 (released 2017), both names refer to the same lineage) and was later ported to macOS. Documented benign-fire rate on macOS developer hosts — in this rule’s history mostly benign true positives, developer tools doing exactly what the rule describes: ~6× higher than on managed productivity laptops. That is a known calibration issue, captured in the rule’s metadata.

The rule’s confidence on this host class is therefore lower from the start. The analyst notes that explicitly before opening the payload.

Step 2. Validate the signal

The four-dimensional validation reads differently from Case A:

• Technical. The pattern (disabled sandbox, encrypted outbound from a helper process) does overlap with Empire’s macOS agent behavior at the surface level. But the binary itself is signed and notarized by the vendor, and the install path is a system-managed application directory, not a user-writable staging area.
• Environmental. The host is a managed developer workstation. Helper-process activity from IDEs is part of the daily baseline. The user’s peers show the same pattern on the same vendor binary.
• Intelligence. No prior incidents involving this binary or vendor. The TLS destination resolves to the vendor’s documented inference infrastructure with a valid cert.
• Business. Source code exposure exists, but the binary’s runtime behavior is consistent with the vendor’s documented operating mode.

Three of the four context dimensions point away from compromise. The technical dimension has a surface match but is contradicted by deeper context. The methodology calls for continuing the investigation, not closing the alert; the hypothesis is now “likely benign true positive — the rule read the behavior correctly, and the behavior looks like the IDE’s documented operating mode; confirm via Subject and Uncover.”

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 here is the combination: signature plus system-managed install path plus peer-group baseline plus vendor-documented behavior. Any one of those alone is a weaker claim than it feels.

Step 3. Parse the metadata

• Command line. /Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app/Contents/MacOS/Cursor Helper (Plugin) —type=utility …. Vendor-standard.
• Process tree. launchd → Cursor; the main Cursor process spawns Cursor Helper and Cursor Helper (Plugin) as direct children (Electron helpers are children of the main app, never of each other). launchd is Apple’s platform-signed init process; the three Cursor binaries are signed by Anysphere (Developer ID) and notarized by Apple.
• Network. Multiple TLS connections to *.cursor.sh and to a small set of LLM-inference hosts, all with valid certificates, all resolving via standard public DNS.
• File system. Reads in the user’s home and the Cursor application support directory. No writes outside expected paths.
• Identity. Active session: a frontend engineer. SSO login at 09:14 with FIDO2 second factor.

Step 4. Frame the hypothesis

Working hypothesis: the detection logic correctly recognized a process-behavior pattern that overlaps with Empire-style macOS post-exploitation tradecraft. The binary, signature chain, install path, and behavioral baseline all suggest this is the documented operating mode of a vendor-supplied IDE plugin host, not adversary tooling. 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 different starting point from Case A, narrower, but with explicit caveats:

• Named entities. The frontend engineer (user), the macOS laptop (host), Cursor Helper (Plugin) (binary), the vendor’s inference endpoints (external).
• Open questions. Does the binary’s behavior match peer-group baselines? Are there detection-tuning opportunities for this host class?
• Confidence. High on the binary identity and signature chain (signed, notarized, corroborated by vendor documentation); medium on runtime posture (sandbox-disabled behavior is intrinsically harder to baseline).

Step 1. Read the detection

The rule is a two-signal correlation: an IdP risk event (session token presented from a new autonomous system with a mismatched browser fingerprint) 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.

The join key is worth noticing before the payload is even open. Nothing here shares a host or a PID. The two events are joined on the account and the session, which is exactly how the cloud and identity parsing page says this class of alert must be read.

Step 2. Validate the signal

The four-dimensional validation:

• Technical. The 09:03 sign-in 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. prompt. A legitimate new device would have triggered both. Token reuse without an authentication ceremony is the signature of session hijack Session Hijack Taking over an active session by stealing or guessing session tokens or cookies, bypassing authentication. via a stolen cookie.
• Environmental. rvega’s 90-day sign-in baseline is two devices, one city, one ASN. The 09:03 presentation is a first for the ASN, the geography, and the fingerprint. The 08:47 sign-in that preceded it was normal in every dimension.
• Intelligence. The source IP belongs to a VPS provider whose ranges appear in current reporting on adversary-in-the-middle (AiTM) phishing kits, which proxy the real login page and capture the session cookie after MFA succeeds.
• Business. rvega’s mailbox holds customer contract and billing threads. Historically this is the staging ground for payment-redirect fraud, and the mailbox contents are customer personal data with regulatory weight.

All four dimensions 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:

• Sign-in chain. 08:47:19 UTC, corporate laptop, MFA satisfied, home ASN. 08:52:41 UTC, click on a “shared document” link recorded by the email gateway. 09:03:12 UTC, the same session ID presented from the VPS ASN, new fingerprint, no MFA event.
• Session. One session ID spans both presentations. That single field is what makes this one story instead of two logins.
• Tenant audit. 09:06:55 UTC, new inbox rule named . (a single dot): messages containing “invoice”, “payment”, or “bank” moved to a subscriptions folder and marked read.
• Consent grant. 09:09:30 UTC, OAuth consent to an unverified application named “Mail Backup Sync” with offline mailbox-read scopes.
• Identity. rvega, customer-success lead. No admin roles. Access to the CRM and the shared billing mailbox via group membership.

What a less experienced analyst could miss: the session ID field. Read as two sign-ins, 08:47 and 09:03 look like a normal morning plus a VPN; read as one session presented twice with no second authentication ceremony, they are a theft. The single join field 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 captured her session cookie after a legitimate MFA approval; the attacker replayed the session from a VPS, created an inbox-hiding rule to conceal payment-themed mail, and consented 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, this is a hypothesis with named evidence, not a declared incident. The difference is the evidence type: every artifact is an identity or tenant event, and confidence rests on the session join, not on a process chain.

Step 5. Hand to Subject

Subject inherits an identity-shaped starting point:

• Named entities. rvega (user), the hijacked session ID, the VPS source IP, the inbox rule named ., the “Mail Backup Sync” OAuth application, and the phishing link’s domain from the 08:52 gateway record.
• Open questions. Who else received the same link? Did anyone else’s session present from that ASN? What has the consented app already read? Is the attacker session still alive right now?
• Confidence. High on session theft (single session ID across both presentations, corroborated by the fingerprint mismatch and missing MFA ceremony); medium on the AiTM delivery mechanism (inferred from the link click timing, pending the gateway’s URL verdict); labels per the shared rubric.