Master the first-responder phishing workflow — reading headers to confirm spoofing, safely analysing URLs and attachments without executing anything, identifying classification type and its matching response playbook, calculating blast radius from mail and proxy logs, and producing a complete incident record from initial report to containment.
Phishing Triage — The First IR Playbook
Phishing triage is the first incident response playbook most SOC analysts encounter, and the one they will execute most frequently throughout their career. It is the structured process for investigating a reported suspicious email: confirming whether it is malicious, determining what type of phishing attack it represents, establishing who received and interacted with it, and executing the appropriate containment and remediation steps.
IR01 designates this as a foundational playbook — the baseline from which more complex incident types branch. A credential harvest that goes undetected becomes an account compromise incident. Undetected malware delivery becomes an endpoint compromise incident. Every escalation path starts with a phishing email that was either caught early or missed. The speed and accuracy of the initial triage determines which path the incident takes.
Why Speed Matters in Phishing IR
Phishing attacks are time-sensitive in both directions. An attacker who receives stolen credentials from a phishing page typically acts within minutes to hours — logging into VPN, resetting MFA, creating persistence before the victim reports the email. A credential harvest phishing campaign that is triaged and contained within 30 minutes of the first user report may result in zero account compromises. The same campaign triaged four hours later may result in multiple compromised accounts, lateral movement, and a much larger incident.
Equally, phishing campaigns are often sent to many recipients simultaneously. The time between the first user report and completing mail log analysis to identify all recipients determines how many users remain at risk during the investigation window. Fast, accurate initial triage directly limits blast radius.
Imagine a letter containing powdered toxin mailed to 47 people in an office building. The first person to open their envelope reports it immediately. The investigator now has a race: identify every recipient, get to them before they open their envelopes, and determine whether anyone already has. The faster the investigator works through the mail log and reaches each recipient, the better the outcome. An investigator who spends two hours carefully documenting one envelope before checking who else received the letter will find many opened envelopes on arrival. Phishing triage has the same structure — the email log is the mail log, the phishing page is the toxin, and every user who submits credentials before containment is an opened envelope.
The Triage Methodology
Step 1 Read headers: verify sender, trace routing, check SPF/DKIM/DMARC Step 2 Analyse links: expand URLs, check reputation (VirusTotal, URLScan.io) Step 3 Analyse attachments: file type, hash, sandbox detonation -- never open directly Step 4 Check mail logs: who received it? Distribution list or targeted? Step 5 Classify: credential harvest / malware delivery / BEC / vishing lure Step 6 Check proxy logs: did anyone click? Did anyone submit credentials (POST)? Step 7 Contain: block sender domain, quarantine copies, reset credentials if clicked Step 8 Document: write the incident report with timeline, blast radius, and actions
Email Triage in Practice
Headers reveal the true path a message took and expose spoofed senders. The visible From address is what the attacker controls — the Received chain and authentication results are what the mail infrastructure recorded.
# Visible From (what the user sees in their inbox): From: IT Support <[email protected]> # Actual sending server in bottom Received header (true origin): Received: from mail.suspicious-domain.ru [185.234.12.44] # SPF authentication result: Received-SPF: FAIL (company.com does not permit 185.234.12.44 as sender) # Conclusion: exact domain spoofing confirmed -- sender impersonating company.com
Links are often obfuscated with URL shorteners, redirectors, or display text that differs from the actual href. Always expand fully and check reputation before drawing any conclusions — never click.
# Displayed link text: "Click here to verify your account" # Actual href extracted from raw email source: http://company-secure-login.xyz/verify?token=abc123 whois company-secure-login.xyz: domain registered 2 days ago VirusTotal: 12/90 engines flag as phishing # Credential harvesting page confirmed -- lookalike domain, recent registration # Safe analysis: curl --head to check server, URLScan.io for page screenshot
Hash attachments and submit to threat intelligence without opening them directly. Sandboxes provide safe detonation when hash lookup is insufficient.
sha256sum Invoice_Q1.docm 3a4f8b2c1d9e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2 # Submit hash to VirusTotal (never upload the file itself -- may alert attacker): Detection: 47/72 engines -- Emotet dropper variant file Invoice_Q1.docm Microsoft Office Open XML document with macros enabled (.docm) # .docm + macro = classic malware delivery. Classification: malware delivery. # Sandbox detonation (Any.run, Hybrid Analysis) for full behaviour report
After confirming phishing, proxy logs reveal who visited the phishing domain. A POST request to the phishing page confirms credential submission — that user's account must be treated as compromised immediately.
Mail logs: sender delivered to 23 mailboxes across the organisation # Proxy/web gateway logs for the phishing domain: 10.0.1.45 company-secure-login.xyz 14:32:07 GET /verify (page loaded) 10.0.1.45 company-secure-login.xyz 14:32:08 POST /verify (credentials submitted!) # POST = credentials submitted. This user's credentials are now with the attacker. # Identify user at 10.0.1.45, force password reset, disable sessions IMMEDIATELY
What You Need to Know
Phishing Classification Taxonomy — Four Types, Four Playbooks
Classifying a phishing email correctly is not just a labelling exercise — it determines the entire response path. A credential harvest requires immediate password reset and session invalidation for anyone who clicked. Malware delivery requires endpoint isolation and EDR triage. BEC requires finance team notification and payment verification. Each type has a different urgency profile, different affected systems, and different stakeholders who need to be involved.
Email links to a fake login page collecting username and password. Often mimics Microsoft 365, VPN portals, banking, or corporate intranets.
Indicators: Link to external domain with login form, domain registered recently, VirusTotal flagged as phishing, POST requests in proxy logs.
Response: Identify anyone who POSTed. Immediately force password reset and invalidate all active sessions. Check for MFA bypass or new device enrolment in the identity provider. Treat account as compromised until verified clean.
Email delivers malicious attachment (Office macro, PDF exploit, LNK file, ZIP with executable) or links to a drive-by download page.
Indicators: .docm/.xlsm/.pdf/.zip attachment, hash detected by threat intel, sandbox shows process execution, network connections on detonation.
Response: Identify anyone who opened the attachment (endpoint logs, EDR telemetry). Isolate affected endpoints immediately. Pull EDR for process tree and network activity. Escalate to endpoint compromise IR if execution confirmed.
Impersonates an executive or trusted party to request a wire transfer, payment redirect, or sensitive information. No link or attachment — pure social engineering.
Indicators: Display name matches executive but sending domain differs, urgent financial request, requests for secrecy, no link or attachment (no technical payload).
Response: Immediately notify finance team — do not allow any payment action until verified out-of-band. Check whether any payment was already initiated. Report sending domain to registrar. Low technical complexity, high financial risk.
Email designed to prompt a phone call to an attacker-controlled number. Fake invoices, tech support scams, "urgent account issue" lures asking the user to call a number.
Indicators: No link or attachment, prominent phone number, urgency language, often impersonates known vendors or government agencies.
Response: Block sender. Identify anyone who may have called the number (difficult to detect — may require user notification and self-reporting). Document phone number as IOC. No technical containment required unless call resulted in remote access tool installation.
Safe URL and Attachment Analysis — Tools and Technique
The discipline of analysing potentially malicious content without executing it or interacting with it as a user is fundamental to phishing triage. Every tool and technique described here maintains analyst isolation — the phishing content is examined, not experienced.
URL Analysis Without Clicking
- Extract the raw href from email source: Never trust display text. View the raw HTML source of the email and extract the actual href attribute value. URL shorteners and redirectors require expansion — use an expansion service or
curl -sI [url]to follow redirects without loading the page. - VirusTotal domain/URL lookup: Submit the full URL to VirusTotal for engine-based classification. A newly registered domain with zero prior history is itself a weak signal — combine with display name and email context.
- URLScan.io: Submits the URL to a browser sandbox and returns a screenshot, DOM content, network connections made, and resource hashes. Provides a visual confirmation of what the user would have seen without the analyst visiting the page. Note: URLScan submissions are public — do not submit internal URLs containing session tokens or sensitive parameters.
- WHOIS for domain age: Domain registered in the last 30 days combined with any phishing indicator is high-confidence malicious. Use
whoisor a web-based WHOIS for registration date and registrant details. - curl --head for server response:
curl -sI https://[domain]returns HTTP headers without loading page content. Server type, redirect chain, and response codes provide technical context without browser execution risk.
Attachment Analysis Without Opening
- Hash first, always:
sha256sum [filename]produces the file's hash. Submit to VirusTotal hash lookup before any other action. If the hash is known-malicious, you have a confirmed detection without touching the file further. - File type verification:
file [filename]reveals the true file type regardless of extension. A file named "Invoice.pdf" that is actually an executable or a ZIP is immediately suspicious. Extension mismatch is a strong indicator. - Sandbox detonation for unknown hashes: Any.run, Hybrid Analysis, and VirusTotal's sandbox allow safe detonation in an isolated environment. The sandbox executes the file and captures: process creation tree, network connections, registry modifications, file system changes, and C2 communication attempts. This produces the definitive behavioural analysis without any risk to analyst systems.
- Never upload to VirusTotal if the file contains sensitive data: VirusTotal submissions are visible to paying subscribers. An attachment containing an internal document, credentials, or PII should be analysed by hash only, or detonated in a private sandbox.
A systematic analysis of both a suspicious link and attachment from a single phishing email, staying entirely non-interactive throughout.
--- URL Analysis --- # Step 1: Extract raw href from email source (never trust display text) Displayed: "Review your invoice" Actual href: http://bit.ly/3xK9mPq # Step 2: Expand shortener without clicking curl -sI http://bit.ly/3xK9mPq | grep Location Location: https://microsoft-365-invoices.com/review?id=4821 # Step 3: WHOIS the expanded domain whois microsoft-365-invoices.com Creation Date: 2026-05-19 (7 days ago) # Step 4: URLScan.io for visual confirmation (no analyst browser risk) curl -X POST "https://urlscan.io/api/v1/scan/" -d '{"url":"https://microsoft-365-invoices.com/review"}' Screenshot: Microsoft 365 login page clone. Password field present. Classification: CREDENTIAL HARVEST -- Microsoft 365 phishing page --- Attachment Analysis --- sha256sum Remittance_Advice.xlsm f3a2b1c4d5e6... # Submit to VirusTotal hash lookup VT Result: 38/72 detected -- Qakbot dropper file Remittance_Advice.xlsm Microsoft Excel Open XML Spreadsheet (macro-enabled) # Both vectors confirmed malicious. Classification: COMBO -- credential harvest + malware delivery
Blast Radius Calculation and Escalation Tiers
Blast radius — who received the email, who opened links, who submitted credentials, who opened attachments — determines both the scope of containment required and the severity classification of the incident. Calculating blast radius accurately and quickly is the most operationally critical step in phishing triage.
| Blast Radius Finding | Severity | Required Response | Escalation |
|---|---|---|---|
| Email delivered, no interaction confirmed | Low | Quarantine all copies. Block sender domain at mail gateway. Notify affected users not to interact. | SOC only |
| Link clicked (GET only — page loaded, no credentials submitted) | Medium | All Low actions plus: identify clicking user(s), force browser cache/cookie clear, monitor for follow-on access from unusual locations. | SOC + user manager notification |
| Credentials submitted (POST confirmed in proxy logs) | Critical | All above plus: immediate force password reset, invalidate all active sessions in IdP, disable MFA devices enrolled after the POST timestamp, check for new OAuth grants or mail forwarding rules. | SOC + IR lead + identity team + user's manager |
| Malware attachment opened / executed (EDR confirms) | Critical | Isolate endpoint immediately (network quarantine via EDR). Pull full process tree and network connections. Escalate to endpoint compromise IR playbook. Check for lateral movement. | SOC + IR lead + endpoint team + CISO if ransomware suspected |
14:31 — Report received: User Linda from Finance submits a suspicious email report via the phishing button in Outlook. The email claims to be from IT Support with an urgent password expiry warning and a link to reset credentials.
14:33 — Header analysis: SPF FAIL. Sending IP 185.234.12.44 does not match company.com SPF record. DMARC fail with p=quarantine (email delivered to junk but not blocked). Display name spoofing — the From header shows "IT Support <[email protected]>" — a lookalike domain registered 4 days ago.
14:35 — URL analysis: Link expands to https://corp-helpdesk.net/password-reset. URLScan.io screenshot shows a convincing Office 365 credential harvest page. VirusTotal: 9/90 engines flagged. Domain age 4 days confirmed.
14:37 — Mail log query: Sender delivered to 31 mailboxes. All Finance and HR staff. Targeted campaign — not mass phishing.
14:39 — Proxy log query: Three users visited corp-helpdesk.net. Two GET requests only (browsed but did not submit). One user — 10.0.4.22, James Okafor in Finance — has a POST to /password-reset at 14:34. Credentials submitted 3 minutes before Linda reported the email.
14:41 — Escalation and containment: IR lead notified. Identity team paged. James Okafor's account: password reset forced, all sessions invalidated in Azure AD, MFA devices reviewed (no new enrolment since POST). James called directly — confirmed he submitted his credentials. Mail gateway block on corp-helpdesk.net and 185.234.12.44 applied. Remaining 30 copies quarantined from all mailboxes.
14:59 — All clear: No further credential submissions. No anomalous sign-in activity on James's account (attacker had not yet used the credentials — 20-minute window closed by containment). Incident documented, post-mortem scheduled. Total time from report to containment: 28 minutes.
Incident Report Structure
Every phishing triage produces an incident record that serves as the definitive account of what happened, what was found, and what was done. This record feeds compliance reporting, post-incident review, threat intelligence (IOCs extracted from the investigation), and user awareness training (real examples from your own environment are the most effective training material).
The standard phishing incident report format covering all required fields for both operational use and compliance documentation.
INCIDENT RECORD — INC-2026-0522 Classification: Credential Harvest Phishing Severity: Critical (credential submitted confirmed) Status: Contained Reported: 2026-05-26 14:31 UTC by Linda Chen (Finance) Analyst: J. Harrington TIMELINE 14:28 Phishing email delivered to 31 mailboxes 14:34 James Okafor submitted credentials to phishing page (POST confirmed) 14:31 Linda Chen reported email via Outlook phishing button 14:41 Password reset forced, sessions invalidated (James Okafor) 14:41 Mail gateway block applied, copies quarantined 14:59 No further credential submissions. Incident contained. TECHNICAL FINDINGS Sender: [email protected] (lookalike domain, 4 days old) Spoofing: Display name "IT Support" -- SPF FAIL, DMARC FAIL Payload: Credential harvest page at corp-helpdesk.net/password-reset Recipients: 31 (Finance and HR departments -- targeted campaign) Clicked: 3 users visited URL Submitted: 1 user (James Okafor, 10.0.4.22) -- POST at 14:34:08 IOCs IP: 185.234.12.44 Domain: corp-helpdesk.net URL: https://corp-helpdesk.net/password-reset ATT&CK: T1566.002 (Spearphishing Link), T1598.003 (Phishing for Information) CONTAINMENT ACTIONS James Okafor: password reset, sessions invalidated, MFA reviewed Mail gateway: sender IP and domain blocked 31 mailboxes: phishing copies quarantined No evidence attacker used credentials before containment RECOMMENDATIONS DMARC p=reject for company.com (currently p=quarantine) Targeted user awareness for Finance/HR (highest-risk departments) Consider deploying phishing-resistant MFA (FIDO2) for Finance staff
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — IR01 Phishing Triage→← Return to all labs