Phishing Investigation Demystified: From Inbox to Incident Report

Phishing remains the most common initial access vector in modern breaches. The FBI IC3 continues to rank phishing and spoofing as the top reported crime category, while Verizon’s Data Breach Investigations Report consistently shows the human element contributing to roughly 60%+ of incidents. For SOC analysts, the difference between a closed ticket and a full-blown account takeover often comes down to a disciplined, repeatable investigation process.

This guide walks through that process end-to-end: from the moment a suspicious message lands in a user’s inbox, through authentication analysis (SPF, DKIM, DMARC), command-line evidence collection, alert triage integration, scoping, and finally the incident report. It draws on established SOC workflows (including practical frameworks published by teams such as Prophet Security) and points to open-source tooling that can accelerate the work.

The Four Questions Every Phishing Investigation Must Answer

A solid investigation answers these in sequence:

1. Is the message genuinely malicious?
2. Who received it?
3. Did anyone interact with it (open, click, reply, or submit credentials)?
4. What is the blast radius and current exposure?

The lure (credential harvest, BEC, brand impersonation, or abuse of legitimate services) changes the artifacts, but the questions stay the same. MITRE ATT&CK catalogs the delivery under T1566 and its sub-techniques; the investigation treats phishing as a delivery mechanism whose outcome must still be scoped.

Step 1: Confirmation and Initial Triage

Most reported messages turn out to be benign or low-impact. Still, every report needs validation because the cost of missing a real compromise is high. Confirmation includes:

• Deduplicating against known campaigns already under investigation.
• Assigning a severity that drives prioritization (business impact over pure volume).
• Checking whether the message has already been auto-quarantined or purged.

This sits inside the broader alert triage pipeline. Alert triage is the systematic evaluation and classification of incoming signals so limited analyst time goes to the highest-risk items. Phishing reports are one input among endpoint, identity, cloud, and network alerts. Effective triage requires:

• Understanding the detection logic that fired.
• Pre-correlated entity context (user, assets, recent related alerts).
• Alert-type-specific investigation paths rather than a generic “check the logs” playbook.

Severity-based prioritization alone creates blind spots: early-stage activity often surfaces as medium or low severity. High false-positive rates breed alert fatigue. Context assembly that forces analysts to jump across five consoles burns investigation time before real analysis begins. Structured, type-specific methodology and a feedback loop into detection engineering are what turn triage from a queue-management exercise into a quality control layer.

Step 2: Evidence Collection — Headers, Authentication, and the Email Itself

Preserve the original message in native format (.eml or .msg) with full headers and attachments intact before any remediation. Containment can destroy the very artifacts needed for the report or for law enforcement.

Example of authentication results from a mail security console showing SPF, DKIM, and DMARC all passing.

Authentication Results: SPF, DKIM, and DMARC

These three mechanisms form the first technical verdict most analysts look at.

• SPF (Sender Policy Framework) checks whether the sending IP is authorized by the domain’s DNS TXT record.
• DKIM (DomainKeys Identified Mail) verifies a cryptographic signature over selected headers and the body.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) ties the two together with an alignment check and a policy (none / quarantine / reject).

A message that shows PASS on all three is not automatically safe. Attackers routinely send from compromised legitimate infrastructure or use lookalike domains that pass authentication. Conversely, a hard FAIL is a strong signal but still requires correlation with content, URLs, and user interaction.

Here is a typical view of authentication results on a legitimate report message (the kind of screenshot an analyst might capture during investigation):

The highlighted section confirms:

• SPF: PASS with a specific IP
• DKIM: PASS with the domain
• DMARC: PASS

In real investigations you will also see SoftFail, Neutral, None, or Fail, plus the exact IP and selector used.

DNS Record Structure (Quick Reference)

SPF example

v=spf1 include:_spf.google.com ip4:192.0.2.1 -all

DKIM example (selector + public key)

Host: google._domainkey

Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…

DMARC example (always at _dmarc.yourdomain.com )

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com

DNS Verification (Command-Line)

Once you have the From domain (and any lookalike domains that appear in the body or links), verify the published records directly:

# DNS checks for the From domain and any lookalikes
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT selector._domainkey.example.com +short

For richer automation, open-source projects such as **PhishGuard AI** demonstrate hybrid pipelines (TF-IDF + SVM + heuristic scoring + Streamlit dashboard) that can ingest message text or structured fields and return a risk verdict with explanations. Use them as accelerators, never as replacements for judgment.

Live URLs and attachments should be detonated only in an isolated sandbox. Never open them on an analyst workstation that has production credentials or network access to internal resources.

Step 3: Exposure and Interaction

Identify every recipient. Partition them:

• Received only
• Opened
• Clicked link or opened attachment
• Submitted credentials or replied

Interaction turns a delivered message into an incident. Pull this data from the mail gateway, SIEM, or EDR/mail security console. For any interacting user, immediately review:

• Recent sign-in logs (impossible travel, new devices, unusual geographies)
• Newly created inbox rules (especially auto-forward or delete)
• OAuth grants and consented applications
• Outbound mail volume and new contacts

Step 4: Scoping the Blast Radius

Second-order indicators reveal whether the attacker moved beyond the original inbox. Look for lateral movement, additional mailbox access, persistence mechanisms, and any data that may have left the environment. Document every related alert on the same entity within the relevant time window.

Step 5: Containment, Remediation, and the Incident Report

Containment actions flow from the evidence:

• Purge the message across all mailboxes
• Reset credentials and revoke active sessions for affected accounts
• Block malicious infrastructure (domains, IPs, file hashes)
• Revoke suspicious OAuth grants and remove malicious inbox rules
• Notify affected users with clear next steps

Remediate after scoping. Acting too early can leave forwarding rules or OAuth tokens intact.

The final incident report should contain:

• Timeline of discovery, investigation, and containment
• Original message (headers + body summary)
• Authentication results and sending infrastructure
• URLs, attachment hashes, and sandbox reports
• Recipient list and interaction status
• Account-level findings (sign-ins, rules, grants)
• Indicators of compromise written back into detection rules
• Lessons learned and any detection or process improvements

Evidence preservation is non-negotiable. The original message, authentication results, resolved URLs, hashes, interaction records, and account telemetry form the audit trail.

Scaling the Work: Automation and AI

Manual investigation does not compress easily. Retroactive quarantine notices alone can force the same sequence hundreds of times. SOAR playbooks handle repetitive enrichment and containment. AI-assisted investigation systems can apply the full five-step method to every reported message, produce documented reasoning, and free analysts for the ambiguous or high-impact cases. Both approaches preserve the core workflow; the difference is how many cases receive consistent depth.

Projects like PhishGuard AI illustrate one direction: lightweight, explainable models that score intent and surface threat reasons so an analyst can focus on the judgment calls that still require a human.

Closing the Loop

A phishing investigation that ends without writing indicators back into detection engineering is a case that is likely to recur. Feed sender infrastructure, lookalike domains, credential-harvest URLs, and file hashes into the detection pipeline. Use triage outcomes to tune rules and reduce the noise that creates fatigue.

The method itself stays fixed. Whether the lure is a classic credential harvest, a targeted BEC payment request, or a message routed through legitimate infrastructure, the same five steps — confirm, collect, determine exposure and interaction, scope, remediate — produce a defensible verdict and a usable incident report.

Master the email authentication signals, keep your command-line toolkit sharp, treat every report as potential evidence, and integrate the work into a disciplined alert triage process. That is how an inbox notification becomes a controlled, well-documented incident rather than an open door.

References and Further Reading

Email authentication standards

• RFC 7208 — Sender Policy Framework
• RFC 6376 — DomainKeys Identified Mail Signatures
• RFC 7489 — Domain-based Message Authentication, Reporting and Conformance

Provider guidance

• Google Gmail Sender Guidelines
• Google Gmail Sender Guidelines FAQ

Threat framework

• MITRE ATT&CK — Phishing T1566
• MITRE ATT&CK — Spearphishing Attachment T1566.001

Threat and fraud reporting

• FBI Internet Crime Complaint Center — 2024 IC3 Annual Report

Project

• PhishGuard AI — GitHub

Connect with Me

• **Portfolio.**
• **X(Twitter)**
• **Linkedin**