Playbooks

T1566

Phishing Triage

A step-by-step SOC playbook for triaging reported phishing emails — intake to decision in 15 minutes, with email header analysis, URL sandboxing, attachment scanning, detection queries, and clear escalation criteria.

View on Graph

What This Playbook Covers

  • This playbook handles the most common SOC intake: a user reports a suspicious email via the phishing report button, a forwarded message to phish@company.com, or a ticket from the help desk.
  • Goal: triage each submission and reach one of three dispositions within 15 minutes — (1) Benign: legitimate marketing, newsletter, or internal communication the user misidentified. (2) Phishing Simulation: company-run phishing test. Record that the user reported it correctly (or failed to report it). (3) Malicious: real phishing attack targeting the organization. Escalate.
  • MITRE ATT&CK maps phishing to T1566 (Phishing) with sub-techniques T1566.001 (Spearphishing Attachment), T1566.002 (Spearphishing Link), and T1566.003 (Spearphishing via Service).

Phase 1: Intake and Quick Filter (0-5 minutes)

Email Metadata — Find the Headers

Extract the raw email headers (use OSINT Tools for automated header analysis). All the critical information is here:

Header FieldWhat It Tells YouSuspicious Indicator
FromDisplay name and email addressDisplay name of executive, but email is external (e.g., ceo@ gmail.com)
Reply-ToWhere replies actually goDifferent from From address — attacker intercepts replies
Return-PathBounce addressDifferent from From — SPF failure is likely
Received chainMail server routeFirst Received from an unknown IP, or hop count doesn’t match
Message-IDUnique email IDFormat or domain doesn’t match the claimed sender domain
DKIM-SignatureCryptographic signature of the emaildkim=fail — email was tampered with or forged
SPF (via Received-SPF)Authorization of sending serverspf=fail — sending server is not authorized for this domain
DMARC (via Authentication-Results)Policy for SPF/DKIM failuredmarc=fail — email failed both SPF and DKIM authentication

The authentication fields map directly to SPF and DKIM — when these fail, the email is almost certainly forged.

SPL query — search for phishing emails sent to other users from same sender/domain:

index=email sourcetype=email_security
| search sender_address="*attacker-domain.com" OR from_domain="attacker-domain.com"
| stats count by sender_address, recipient_addresses, subject
| where count > 1
| eval alert = "HIGH — same sender sent phishing emails to " . mvjoin(recipient_addresses, ", ")
| table _time, sender_address, recipient_addresses, subject, count, alert

Quick Checks

CheckWhat to Look ForBenignPhishing
SPF/DKIM/DMARCAuthentication statusAll passOne or more fail
Display name vs actual addressMismatchMatchHR Department <h4ck3r@evil.com>
Known phishing URLURL reputation in VT/URLScanCleanBlocked, malicious, or suspicious
Attachment hashFile hash in VirusTotalClean or known-goodDetected as malware
Subject unusualUrgency, threats, giftsNormal business”Urgent password reset”, “Your account will be suspended”, “You won a gift card”

Phase 2: URL and Attachment Analysis (5-10 minutes)

URL Analysis

Extract URLs from the email body:

# Extract all URLs from an email file
grep -oE 'https?://[A-Za-z0-9./?=_%:-]*' email.eml

# Look for obfuscated URLs
cat email.eml | grep -iE '(href|http|url|link|click|redirect)'

Common obfuscation techniques to check for:

ObfuscationExampleHow to Detect
Legitimate domain + subdomainhttps://legitimate.com.security.evil.com/Check the real domain (rightmost part before TLD)
URL shortenerbit.ly/3xYzAbcExpand with curl -I or unshorten tool
Homoglyph charactersg00gle.com (zero instead of O)Visually inspect or use a homoglyph detector
Redirect on legitimate domainhttps://legitimate.com/redirect?url=evil.comCheck the redirect parameter target
Base32/Base64 encoded URLEncoded in the email bodyDecode with base64/base32 utility and check the result
QR code phishing (QRishing)QR in attached imageExtract and scan with QR reader in sandbox

Attachment Analysis

Attachment TypeSuspicious IndicatorAnalysis Tool
.pdfContains embedded URL or JavaScriptpdfinfo, pdfid.py, peepdf
.docx / .xlsxContains macrosolevba, oledump
.htmlContains JavaScript redirect or credential formView source, check for document.write(), window.location
.iso / .imgDisk image — often used to bypass email attachment filtersMount in sandbox, check contents
.lnkShortcut to remote scriptCheck target path and arguments
.urlLink file pointing to malicious URLOpen with notepad — check URL value
.zip / .7z / .rarPassword-protected archive (password in email body)Extremely suspicious — request password if urgent, otherwise detonate

Phase 3: Threat Intelligence Checks (10-12 minutes)

Check the Sender Domain

# Check domain reputation
whois attacker-domain.com
dig attacker-domain.com mx
dig attacker-domain.com txt

# Check for recently registered domain
whois attacker-domain.com | grep -E "Creation Date"
# Domains registered < 30 days ago are highly suspicious

Check URLs Against Threat Intelligence

ServiceWhat It DoesWhen to Use
VirusTotal URLScans URL against 70+ scannersFirst check — fastest
URLScan.ioTakes a screenshot of the rendered pageWant to see what the victim would see
AbuseIPDBCheck IP reputationPhishing site is hosted on an IP, not a domain
PhishTankCommunity-vetted phishing URLsCheck if this URL is already reported
Google Safe BrowsingReal-time phishing URL blockingCheck with curlhttps://safebrowsing.googleapis.com/...

Phase 4: SIEM Correlation (12-15 minutes)

Check if Other Users Received the Same Email

SPL query — find other recipients of the same phishing email (run in Splunk):

index=email sourcetype=email_security
| search subject="*URGENT*Password*Reset*" OR subject="*Invoice*Overdue*" OR sender_address="*@evil-domain.com"
| stats count by subject, sender_address, sender_ip, recipients
| where count > 1
| eval alert = "MULTIPLE RECIPIENTS — " . count . " users received phishing email from " . sender_address . " with subject '" . subject . "'"
| table _time, sender_address, subject, count, recipients, alert

SPL query — correlate email events with proxy/web events:

index=proxy sourcetype=access_combined
| search dest_domain="evil-domain.com" OR dest_ip="ATTACKER_IP"
| eval user = coalesce(username, client_ip)
| stats count, values(url) as URLs, values(dest_domain) as Domains by user
| table _time, user, count, URLs, Domains

Phase 5: Disposition and Escalation (15 minutes)

Decision Matrix

FindingDispositionAction
SPF/DKIM/DMARC all pass. URL is legitimate. No attachment.BENIGNClose ticket. Notify user it was benign.
SPF/DKIM/DMARC all pass. Known company test platform URL.SIMULATIONRecord user behavior (reported = good). Close.
SPF fail. URL is malicious on VirusTotal.MALICIOUS — PHISHINGBlock sender domain at email gateway. Remove from all user inboxes. Begin incident response.
SPF pass (compromised legitimate account). URL redirects to credential harvester.MALICIOUS — ACCOUNT TAKE OVERLock the compromised sender account. Remove forwarded email. Escalate.
Attachment detected as malware by VirusTotal.MALICIOUS — MALWAREBlock file hash. Check for detonation on recipient’s endpoint. Escalate.
SPF fail. URLs uncheckable (sandboxed). No VT hits.SUSPICIOUS — FURTHER INVESTIGATIONDeeper header analysis. Check if user clicked. Watch for 24-48 hours.

Escalation Thresholds

SignalEscalate ToTimeline
Credential harvesting confirmedSOC LeadImmediate
Malware attachment detonatedIncident Response TeamImmediate
Account takeover confirmedIncident Response + Identity TeamImmediate
Executive impersonated (CEO fraud)Incident Response + Executive ProtectionImmediate
BEC/financial fraudFinancial Fraud team + IC3Immediate + report
Single user, no click-throughSOC analyst — closeSame shift

Common Phishing Triage Mistakes

MistakeWhy It’s Dangerous
Trusting the display nameAttackers spoof display names. Always check the actual email address.
Clicking links from the SOC workstationIf the URL is malicious, clicking from corporate IP lands on adversary infrastructure. Always use a sandbox or VT.
Ignoring DMARC failuresMany SPF-pass but DKIM-fail emails look legitimate but are actually office.com or SharePoint-branded credential harvesters.
Not checking for forwarding rulesAfter account compromise, attackers often set up inbox rules to hide responses. Check Outlook rules / OWA redirects.
Only checking the first URLModern phishing emails often have multiple URLs — one legitimate (to pass filters), one malicious.
Trusting benign attachment types.html attachments can contain credential harvesters. .iso containers bypass email AV scanning.

Sources