Phishing Incident Response: A Step-by-Step Runbook for SOC Teams

Phishing is the most common initial access vector in enterprise breaches. Most organizations have email gateways, user training programs, and detection rules in place. And yet phishing still works — because attackers adapt faster than defenders retrain.

This runbook covers the complete phishing response process from the moment an alert fires through containment, investigation, recovery, and documentation. Every step comes from real phishing incidents handled at major Canadian financial institutions using CrowdStrike Falcon, Microsoft Defender for Office 365, and Microsoft Sentinel.

Phase 1: Detect and Validate

Phishing alerts come from multiple sources: user reports, email gateway detections, SIEM rules firing on URL clicks, or EDR alerts on post-click activity. The source matters because it changes where you start.

Step 1: Retrieve full email headers

Pull the complete email headers and check SPF, DKIM, and DMARC results. A legitimate sender almost never has a Reply-To pointing to a different domain. Look specifically for:

• Mismatch between the From display name and the actual sending address
• Reply-To pointing to a Gmail, Hotmail, or other free provider
• DMARC fail or soft fail on a domain that should be passing
• Sending IP that does not match the domain's SPF record

Step 2: Analyze URLs and attachments safely

Extract all URLs and file hashes without clicking. Submit to URLScan.io and VirusTotal. For attachments, upload to ANY.RUN for sandbox detonation. You are looking for:

• Credential harvesting pages mimicking your organization's login portal
• Redirectors that serve different content to sandbox IPs vs real users
• Macros or scripts embedded in Office documents
• ISO or ZIP files containing executables (common phishing delivery method)

Step 3: Determine blast radius

Search your email platform for the sender domain, subject line, and embedded URLs across all mailboxes. You need to know how many people received this before you can scope containment. In Microsoft 365, use Threat Explorer in the Defender portal.

Step 4: Check for clicks

Check email gateway click tracking, web proxy logs, and your EDR for process creation events in the window after the email was received. This tells you whether you have a contained detection or an active execution.

Severity scoring

• P1: Credentials entered on a phishing page, or payload executed on endpoint
• P2: Link clicked, no confirmed credential entry or execution
• P3: Email received and reported, no clicks confirmed

Phase 2: Contain

1. Block the sender domain and sending IP at your email gateway for all users
2. Block the malicious URL or domain at your web proxy and DNS filter
3. If anyone clicked: isolate the endpoint through CrowdStrike Network Isolation immediately
4. Quarantine the email from all mailboxes using the Defender portal soft delete
5. If credentials may have been entered: force password reset and revoke all sessions in Entra ID now — do not wait for confirmation
6. Disable any inbox forwarding rules on the affected account

Phase 3: Investigate

On any isolated endpoint, pull the process tree for the 30 minutes following the email open. Use this CrowdStrike LogScale query to find post-click process execution:

#event_simpleName=ProcessRollup2
ComputerName=AFFECTED_HOSTNAME
ParentBaseFileName IN ("WINWORD.EXE","EXCEL.EXE","OUTLOOK.EXE",
  "chrome.exe","msedge.exe","firefox.exe")
| table @timestamp ComputerName UserName ImageFileName CommandLine ParentBaseFileName
| "sort" @timestamp desc

Beyond the process tree, investigate these areas:

Azure sign-in logs

Check for successful authentications from new countries or IP addresses in the 72 hours after the phishing email was received. Impossible travel — a sign-in from Canada followed 20 minutes later by a sign-in from Eastern Europe — confirms credential theft.

OAuth application grants

Attackers increasingly use phishing to steal OAuth tokens rather than passwords. Check for new application consent grants made under the affected identity in the past 30 days. A third-party app with Mail.Read and Files.ReadWrite permissions granted by a user who does not remember doing it is a confirmed attack.

Scheduled tasks and registry run keys

Check for new scheduled tasks (EventCode 4698) and new registry persistence mechanisms on any endpoint involved. These are planted immediately after initial access to survive reboots.

Communication Scripts

Use these templates verbatim or adapt to your organization's tone. The goal is to communicate clearly without creating panic or tipping off the attacker if this is a targeted campaign.

Phase 4: Eradicate and Recover

1. If any payload executed: reimage the machine from a clean baseline — do not attempt to clean in place
2. Re-enable the account only after password reset, MFA re-enrollment, and session revocation are all confirmed
3. Submit IOCs to your threat intel platform and email gateway vendor
4. Require the affected user to complete phishing awareness training before returning to full access
5. Review email gateway rules and tighten any gaps this phish exploited
6. Document the full timeline in your incident management system