Phishing alert investigation: a step-by-step walkthrough

Phishing is one of the highest-volume alert types in most SOCs. It's also one of the most common places analysts make mistakes — dismissing something that should have escalated, or escalating a legitimate marketing email because the headers looked unusual. Getting phishing triage right early in your career matters.

This is a realistic walkthrough of how you'd investigate a phishing alert from the moment it lands in your queue.

What triggers a phishing alert

Phishing alerts reach your queue from several sources:

Email gateway detection — your email security platform (Proofpoint, Defender for Office 365, Mimecast) flags a message based on URL reputation, file hash, sender reputation, or a policy rule
Proxy/web filter log — a user clicked a link in a suspicious email and your proxy logged the connection to a known-malicious URL
User report — someone hit "Report Phishing" in Outlook, which pushes the message to the security mailbox
SIEM correlation rule — multiple users received the same email, triggering a campaign-level alert

Each of these gives you different starting context. An email gateway alert gives you full message metadata before anyone has clicked anything. A proxy alert tells you a click already happened — which changes the priority significantly. A user report often gives you the raw email to inspect directly.

Step 1: Get the email metadata

Before you open any links or attachments, establish what you're looking at:

From address — what does it claim to be? Does the display name match the actual sending address?
Reply-To — does it differ from the From? A mismatched Reply-To is a classic phishing indicator.
Sending domain — is it the legitimate domain or a lookalike? paypa1.com, microsoft-support.com, amazon.uk.co
Message ID and timestamps — useful for pivoting in your SIEM to find other recipients

In a SIEM, you're searching your email log source:

index=email_gateway src_domain="paypa1.com"
| table _time, to, from, subject, attachment_name, url

Step 2: Check authentication headers

Legitimate organisations configure email authentication. Look at the SPF, DKIM, and DMARC results:

SPF pass — the email came from a server the sending domain has authorised
DKIM pass — the email content hasn't been tampered with in transit
DMARC pass — the email passed the sending organisation's own policy check

All three failing on an email claiming to be from your bank is a significant indicator. All three passing doesn't mean it's legitimate — it means the attacker set up their own authenticated domain, which is increasingly common in targeted campaigns.

Step 3: Analyse the URL

If the email contains a URL, this is where most of your triage time goes. Do not click it in a browser. Use purpose-built tools:

VirusTotal — paste the URL and check how many engines flag it. More than two or three flags is significant. Zero flags does not mean safe.
URLScan.io — this visits the URL in a sandboxed browser and shows you a screenshot. You can see if it's a credential harvesting page without clicking anything yourself.
Threat intelligence feeds — is the domain on your internal blocklist? Does it appear in feeds your SOC subscribes to?

Also look at the domain registration date. A domain registered three days ago hosting an "HMRC refund portal" is not HMRC.

Step 4: Check the attachment

If there's an attachment, get the hash and look it up:

MD5 or SHA256 hash from your email security tool
Search VirusTotal, MalwareBazaar, and your EDR platform
Check the file type — a .pdf that's actually an executable is immediately suspicious; macro-enabled Office documents are a classic delivery mechanism

If your SOC has a sandbox (Any.run, Cuckoo, Hatching Triage), submit it there for detonation. Don't open it on your workstation regardless of what you find.

Step 5: Pivot to blast radius

Is this one recipient or many? Search for other recipients of the same message:

index=email_gateway (subject="Your invoice is ready" OR url="paypa1.com")
| stats count by to
| sort -count

If 40 people received the same phishing email, this is a campaign. That changes your response from "close this alert" to "does the team need to block this domain, reset credentials, or kick off a broader IR process?"

More critically — did anyone click?

index=proxy url="paypa1.com/*"
| table _time, src_ip, user, url, http_status

A click means you need to treat those users as potentially compromised and check for credential submission or malware execution on their endpoints. This is when the alert escalates from triage to incident response.

Verdict decision

True positive — escalate immediately if:

Any user clicked the URL, especially if the destination was a login form
Attachment is confirmed malware on detonation or TI lookup
Campaign-scale activity across multiple recipients

True positive — close (low severity) if:

Email was blocked before delivery, no user interaction, single recipient, clear phishing indicators but no active threat

False positive — close if:

The email is from a legitimate sender whose domain looks unusual but is real (DocuSign, transactional mail services, legitimate lookalike domains belonging to the claimed sender)
The URL is a marketing tracking link flagged by heuristics but not corroborated by any TI source
The "phishing report" came from a user who misidentified a legitimate email

Document your verdict and reasoning every time. If you escalated, note what you found. If you closed, note why you were confident.

This is exactly the same process you'll use from your first week in a SOC — and the same process covered in what is alert triage at a higher level.

Work through real phishing scenarios. SOCentre gives you email metadata, threat intel lookups, and MITRE ATT&CK mappings to practice on before your first day. Start training free — no card required.