Phishing Email Investigation: A Step-by-Step Workflow From User Report to Closed Case

Before any analysis, answer the single most important triage question: did the reporting user interact with the email, or are they reporting it unclicked? This distinction determines the entire scope and urgency of your investigation. An unclicked report of a phishing email is a prevention success story that requires a sweep for other recipients and a clean verdict on the email itself, but almost certainly does not involve active compromise. A clicked link or opened attachment potentially represents an active compromise, and that investigation is fundamentally different: you are now investigating a potential breach, not just a malicious email.

Ask the reporting user directly and specifically: Did you click any link in this email? Did you open any attachment? Did you enter your credentials on any page the email took you to? Did you approve any MFA prompts that arrived after you clicked? Users sometimes minimize or misremember their actions under the anxiety of reporting a potential security incident. If you get vague answers, correlate against your email security gateway logs (did the user's client fetch any URLs from the email?), proxy logs (did the user's machine make outbound requests to the destination domain?), and EDR telemetry (did a browser process make network connections to the phishing domain around the time the email was received?).

The clicked-vs-unclicked gate should be the first branch in your investigation workflow with explicit time pressure. A clicked phishing link with credential input requires immediate parallel investigation: the email analysis continues, but simultaneously you are checking for signs of account compromise (new MFA device, impossible travel, inbox rule creation) and you have a hard timer. Most attackers using credential-harvesting pages move quickly once credentials arrive; the window between phish submission and account takeover is often measured in minutes to a few hours. Forty-five minutes of careful email header analysis while an attacker is actively using stolen credentials is forty-five minutes wasted.

Email headers contain the full authentication and routing record for a message. Reading them correctly requires understanding the layered structure: the From header that the user sees is often not the actual sending infrastructure, and the actual sending infrastructure is what the authentication results evaluate. Start by extracting the full message headers (in Outlook: File > Properties > Internet Headers; in Gmail: three dots > Show Original; in Threat Explorer: the raw message view).

The From header is controlled entirely by the sender and is trivially spoofed. What matters is the Return-Path (the address bounces go to, usually the actual sending domain), the Received chain (the relay path from originating server to destination), and the originating IP in the first Received header that is outside your own infrastructure. Resolve this IP to understand the sending organization: legitimate corporate email comes from on-premises mail servers or known cloud providers (Microsoft 365, Google Workspace, Proofpoint, Mimecast). Phishing frequently originates from compromised legitimate domains (look for mismatches between the From domain and the originating infrastructure) or from hosting providers commonly associated with bulk sending.

SPF, DKIM, and DMARC results are in the Authentication-Results header added by your receiving mail infrastructure. SPF pass means the sending IP is authorized by the From domain's SPF record. SPF fail or softfail means it is not, which is a strong phishing indicator. DKIM pass means the message body and headers were cryptographically signed by a key published in the sending domain's DNS, confirming the message was not modified in transit and was sent by infrastructure that controls the signing key. DMARC pass requires SPF or DKIM to pass with alignment (the authenticated domain must match the From header domain). A message where SPF passes but DKIM fails, or where both pass but DMARC fails due to alignment mismatch, warrants deeper examination.

Look at the Reply-To header separately from the From header. Attackers frequently use a legitimate-appearing From domain (which may pass SPF if the domain is compromised, or be spoofed with a lookalike) while setting Reply-To to their actual mailbox. This means replies from victims go to the attacker even though the initial message appears to come from a trusted source. This pattern is common in business email compromise (BEC) attacks impersonating executives.

URL analysis is where many SOC analysts take unnecessary risk. Never click a suspicious URL from your work machine or any machine connected to your corporate network. The destination may serve browser exploits, initiate drive-by downloads, or fingerprint your system and IP address. Analysis happens through safe tools that create distance between you and the destination.

The first tier of URL analysis is passive: submit the URL to VirusTotal (virustotal.com), URLscan.io, and check the domain against threat intelligence feeds. VirusTotal aggregates verdicts from dozens of URL reputation and anti-malware services and flags known-malicious domains. URLscan.io performs a passive screenshot and DOM capture of the destination page in an isolated environment and shows you what the page actually looks like, any embedded URLs or redirect chains, the page technology, and network requests made on load. URLscan.io is particularly useful for credential harvesting pages because you can see the login form without submitting anything.

For URLs that are not detected by passive tools but remain suspicious, detonate in a dynamic sandbox. ANY.RUN provides an interactive sandbox with visual session replay. Hybrid Analysis (VXunderground's cloud sandbox) runs automated analysis. Joe Sandbox provides detailed behavioral reports. Upload the URL (not the email file) and observe: does it redirect through multiple hops, does it serve content only to specific geolocations or browser types (evasion), does it deploy any in-browser credential harvesting, does it initiate a download? Modern phishing infrastructure often uses cloaking: it serves a benign page to analysis IPs and sandbox environments, and the actual phishing page to real users. If a sandbox returns benign but the email context is strongly suspicious, try detonating through a residential IP proxy or with a user-agent that matches the targeted users.

For redirect chains, trace every hop. Phishing links frequently route through legitimate URL shorteners (bit.ly, tinyurl), legitimate click-tracking infrastructure from compromised mass-email platforms, and open redirectors on trusted domains (Google, Bing, LinkedIn all have documented open redirector patterns). The final destination after all redirects is what matters for the verdict. URLscan.io's scan results show the full redirect chain.

Attachment analysis follows a similar tiered approach to URL analysis: start passive (hash lookup), escalate to dynamic (sandbox detonation) if needed. Never open a suspicious attachment on your work machine or any machine connected to your corporate network.

Hash the suspicious attachment (SHA-256) and look it up in VirusTotal and your threat intelligence platform. If the hash matches a known malicious file, you have your verdict quickly. If it is clean but suspicious, submit the file to VirusTotal for fresh analysis (this will share the file with VirusTotal and its partners; consider a sandboxed environment with no external submission for sensitive incidents). For Office documents (DOCX, XLSX, PPTX, DOC, XLS) suspected of containing macros, use olevba (from the oletools Python package) or DidierStevens' oledump to extract and examine macro code without executing it. Malicious macros commonly contain base64-encoded payloads, PowerShell download-and-execute chains, or WMI execution sequences that are visible in the extracted VBA code.

For PDF attachments, extract embedded JavaScript using peepdf or pdfid. Malicious PDFs often contain JavaScript that exploits the PDF reader or launches embedded executables. PDFs can also contain embedded URLs that bypass email URL scanning by wrapping the destination in a PDF action rather than a visible link. Use pdfid to identify unusual features (JavaScript presence, embedded files, URI actions, OpenAction triggers).

For executables, LNK files, and ISO images (increasingly common delivery mechanisms for bypassing Mark of the Web protections), detonate in a full sandbox with network simulation enabled. Observe process creation chains, file system writes, registry modifications, and network connections. A malicious executable will typically write persistence (registry run key, scheduled task, startup folder entry), make a C2 connection, and potentially download secondary payloads. Capture the IOCs (C2 IPs and domains, file hashes of dropped payloads, registry keys created) for the follow-on sweep.

Microsoft 365 provides three primary investigation tools for email security analysis, and using them in sequence gives you a complete picture of a phishing campaign's reach within your tenant.

Threat Explorer (in the Microsoft Defender portal under Email & Collaboration > Explorer) provides a searchable view of all email processed by Exchange Online Protection and Defender for Office 365. Filter by sender address, sender IP, subject line, URL (use the URL Clicks tab to see if anyone clicked a link in the message), or attachment hash. The 'All email' view shows both delivered and quarantined messages. For a phishing investigation, search by the sender address and delivery time range to find every instance of the campaign that entered your tenant. Switch to the 'User Reported' view to see what the reporting user's submission looked like versus the automated analysis verdict.

Message Trace (in the Exchange Admin Center or via the Microsoft Defender portal) provides delivery status for specific messages. Use it to determine whether a specific message was delivered to specific recipients, quarantined, or rejected. Message Trace is more reliable than Threat Explorer for confirming delivery status to individual mailboxes and for identifying delivery to distribution groups (where Threat Explorer may not expand all members). For high-volume sweeps, use the PowerShell Exchange Online cmdlet Get-MessageTrace with appropriate filters rather than the GUI.

Content Search (in the Microsoft Purview compliance portal) allows you to search mailbox content across all mailboxes in the tenant. Use it to find every mailbox that still contains the phishing message after initial delivery. Search by subject, sender, and date range, then refine with keywords that appear in the message body or URL. Content Search results are used to scope the message purge action. Before purging, export the search results to document the scope. Use New-ComplianceSearchAction with Purge -PurgeType SoftDelete for initial remediation (messages go to Recoverable Items and can be restored), or HardDelete for permanent removal when you are certain of scope and do not need recovery options.

Google Workspace investigations follow a similar flow but use Google-native tooling. The primary investigation surfaces are the Admin Console Gmail Log Search, the Alert Center, and the Google Vault for preservation and eDiscovery.

Gmail Log Search is accessible in the Admin Console under Reports > Email Log Search. You can search by sender, recipient, subject, message ID, and date range. The search results show the delivery status (delivered, quarantined, rejected), the routing path, and whether any Gmail security filters applied. For a phishing investigation, search by the sender address and date range to find all messages from the campaign that entered your Workspace tenant. Note whether the messages were delivered to spam or inbox; spam delivery means users likely still saw the message. The 'Details' view for each message shows the full message path and any applied security policies.

The Alert Center (Admin Console > Security > Alert Center) shows automated security alerts generated by Google's security systems, including phishing reclassification alerts, suspicious login alerts, and user-reported phishing events. Check here first when beginning an investigation to see if Google's systems have already identified a threat. The phishing reclassification alerts are particularly useful: if Google's backend analysis determines a message was phishing after delivery, the alert appears here, and you can trigger retroactive message reclassification directly from the alert.

For sweeping and remediating messages, Google Workspace admins can use the Admin Console's Email quarantine (under Apps > Google Workspace > Gmail > Compliance) to delete messages from user mailboxes using the 'Delete From View' action in the quarantine interface. For large-scale remediation, the Gmail API's users.messages.trash and users.messages.delete methods allow programmatic remediation across all mailboxes. Unlike Microsoft 365, Google does not have a single command-line purge tool equivalent to New-ComplianceSearchAction; large-scale remediation either requires the API or a SIEM integration with remediation action capabilities.

If the reporting user clicked a link and potentially submitted credentials, the following indicators must be checked immediately and in parallel with the email analysis. Do not wait for the email verdict to check these; the timeline between credential submission and account takeover can be measured in minutes.

Impossible travel is the classic indicator: sign-in from a geographic location that is physically impossible given the user's prior sign-in location and the time elapsed. In Microsoft 365, check Azure AD Sign-in logs (Azure Active Directory > Sign-ins) filtered to the affected user. Look for sign-ins from countries the user does not operate in, or sign-in location sequences that would require faster-than-possible travel. Both Microsoft's own risk detection and third-party UEBA platforms will flag impossible travel, but checking manually during an active investigation is faster than waiting for an automated alert.

New MFA device enrollment is a high-confidence compromise indicator. After stealing credentials, attackers immediately enroll their own authenticator device to maintain access even after the victim's password is changed. In Azure AD, check the user's Authentication Methods (Azure AD > Users > [user] > Authentication Methods) and review the registration history for any new devices enrolled recently. In Google Workspace, check the user's security settings for new 2-step verification devices. An MFA device enrolled within minutes to hours of the phishing email delivery is a near-certain indicator of account takeover.

Inbox rule creation is a standard attacker persistence and evasion technique: after taking over an account, the attacker creates inbox rules to delete incoming security alerts, hide replies to messages they are sending on the victim's behalf, or forward all incoming email to an external address. In Microsoft 365, query the Unified Audit Log for Set-InboxRule and New-InboxRule operations by the affected user. In Google Workspace, review the user's filters and forwarding rules under Gmail settings. An inbox rule that deletes or hides security notifications or forwards mail externally created after the phishing delivery date is conclusive evidence of compromise.

After establishing the phishing email's characteristics (sender, subject, URL domain, attachment hash), execute a tenant-wide sweep to find every other user who received the same campaign. The goal is to identify additional recipients who may have clicked before the message was quarantined or before the first report arrived. A sweep that identifies 40 recipients of the same campaign, three of whom clicked, changes the scope from a single-user investigation to a potential multi-user incident.

Design your sweep query to match the campaign at the right level of specificity. Too specific (exact subject match only) will miss messages where the attacker slightly varied the subject. Too broad (sender domain only) will flood you with results from a compromised but high-volume legitimate domain. Layer the search: start with the combination of sender IP or ASN and the URL destination domain, since these are harder to vary than subject lines or display names. If the campaign used a URL shortener or click-tracker, search on the unwrapped destination URL domain rather than the shortened URL.

For Microsoft 365, run the Content Search or Threat Explorer query for all mailboxes over the time range from the campaign's first known delivery to the current time. Export results to identify every recipient and delivery status. For any mailbox where the message was delivered (not quarantined), check that user's activity for click events (Threat Explorer URL Clicks tab) and sign-in anomalies. For Google Workspace, Gmail Log Search can query across all users; supplement with Alert Center for Google's automated phishing detection across the same time range.

Document your sweep methodology and results before taking any remediation action. The documentation serves two purposes: it establishes the scope of the incident for the IR record and any regulatory reporting, and it provides the search parameters for the subsequent purge action so you can verify that purge completed successfully by re-running the same search afterward.

Remediation for a phishing investigation has three components: removing the malicious message from mailboxes, resetting credentials for affected users, and revoking active sessions to force reauthentication with clean credentials. The sequence matters: revoke sessions before resetting passwords, because an attacker with an active session can change the password back before your reset completes in some edge cases. Reset passwords before relying on new credentials for any communication about the incident.

For Microsoft 365 message purge, New-ComplianceSearchAction with PurgeType SoftDelete moves matching messages to the user's Recoverable Items folder, where they can be recovered if needed. HardDelete permanently removes them. Use SoftDelete for the initial purge to preserve recovery options, and document the content search name and result count before and after purging to verify effectiveness. Verify the purge completed successfully by re-running the content search; it should return zero results.

Revoke active sessions for all users who clicked the phishing link or show other indicators of compromise. In Microsoft 365, use Revoke-AzureADUserAllRefreshToken for the affected user account, or in the new Entra ID portal use the 'Revoke sessions' action on the user object. This forces reauthentication on all devices and applications. Follow with a conditional access check to ensure the user's reauthentication will require MFA. In Google Workspace, 'Sign out all web sessions' in the Admin Console revokes all active Google sessions for the user. If the user enrolled a new MFA device during the compromise window, remove that device from their Authentication Methods before forcing reauthentication, or the attacker will simply reauthenticate using the device they enrolled.

Clear case closure criteria prevent two failure modes: closing cases that should be escalated to incident response, and keeping cases open indefinitely because closure criteria are vague. Define your criteria explicitly and check each one before closing.

Close the case as phishing (no compromise) when: the message was not clicked by any recipient, or the only interaction was opening the message without clicking links or downloading attachments; the tenant sweep confirms no other users were affected with clicked indicators; there are no authentication anomalies for any users who received the message; the message has been purged from all mailboxes; and the sending infrastructure, URL, and any attachments have been submitted as indicators to your threat intelligence platform for future detection.

Escalate to incident response when any of the following are true: a user submitted credentials to the phishing page, confirmed by proxy logs, user report, or site analytics from a URL that captured submissions; signs of account takeover are present (new MFA device, impossible travel, inbox rules, external mail forwarding); lateral movement indicators are present in EDR or authentication logs for the affected user's session; more than one user was compromised; or the phishing campaign is specifically targeting your organization (personalized lure, internal information used in the email body, executive impersonation with targeted recipient list).

Documentation before case closure must include: the original email with full headers preserved (do not just close the ticket; export the headers), the analysis verdict for each URL and attachment, the sweep query and result count, the list of affected users and their interaction status, the remediation actions taken with timestamps, and any IOCs extracted for your threat intelligence platform. This documentation supports retrospective analysis, regulatory inquiries, and pattern recognition across multiple phishing cases.