A reported phishing email raises two questions: is it malicious, and what happened because of it. The first is analysis. The second is where most of the response work is.

Preserve -> verdict -> scope recipients and clicks -> user interaction -> contain -> document

For detailed header, authentication, URL, QR code, and attachment analysis, see the Email Analysis Investigation Guide. This note covers the response workflow around it.

Step 1: Preserve the email

  • Don’t click links or open attachments, including from the reporting user’s mailbox.
  • Save the original as .eml or .msg. If the user reports it by forwarding, ask them to forward as an attachment: a normal forward drops the original headers.
  • Keep the full headers and record the message ID, sender, subject, and received time. You’ll need them to scope.
  • Hash any attachments before anything else touches them.

Step 2: Reach a verdict

Work through the analysis guide, or use this quick pass:

Check Look for
Sender Display-name spoofing (“Microsoft Support” from an unrelated domain), lookalike domains, From vs. Return-Path mismatch
Authentication DMARC failure against the From domain, especially with p=reject. SPF or DKIM passing for an unrelated domain doesn’t make it legitimate
URLs Mismatch between displayed and real link, shorteners, encoded redirects, the recipient’s address embedded in the URL
Attachments Real file type vs. extension; HTML, LNK, ISO/IMG, SVG, and OneNote files; archives with executables inside
Sender domain Registered in the last 30 days, bad reputation, lookalike of a brand or partner

Header tools: MXToolbox header analyzer and the Google Admin Toolbox message header analyzer.

URL and file reputation: VirusTotal, URLScan.io, Hybrid Analysis, Any.Run, Joe Sandbox, and Google Safe Browsing.

A note on attachments

Office blocks macros in files downloaded from the internet by default, so macro documents are no longer the most common payload. Current phishing favors:

  • HTML attachments that render a fake login page locally or smuggle a payload
  • LNK files inside ZIP, ISO, or IMG containers
  • PDFs and SVGs that only carry a link
  • QR codes that move the link out of scannable text

Macro documents still show up. When they do, extract the code with oletools:

olevba suspicious.docm

and look for Shell, powershell, cmd.exe, WScript, CreateObject, and auto-run functions like AutoOpen or Document_Open.

Step 3: Scope the campaign

One report rarely means one recipient.

  • Who else received it? Run a message trace by sender, subject, sending IP, URL, and attachment hash. Campaigns often vary the subject and sender, so trace on the URL and attachment too.
  • Who clicked? Check URL-click logs from the email security platform, proxy and DNS logs for the domain, and browser history on the affected endpoints.
  • Is it still arriving? Check the last few hours for new variants from the same infrastructure.

Then remove the message from every mailbox it reached (search and purge), not just the reporter’s.

Step 4: Check what the user did

Treat these as three separate questions. Each changes the response.

Did they click?

  • URL-click logs, proxy logs, and DNS queries for the phishing domain
  • Browser history on the endpoint, which also shows what the page led to: see Browser History for Initial Access

Did they run anything?

  • EDR or Sysmon process telemetry: children of the mail client, browser, or explorer.exe right after the click or download (script interpreters, mshta, rundll32, installers)
  • Files created in Downloads, Temp, or AppData around that time
  • Windows event 4688 helps only if process-creation auditing is enabled

Did they enter credentials?

TLS hides form submissions from most firewall and proxy logs, so look at the identity side instead:

  • sign-ins shortly after the click from a new IP, country, ASN, or device
  • MFA prompts the user didn’t expect, especially approvals, and newly registered MFA methods
  • new inbox rules, mail forwarding, or mailbox access from new IPs
  • OAuth application consents granted around the time of the click

Phishing kits that proxy the real login page capture the session, not just the password, so a sign-in from attacker infrastructure can succeed even with MFA in place.

Step 5: Contain based on what happened

What happened Response
Delivered, no interaction Purge from all mailboxes; block the sender address and phishing URLs; add indicators to detection
Clicked, no credentials or execution The above, plus confirm with the user and watch identity logs for the next few days
Entered credentials Reset the password and revoke sessions and refresh tokens; review MFA methods, inbox rules, forwarding, and OAuth consents; enforce MFA if it isn’t already
Ran an attachment or download Isolate the endpoint, investigate the process tree and persistence, remove payloads, and treat credentials as exposed

A password reset on its own doesn’t end sessions the attacker already has. Revoke them.

Block the specific sender address rather than the whole domain when the sender is a compromised legitimate partner. Blocking their domain stops legitimate business mail; notify them instead.

Step 6: Document and close

Record:

  • the verdict and the evidence that carried it
  • every recipient, who clicked, and who interacted further
  • indicators: sender, sending IP, URLs, domains, attachment hashes
  • response actions taken, and anything not observed (for example, “no credential use seen in sign-in logs”)

Summary

Step Action Tools
Preserve Save as .eml / .msg with full headers, hash attachments Email client, forward-as-attachment
Verdict Sender, authentication, URLs, attachments, domain Header analyzers, VirusTotal, URLScan.io, sandboxes, CyberChef
Scope Find all recipients and clickers, purge the message Message trace, URL-click logs, proxy and DNS logs
User interaction Clicks, execution, credential use Browser history, EDR process telemetry, identity sign-in logs
Contain Purge, block, reset and revoke, isolate as needed Email platform, identity provider, EDR
Document Verdict, scope, indicators, actions Case notes