How to Investigate a Suspicious Phishing Alert

A reported phishing email is one of the highest-volume, lowest-signal alert types a SOC handles, and one of the categories where getting the investigation wrong has real consequences. Closing the ticket isn't the goal. Reaching a defensible verdict on whether anything downstream of that email was actually affected is.

The chain: email → URL → user → endpoint → network → verdict

I work the investigation as a chain, because each link either stops the chain (nothing further happened) or hands you a concrete artifact to keep pulling on.

1. Email

Start with headers, not the body. Sender authentication results (SPF, DKIM, DMARC), the true originating IP, and reply-to mismatches tell you more in thirty seconds than the email content does. Check whether this sender or infrastructure has shown up in other reports.

2. URL

Any embedded link gets detonated in isolation, never in a live browser on a production endpoint. What matters is the final landing page after redirects, not the link as it first appears. Phishing infrastructure routinely chains redirects specifically to survive first-pass URL reputation checks.

3. User

Did the user open it, click it, or enter credentials? This is usually the single most important question in the whole investigation, because the answer decides whether this is a 'delivered but not actioned' event or a credential-exposure event that needs a password reset and session revocation.

4. Endpoint

If the user interacted with the message, pull endpoint telemetry for the relevant window: process creation from the mail client or browser, any file downloads, and any child processes that don't belong to a normal browsing session.

5. Network

Check for outbound connections to the same infrastructure the phishing link resolved to, and for any sign-in activity from unfamiliar locations or client applications in the hours following.

6. Verdict

Every investigation ends in one of a small number of verdicts: delivered and reported (no interaction), delivered and clicked (no credential exposure), or credential/endpoint compromise. The verdict should trace back to specific evidence from the chain above, not a gut call.

The chain doesn't have to go all the way to 'network' to be a complete investigation. It has to go far enough to justify the verdict.

Why consistency matters more than speed here

Phishing volume makes it tempting to shortcut the chain for alerts that 'look' benign. The chain exists specifically because that instinct is unreliable at scale. A consistent, repeatable process is what makes the eventual real incident easy to spot instead of getting buried under triage fatigue.