The moment you realize it isn’t “one email”

A phishing ticket lands in the queue.

One user reported it. One mailbox. One click (maybe). One attachment (maybe).

At first, it looks small.

Then you remember the rule that keeps being true in real environments:

If one user reported it, several users received it.
And if the phish is part of a kit, multiple variants likely exist.

So the work isn’t “analyze this one email.” The work is: expand scope fast without turning the SOC into a fire drill.

This post is my workflow for going from one phish to a fleet-wide hunt—safely.

The goal (what “safe scope expansion” actually means)

Safe scope expansion means:

  • you find other victims (sibling emails, clicked users, infected endpoints)
  • you avoid breaking business (bad blocks and rushed changes)
  • you preserve evidence (for IR and post-mortems)
  • you keep the hunt structured so it doesn’t sprawl

The fastest way to fail is to jump straight to global blocks off a single sample.

The second fastest is to hunt everything everywhere with no pivots.

Step 1: Classify the phish in 90 seconds

Before hunting, you need to know what you’re dealing with. I classify it into one of these:

A) Link lure (credential theft / token theft)

  • URL leads to login prompt or fake doc viewer
  • often ends in session theft or mailbox compromise
  • endpoint infection may not occur

B) Attachment lure (payload delivery)

  • macro doc, ISO/LNK, PDF with embedded links, HTML smuggle, ZIP chain
  • higher chance of endpoint execution chain

C) Conversation hijack / supplier fraud

  • legitimate thread compromised
  • highest business impact; fewer IOCs; more identity response work

This classification tells you where to spend your first 30 minutes:

  • email layer, identity layer, or endpoint layer.

Step 2: Freeze the “source of truth” artifacts

Before anything gets cleaned up, I capture the pieces I’ll need later.

Email artifacts (minimum)

  • sender address + display name
  • reply-to (often different)
  • subject and timestamp
  • Message-ID and return-path
  • URLs (decoded, de-obfuscated)
  • attachment hashes (if any)
  • any brand impersonation themes and lures used

This becomes the anchor for all pivots. No anchor = messy hunt.

Step 3: Find sibling messages (the “blast radius”)

Now I search for:

  • same sender
  • same subject pattern
  • same URL domains
  • same attachment hashes
  • similar body content (kit reuse)

The point is to build a list:

  • who received it
  • who interacted with it
  • which mailboxes were targeted

The “do not panic” rule

At this stage, you do not assume everyone is compromised. You assume everyone is exposed.

Exposure is what you track.

Step 4: Identify interaction (clicked, opened, executed)

This is where scope turns from “distribution” to “impact.”

I look for:

  • click events (proxy/secure email gateway logs)
  • attachment downloads
  • detonation outcomes (if your stack supports it)
  • login attempts to suspicious domains
  • MFA prompts / risky sign-ins soon after click

This yields your first three lists: 1) Recipients 2) Interactors 3) Likely impacted

Keep them separate. It prevents overreaction.

Step 5: Contain in layers (so you don’t break the org)

Containment is not binary. You can stage it.

Layer 1: User-level actions (fast and low-risk)

  • remove email from inboxes (if your tooling allows)
  • reset password / revoke sessions for clicked users (if credential phish likely)
  • alert users and managers if impact is suspected

Layer 2: Mail controls (medium risk)

  • block sender domain / specific sender
  • block attachment hashes
  • add URL detonation or rewrite policies

Layer 3: Network blocks (highest risk)

This is where people break business by blocking a CDN or a shared platform too early.

My rule:

  • I only implement network blocks when I have:
    • high-confidence malicious domain, AND
    • clear business impact justification, AND
    • scope evidence suggesting active harm

When in doubt: isolate endpoints and revoke sessions first.

Step 6: Expand to endpoint hunting (only if needed)

If this is link-only credential theft, endpoint hunting may be minimal. But if you see attachment execution, you go hunting.

My first endpoint pivots:

  • execution from Downloads/Temp
  • suspicious LOLBins:
    • powershell -enc
    • rundll32 from user profile
    • mshta, wscript, regsvr32
  • persistence creation:
    • scheduled tasks
    • Run keys
    • services
  • first-seen domains contacted shortly after execution

The “hinge window” trick

I always hunt within a tight window around the click/open/execute time. It increases signal and avoids noise.

Step 7: Fleet-wide scoping (the three pivots that catch siblings)

If you only have time for three hunts, make them count.

1) Same URL and redirect chain

  • not just the final domain
  • include intermediate redirectors

2) Same attachment hash or filename patterns

  • kits reuse names even when hashes change

3) Same execution chain artifacts

  • rundll32 paths
  • scheduled task naming patterns
  • PowerShell flags and base64 patterns (even partial)

You’re not hunting “the phish.” You’re hunting the kit.

Step 8: Decide the incident type (this changes the response)

By this stage, you can confidently label it as one of:

  • Exposure incident (distributed, no interaction)
  • Interaction incident (clicks, no confirmed compromise)
  • Credential compromise (session/token abuse)
  • Endpoint compromise (payload executed / persistence)

Each category has a different “done” state. Don’t close an endpoint compromise with “email removed.”

Common mistakes that cost hours

  • Blocking domains that are actually shared CDNs
  • Treating all recipients as compromised (panic resets)
  • Failing to track who clicked vs who received
  • Losing evidence because you deleted before capturing
  • Not revoking sessions after credential phishing (password reset alone is not enough)

Artifact Annex (field notes)

Email pivots

  • sender + reply-to + Message-ID
  • subject patterns + timestamp clusters
  • URLs (full redirect chain)
  • attachment hashes and file types

Identity pivots (for credential phish)

  • risky sign-ins
  • new device/IP sign-ins
  • OAuth consent grants
  • mailbox rules / forwarding

Endpoint pivots (for payload delivery)

  • execution from Downloads/Temp
  • LOLBin chains (PowerShell/rundll32/mshta)
  • persistence artifacts (task XML, Run keys)
  • first-seen domains contacted after execution