In this module

AD2.10 Investigating a Reported Phishing Email

5-6 hours · Module 2 · Free

Operational Objective

A user reports a phishing email. Now what? You need to determine three things within 15 minutes: Is this real phishing or a false alarm? Did anyone else receive the same email? Did anyone click the link or open the attachment? This subsection teaches the investigation procedure using message trace and the Defender portal — the tools available in E3 without Threat Explorer. You'll trace the email from delivery to every recipient's mailbox, check Safe Links click data for link clicks, and correlate with sign-in logs if credentials may have been compromised.

Deliverable: A repeatable phishing investigation procedure that takes you from report to containment in under 15 minutes — identifying all affected users, checking for credential compromise, and remediating across all mailboxes.

Estimated completion: 30 minutes

Figure AD2.10 — The 15-minute phishing investigation procedure. Classify (is it real?), Scope (who else got it?), Impact (did anyone click?), Contain (remove + block + reset), Close (document + notify + submit). This procedure works with E3 tools — no Threat Explorer required.

Step 1: Classify (minutes 0-3)

Open the reported email from the Submissions page or the admin reporting mailbox. Check three things.

The sender. Is the FROM address spoofing a known domain, using a lookalike domain, or coming from a free email provider (Gmail, Outlook.com, Yahoo) with a display name that matches someone internal? Copy the sender address — you'll need it for the scope search.

The URL. If the email contains a link, hover over it (don't click). Does the URL domain match the claimed sender? Does it use a legitimate service as a redirect (Google Docs, SharePoint, OneDrive)? Is the domain newly registered or suspicious? If the URL is already rewritten by Safe Links, the original URL is embedded in the safelinks parameters.

Microsoft's verdict. In the Submissions page, Microsoft's automated analysis provides a verdict. If the verdict says "Phishing," trust it — Microsoft's classification is based on global threat intelligence. If the verdict says "Not a threat" but you're not convinced, proceed with the investigation anyway — automated systems aren't perfect.

If the email is clearly not phishing (a legitimate newsletter, a marketing email, or internal email that looked suspicious to the user), classify it as a false positive, thank the user for reporting, and close. If it IS phishing, continue.

Step 2: Scope (minutes 3-7)

Determine how many users received the same email. Navigate to the Exchange admin center → Mail flow → Message trace. Search by sender address with the time range covering the delivery window.

In PowerShell for faster results:

Get-MessageTrace -SenderAddress "attacker@phishing-domain.com" -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
    Select-Object Received, SenderAddress, RecipientAddress, Subject, Status |
    Format-Table -AutoSize

Count the results. "Delivered" status means the email reached the inbox. "FilteredAsSpam" means EOP or Safe Attachments caught it. "Failed" means it was blocked. Focus on the "Delivered" entries — those users have the phishing email in their inbox right now.

If the phishing was sent to many users (10+), check whether it was a targeted campaign against specific roles (finance, HR, executives) or a mass spray against your entire organization. This affects the urgency and the notification approach.

Worked example: investigating a credential phishing email

Here's a complete worked investigation using NE's environment.

09:15 — Report received. User a.patel reports a suspicious email via the Report Message button. The email subject is "Important: Verify Your Microsoft 365 Account" from "Microsoft Security" <security-alert@m365-verify-account.com>. The email body asks the user to click a link to "verify their identity before account suspension."

09:16 — Classify. The sender domain (m365-verify-account.com) is not microsoft.com. The urgency language ("before account suspension") is a classic phishing tactic. Microsoft's automated verdict in the Submissions page confirms: Phishing. Classification: real phishing. Continue investigation.

09:18 — Scope. Run message trace:

Get-MessageTrace -SenderAddress "security-alert@m365-verify-account.com" `
    -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
    Select-Object Received, RecipientAddress, Status | Format-Table

Result: 12 users received the email. 9 show "Delivered" status. 3 show "FilteredAsSpam" (EOP caught these but not the other 9). This is a targeted campaign hitting your organization.

09:21 — Impact. Check Safe Links URL trace for the phishing URL. Navigate to security.microsoft.com → Reports → URL protection report. Search for the domain "m365-verify-account.com." Result: 2 clicks recorded. User r.williams clicked at 09:02 — Safe Links blocked (warning page shown). User m.thompson clicked at 08:47 — Safe Links allowed (the URL was clean at 08:47, the phishing page activated at 08:55).

m.thompson clicked before Safe Links classified the URL. Check the sign-in log:

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'm.thompson@northgateeng.com'" -Top 10 |
    Where-Object { $_.CreatedDateTime -gt (Get-Date).AddHours(-3) } |
    Select-Object CreatedDateTime, IpAddress, @{N="Location";E={$_.Location.City}},
        @{N="Status";E={$_.Status.ErrorCode}} | Format-Table

Result: sign-in at 08:49 from IP 198.51.100.77 (not NE's office IP), location: unknown. Status: 0 (success). MFA: satisfied by claim. This is an AiTM token replay. m.thompson's account is compromised.

09:23 — Contain. Execute the AD1.9 procedure for m.thompson: revoke sessions, reset password, check MFA methods, check inbox rules. Then purge the phishing email from all 9 remaining inboxes:

$search = New-ComplianceSearch -Name "Phish-Cleanup-$(Get-Date -Format 'yyyyMMdd-HHmm')" `
    -ExchangeLocation All `
    -ContentMatchQuery 'from:"security-alert@m365-verify-account.com" AND subject:"Verify Your Microsoft 365 Account"'
Start-ComplianceSearch -Identity $search.Name
# Wait for completion, then:
New-ComplianceSearchAction -SearchName $search.Name -Purge -PurgeType SoftDelete

Block the sender domain: security.microsoft.com → Tenant Allow/Block Lists → URLs → add "m365-verify-account.com."

09:28 — Close. Document: 12 recipients, 9 delivered, 2 clicked, 1 compromised (m.thompson — contained in 5 minutes), phishing email purged from all mailboxes, sender domain blocked. Total investigation time: 13 minutes.

Step 3: Impact (minutes 7-10)

Did anyone click the link? Navigate to security.microsoft.com → Email & collaboration → URL trace (or Reports → URL protection report). Search for the phishing URL. If any users clicked the link, the URL trace shows who, when, and whether Safe Links blocked the click or allowed it.

For each user who clicked, check the sign-in log immediately. Navigate to entra.microsoft.com → Monitoring → Sign-in logs → filter by the user's UPN. Look for sign-ins from unusual IPs or locations within minutes of the click. A sign-in from an unfamiliar IP after a phishing click is a confirmed credential compromise — execute the 15-minute compromised account procedure from Module AD1.9.

If Safe Links blocked the click, the user reached the warning page but never saw the phishing site — no credentials were entered. These users are safe but should still be notified that they clicked a phishing link and were protected by Safe Links.

Step 4: Contain (minutes 10-13)

Remove the phishing email from all mailboxes that received it. If you have E5 with Threat Explorer, use the "Trigger investigation" or "Take actions" feature to purge the email from all recipients. With E3, use PowerShell:

# Find and soft-delete the phishing email from all mailboxes
$searchName = "Phishing-Cleanup-$(Get-Date -Format 'yyyyMMdd-HHmm')"
New-ComplianceSearch -Name $searchName -ExchangeLocation All `
    -ContentMatchQuery "from:attacker@phishing-domain.com AND subject:'Verify Your Account'" |
    Start-ComplianceSearch

# Wait for search to complete, then purge
New-ComplianceSearchAction -SearchName $searchName -Purge -PurgeType SoftDelete

Block the sender and URL. Navigate to security.microsoft.com → Policies & rules → Threat policies → Tenant Allow/Block Lists. Add the sender domain and the phishing URL to the block list. This prevents any future emails from the same source.

For any users who clicked AND have sign-ins from unusual IPs: execute the compromised account procedure immediately — revoke sessions, reset password, check MFA methods, check inbox rules.

Step 5: Close (minutes 13-15)

Document the incident: sender address, subject line, number of recipients, number of clicks, number of compromised accounts, remediation actions taken. Submit the phishing email to Microsoft via the Submissions page (if not already submitted by the user report) to improve global filtering.

Notify affected users. For users who received the email but didn't click: "A phishing email was sent to your mailbox. We've removed it. No action needed from you." For users who clicked but Safe Links blocked: "You clicked a phishing link, but our email protection blocked the malicious page. Please be cautious with unexpected emails requesting you to sign in." For users whose accounts were compromised: handle individually with the AD1.9 procedure.

Compliance Myth: "If nobody clicked the link, there's no incident to investigate"

The phishing email itself is the incident — regardless of whether anyone clicked. It tells you: your email filters missed this specific campaign (investigate why and adjust), the attacker has your users' email addresses (how?), and the same campaign may return with a different subject or URL (add the sender domain to the block list). Investigating "no-click" phishing emails improves your defenses for the next campaign. Ignoring them because nobody clicked means the same gap exists for the next email — which might arrive when your most click-prone user is having a distracted afternoon.

Decision point

Your investigation reveals that a phishing email was sent to 45 users. Message trace shows 38 were delivered to inboxes and 7 were caught by EOP. URL trace shows 4 users clicked the link — Safe Links blocked 3 of the 4, but 1 user clicked before Safe Links classified the URL. The sign-in log shows a successful sign-in from an unusual IP for the 1 user who wasn't blocked, occurring 2 minutes after the click. What's your priority action sequence?

Option A: Remove the email from all 38 inboxes first, then handle the compromised account.

Option B: Contain the compromised account immediately (revoke sessions, reset password), then remove the email from remaining inboxes.

The correct answer is Option B. The compromised account is an active threat — the attacker may be reading email, creating inbox rules, or moving laterally right now. Contain first (2 minutes to revoke sessions and reset password), then remove the email from the other 37 inboxes (5 minutes with Compliance Search). The email in the other inboxes is a latent threat — users might still click — but the active compromise takes priority. After containment, remove the emails and block the sender/URL.

Try it: Practice the investigation procedure

Practice this procedure using a real (non-malicious) email as a stand-in. Pick any external email you received this week.

1. Classify: Check the sender address, any URLs (hover, don't click), and the content. 2. Scope: Run a message trace for the sender address in the Exchange admin center. How many users received email from this sender in the last 7 days? 3. Impact: Check the URL trace (if the email had links) — were any clicks logged? 4. Contain (simulated): Draft the Compliance Search query you would use to find and remove this email from all mailboxes. Don't execute it — just write the query. 5. Close: Write a 3-sentence incident summary: what happened, how many affected, what actions taken.

Running through this with a benign email builds muscle memory. When a real phishing report comes in at 16:55 on a Friday, you execute the procedure from memory instead of searching for documentation.

You're investigating a phishing email using message trace. The trace shows 25 recipients with "Delivered" status. You remove the email from all 25 mailboxes using Compliance Search. The next morning, 3 users report they "already read and deleted" the phishing email before your remediation. Should you be concerned?

Yes — "read" means they may have clicked the link. Check URL trace for clicks from these 3 users, and check their sign-in logs for unusual activity after the time they read the email — Correct. "Read and deleted" doesn't mean safe. If the email contained a link and they clicked it, credentials may have been entered. If it contained an attachment and they opened it, malware may have executed. "I read it and deleted it" is reassuring to the user but not to you — investigate the 3 users the same way you'd investigate any other recipient who interacted with the email.

No — they deleted the email themselves, so the threat is eliminated — No. Deleting the email removes the message but doesn't undo any actions the user took — clicking a link, entering credentials, opening an attachment. The threat isn't the email sitting in the mailbox. The threat is what the user did when they read it.

Only if the email had an attachment — links can't cause harm if the user didn't enter credentials — Incorrect. Phishing links can trigger drive-by downloads, redirect to malware sites, or capture session tokens without the user entering credentials (browser exploits). Any click on a phishing link warrants investigation.

Only if the email had a link — if it was a BEC text-only email requesting a wire transfer, reading it didn't cause technical harm — Partially correct for BEC specifically, but you still need to check whether the user acted on the request. A BEC email requesting a payment change is harmful if the finance clerk processed the payment — the harm is financial, not technical.

Operational Artifact — Phishing Investigation Procedure Card

Print this 5-step procedure and keep it with your compromised account response card from Module AD1. When a phishing report comes in: Classify (3 min — real or false?), Scope (4 min — message trace for all recipients), Impact (3 min — URL trace for clicks + sign-in logs for clickers), Contain (3 min — Compliance Search purge + block sender/URL + AD1.9 for compromised accounts), Close (2 min — document + notify + submit to Microsoft). Total: 15 minutes. The procedure works with E3 tools — no Threat Explorer or P2 features required.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus

← Previous Next →