This analysis documents the five-stage phishing investigation methodology used in active SOC operations — from initial triage through to formal incident reporting. Each step is grounded in real investigations conducted across both private sector SOC and federal law enforcement intelligence environments. MITRE ATT&CK mappings are included for each phase.
- DMARC FAIL combined with a spoofed display name is the most common initial access vector observed in active phishing campaigns
- Domain registration age under 30 days is the single highest-confidence indicator of a malicious sender infrastructure
- Formal IOC documentation and SIEM integration at Stage 4 creates defensive value beyond the individual incident
- Structured incident reports separate L1 SOC analysts from alert-checkers — this methodology produces reportable deliverables
Stage 1 — Initial Triage
Before touching any artefact, I establish alert context. Who reported the email, and when? Does the subject line employ urgency language ("Your account will be suspended", "Immediate action required")? I query the SIEM for correlated events from the same sender, the same destination mailbox, or the same URL pattern within the preceding 72-hour window.
The goal at triage is scope determination — is this an isolated event or part of a campaign targeting multiple users? A single phishing email is an L1 task. A campaign with 40 recipients is an escalation.
Never open a suspicious attachment or click a suspicious link directly — even in a sandboxed environment without explicit IR authorization. Submit to automated detonation infrastructure (Any.run, Hybrid Analysis) instead.
Stage 2 — Email Header Analysis
The email header is where the truth lives. I extract the raw header and examine four things in order:
- Return-Path vs From field — mismatches between the visible sender display name and the actual Return-Path address are the most common spoofing signature
- SPF / DKIM / DMARC results — a DMARC FAIL with an authoritative-looking display name is the standard credential-phishing pattern
- Received-from chain — tracing IP hops backwards from the recipient MTA reveals the actual sending infrastructure
- X-Originating-IP — when present, often reveals the webmail interface used to send the message
Return-Path: <noreply@bulk-mailer-34.xyz>
Received: from bulk-mailer-34.xyz (45.141.88.12)
SPF: FAIL (45.141.88.12 not authorised)
DKIM: FAIL (signature invalid)
DMARC: FAIL (policy: reject — delivered anyway due to misconfiguration)
# Domain registration: 8 days old
# Registrar: NameCheap · Privacy-protected
Stage 3 — URL and Payload Analysis
All extracted URLs are submitted to VirusTotal, URLScan.io, and where detonation is warranted, Any.run or Hybrid Analysis. I never click links directly — not even on isolated VM environments without authorization.
Domain registration date is my highest-confidence signal. Anything registered within 30 days of the reported incident is treated as malicious infrastructure unless proven otherwise. I also check:
- WHOIS data — registrar, creation date, nameservers
- SSL certificate issuance date and authority
- Redirect chain — where does the link ultimately resolve?
- Page content at URL — credential harvesting form? Malware dropper?
Stage 4 — IOC Documentation
Every confirmed phishing investigation produces a formal IOC table. These are ingested into the threat intelligence platform and pushed to SIEM blocklists and email gateway rules. The value of this stage extends beyond the current incident — documented IOCs from one investigation frequently surface in correlated future events.
| Type | Indicator | Description | Confidence |
|---|---|---|---|
| Domain | payroll-secure-portal[.]com | Sender domain — 8 days old, privacy-protected | High |
| IP | 45.141.88.12 | Sending MTA — known bulk-spam infrastructure | High |
| URL | hxxps://payroll-secure-portal[.]com/login/verify | Credential harvesting page — mimics corporate login | High |
| noreply@bulk-mailer-34[.]xyz | Actual Return-Path address | Medium |
Stage 5 — Incident Report
Everything is documented in a structured incident report. This is what separates a SOC analyst from someone who merely checks alerts. The format I use follows the NexSecure Bootcamp framework, with additions from FG-LEA criminal intelligence reporting standards:
- Timeline — email received → reported → investigated → resolved, with timestamps
- Classification — phishing type (credential harvest, malware delivery, BEC attempt)
- IOC Table — all extracted indicators with confidence ratings
- L1/L2 Actions Taken — what was blocked, quarantined, or escalated
- MITRE ATT&CK Mapping — observed TTPs
- Recommendations — policy or configuration changes to prevent recurrence
The report is the deliverable. Without it, the investigation never happened as far as the organization's security posture is concerned.
References
- MITRE ATT&CK Framework — T1566: Phishing
- VirusTotal URL Analysis — virustotal.com
- URLScan.io — urlscan.io
- Any.run Sandbox — any.run
- Cyber Nate — Phishing Case Study (Full Investigation)