In this module
AD6.3 Phishing Click Response
Figure AD6.3 — Phishing click response decision tree. If Safe Links blocked the click, the impact is minimal — thank the user, check scope, block the sender. If the click reached the phishing page, treat the user as compromised — execute AD6.2 and scope other recipients.
Step 1: Determine click outcome
Check whether Safe Links blocked the click or the user reached the phishing page. Navigate to security.microsoft.com → Email & collaboration → Explorer (or Threat Explorer if available). Search for the email by sender, subject, or recipient.
The email details show: delivery action (Delivered, Blocked, ZAP'd), URL click details (Blocked by Safe Links, Allowed, Pending verdict), and the timeline of events.
Alternatively, check the Safe Links URL trace:
Connect-ExchangeOnline
# Check URL clicks for a specific user in the last 7 days
Get-UrlTrace -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) |
Where-Object { $_.UserId -eq "r.williams@northgateeng.com" } |
Select-Object ClickTime, Url, UrlVerdict, IsClickedThrough | Format-TableIf IsClickedThrough is False and UrlVerdict is "Blocked," Safe Links caught it — the user saw a warning page and didn't reach the phishing site. If IsClickedThrough is True or the verdict is "Allowed" (URL was clean at click time but later reclassified), the user reached the phishing page.
Step 2: Scope the campaign
One phishing email usually means many. Check how many users received the same email:
# Find all recipients of the phishing email
$senderAddress = "support-verify@ms-account-check.com"
Get-MessageTrace -SenderAddress $senderAddress -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) |
Select-Object Received, SenderAddress, RecipientAddress, Subject, Status |
Format-Table -AutoSizeThis shows every user who received emails from the phishing sender. For each recipient, check whether they clicked the URL. If 15 users received the email but only 1 clicked, the scope is limited. If 15 users received it and 5 clicked, you have 5 potential compromises to investigate.
Step 3: Respond based on outcome
If Safe Links blocked the click (most common):
- Thank the user for reporting — positive reinforcement encourages future reporting
- Block the sender domain in Exchange admin: navigate to security.microsoft.com → Policies & rules → Threat policies → Anti-spam → Tenant Allow/Block List → Block → add the sender domain
- Submit the email to Microsoft: security.microsoft.com → Email & collaboration → Submissions → "Submit to Microsoft for analysis" → Phishing
- Check whether other recipients clicked — if any clicks reached the phishing page, those users need the compromised account procedure
- Close the incident — classify as TP (the phishing email was real, Safe Links blocked the impact)
If the user reached the phishing page:
Determine the page type:
- Credential harvester (fake login page): The user likely entered their username and password. Treat as credential compromise → execute AD6.2 immediately. Check the sign-in log for post-click sign-ins from unfamiliar IPs.
- AiTM proxy (real login page proxied through attacker infrastructure): The user completed a real sign-in through the proxy, and the attacker captured the session token. Execute AD6.2 with special attention to MFA-satisfied-by-claim sign-ins.
- Malware download: The page attempted to download a file. Check whether the file was blocked by Defender SmartScreen or actually downloaded. If downloaded, check for endpoint alerts in the Defender portal.
For credential harvester and AiTM scenarios, the sign-in log is your primary investigation tool. After the phishing click timestamp, look for sign-ins from unfamiliar IPs with "MFA: satisfied by claim" — this confirms the attacker captured and replayed the session.
Connect-MgGraph -Scopes "AuditLog.Read.All"
$user = "r.williams@northgateeng.com"
$clickTime = "2026-04-13T14:00:00Z" # approximate time of the click
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$user' and createdDateTime ge $clickTime" -Top 50 |
Select-Object CreatedDateTime, @{N="IP";E={$_.IpAddress}},
@{N="Location";E={"$($_.Location.City), $($_.Location.CountryOrRegion)"}},
@{N="MFA";E={$_.MfaDetail.AuthMethod}},
@{N="Status";E={if($_.Status.ErrorCode -eq 0){"SUCCESS"}else{"BLOCKED"}}},
@{N="App";E={$_.AppDisplayName}} |
Format-Table -AutoSizeStep 4: Purge the phishing email
After scoping all recipients, remove the phishing email from all mailboxes it was delivered to. Use Compliance Search (E3) to find and purge:
Connect-IPPSSession
# Create a compliance search for the phishing email
New-ComplianceSearch -Name "Phishing-Purge-$(Get-Date -Format 'yyyyMMdd')" `
-ExchangeLocation All `
-ContentMatchQuery "from:support-verify@ms-account-check.com AND received>=2026-04-13"
# Start the search
Start-ComplianceSearch -Identity "Phishing-Purge-$(Get-Date -Format 'yyyyMMdd')"
# Check search results (wait for completion)
Get-ComplianceSearch -Identity "Phishing-Purge-$(Get-Date -Format 'yyyyMMdd')" |
Select-Object Name, Status, Items
# Purge (soft delete — moves to Recoverable Items)
New-ComplianceSearchAction -SearchName "Phishing-Purge-$(Get-Date -Format 'yyyyMMdd')" `
-Purge -PurgeType SoftDeleteThe purge removes the phishing email from every mailbox in the organization — including users who haven't opened it yet. This prevents additional clicks.
Important: Use SoftDelete (not HardDelete). SoftDelete moves the email to Recoverable Items where it can be recovered if needed for evidence. HardDelete permanently removes it — destroying potential evidence.
Communicating with the user who clicked
The user who reported the phishing click (or who you identified through URL trace) needs reassurance and guidance:
If Safe Links blocked it: "Thanks for reporting this — you did the right thing. The link you clicked was a phishing attempt, but our Safe Links protection blocked it before you reached the malicious page. Your account is safe. No action is needed on your part. Please continue to report any suspicious emails you receive."
If the click reached the page and you're resetting their password: "We've identified that the link you clicked was a phishing page that may have captured your login information. As a precaution, we've secured your account: your password has been reset and your sessions have been refreshed. I'll send you a temporary password via [Teams/phone] — please change it to a new password when you sign back in. You may also need to re-authenticate your Authenticator app. If you notice anything unusual in your mailbox (missing emails, emails you didn't send, unfamiliar rules), let me know immediately."
Keep the communication factual and non-blaming. The user who clicks a phishing link and reports it is doing you a favor — they're giving you early detection. If you make them feel stupid for clicking, they won't report next time.
After the purge: verifying clean-up
After the compliance search purge completes, verify the phishing email is removed:
# Check purge action status
Get-ComplianceSearchAction -Identity "Phishing-Purge-20260414_Purge" |
Select-Object Action, Status, Results | Format-ListThe "Results" field shows how many items were purged from how many mailboxes. If the count matches your scope (e.g., "15 items from 15 mailboxes"), the purge was complete. If the count is lower than expected, some emails may have been deleted by users, moved to another folder, or in a mailbox that the compliance search doesn't cover (shared mailboxes, if not included in the search scope).
User-reported phishing: the ideal detection path
The best phishing detection isn't technical — it's a user clicking the "Report Message" button in Outlook and saying "this looks suspicious." A user who reports phishing before clicking is the gold standard: the threat is identified, no credentials are exposed, and you can scope and purge before anyone else clicks.
When a user reports via the Report Message add-in, the report appears in security.microsoft.com → Email & collaboration → Submissions → User reported. Each submission shows: the email, the user's classification (Phishing, Junk, Not junk), and Microsoft's automated verdict.
Your workflow for user-reported phishing:
- Check Microsoft's verdict. If Microsoft agrees it's phishing, the email may already be ZAP'd from other inboxes. Verify with message trace.
- Check for other recipients. Same scoping procedure as above — who else got this email?
- Check for clicks. Did any recipient click the URL? Check URL trace for the phishing URL.
- Purge if still in mailboxes. If ZAP didn't catch it (URL was clean, or the email didn't match existing rules), purge manually via Compliance Search.
- Block the sender. Add to Tenant Block List.
- Thank the reporter. Send a brief reply: "Thank you for reporting this phishing email. We've verified it's malicious and removed it from all mailboxes. Your report helped protect the organization."
The thank-you message is operationally important. Users who receive positive feedback for reporting phishing report more frequently. Users whose reports go into a black hole stop reporting. A 30-second thank-you email builds a culture of security awareness that no amount of training can replicate.
Tracking phishing metrics for the quarterly report
Record each phishing event in your incident log with: date, sender, type (credential harvester / AiTM / malware), detection method (user report / Safe Links / EOP / ZAP), click outcome (blocked / reached page / no clicks), and number of recipients. After a quarter, summarize: "Q2: 12 phishing campaigns targeting NE. 47 emails total. 3 user clicks, all blocked by Safe Links. 4 phishing emails reported by users before any clicks. 100% of phishing emails purged within 24 hours of detection."
Three users in accounting received the same phishing email. User 1 reported it immediately (didn't click). User 2 clicked but Safe Links blocked it. User 3 clicked and reached the phishing page — the URL was clean when User 3 clicked (before Safe Links reclassified it). User 3 entered their credentials on the page. How do you prioritize?
Option A: Treat all three the same — reset all passwords to be safe.
Option B: Prioritise by risk: User 3 first — execute full AD6.2 procedure immediately (confirmed credential compromise). User 2 second — verify Safe Links actually blocked the click (no sign-in log anomalies), then close. User 1 third — thank them for reporting, no action needed. Then purge the email from all mailboxes and block the sender domain.
The correct answer is Option B. User 3 is confirmed compromised — immediate response. User 2 was protected by Safe Links — verify and close. User 1 did everything right — reinforce the good behavior. Treating all three the same wastes time on Users 1 and 2 while delaying the response to User 3, who is actually compromised.
param(
[string]$AffectedUser,
[string]$SenderAddress,
[string]$ClickDate
)
Write-Host "=== PHISHING CLICK RESPONSE ===" -ForegroundColor Cyan
Write-Host "Affected user: $AffectedUser"
Write-Host "Phishing sender: $SenderAddress"
Write-Host "Click date: $ClickDate"
# Step 1: Check click outcome
Write-Host "`n--- STEP 1: URL CLICK TRACE ---" -ForegroundColor Yellow
Connect-ExchangeOnline -ShowBanner:$false
Get-UrlTrace -StartDate (Get-Date $ClickDate).AddDays(-1) -EndDate (Get-Date) |
Where-Object { $_.UserId -eq $AffectedUser } | Format-Table
# Step 2: Scope recipients
Write-Host "`n--- STEP 2: OTHER RECIPIENTS ---" -ForegroundColor Yellow
Get-MessageTrace -SenderAddress $SenderAddress `
-StartDate (Get-Date $ClickDate).AddDays(-1) -EndDate (Get-Date) |
Select-Object RecipientAddress, Status | Format-Table
# Step 3: Check post-click sign-ins
Write-Host "`n--- STEP 3: POST-CLICK SIGN-INS ---" -ForegroundColor Yellow
Connect-MgGraph -Scopes "AuditLog.Read.All" -NoWelcome
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$AffectedUser' and createdDateTime ge $ClickDate" -Top 20 |
Select-Object CreatedDateTime, IpAddress, @{N="Status";E={$_.Status.ErrorCode}} | Format-Table
Write-Host "`n--- NEXT STEPS ---" -ForegroundColor Green
Write-Host "If click was BLOCKED: block sender, purge email, close"
Write-Host "If click REACHED page: execute AD6.2 compromised account procedure"Try it: Build the phishing response script
Create C:\SecurityScripts\Respond-PhishingClick.ps1 with the key investigation commands:
Test this script with a known-good email and user to verify the commands work. When a real phishing click is reported, run the script with the affected user's UPN and the sender address to get immediate investigation data.
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.