In this module

AD6.3 Phishing Click Response

5-6 hours · Module 6 · Free
Operational Objective
A user reports: "I clicked a link in an email and it looked suspicious." Or your Monday review shows a Safe Links block for a user who clicked a confirmed phishing URL. The user clicked — but what happened after the click? Did they enter credentials on the phishing page? Did the page download malware? Was the phishing page a credential harvester or an AiTM proxy? The phishing click response procedure determines the impact of the click, scopes other affected users, contains the damage, and prevents recurrence. This is the most frequent incident you'll handle — most phishing clicks are caught by Safe Links (the click is blocked and no damage occurs), but the ones that get through need a structured response.
Deliverable: A phishing click response procedure with scope assessment, impact determination, and containment actions — covering both "click blocked by Safe Links" and "click reached the phishing page" scenarios.
Estimated completion: 30 minutes
PHISHING CLICK — RESPONSE DECISION TREE USER CLICKED PHISHING LINK SAFE LINKS BLOCKED THE CLICK User saw warning page · didn't reach phishing site CLICK REACHED PHISHING PAGE User may have entered credentials 1. Thank the user for reporting 2. Check for other recipients → scope 3. Block sender domain → close 1. TREAT AS COMPROMISED (AD6.2) 2. Check sign-in log for post-click sign-ins 3. Scope + purge + block sender

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-Table

If 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 -AutoSize

This 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):

  1. Thank the user for reporting — positive reinforcement encourages future reporting
  2. 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
  3. Submit the email to Microsoft: security.microsoft.com → Email & collaboration → Submissions → "Submit to Microsoft for analysis" → Phishing
  4. Check whether other recipients clicked — if any clicks reached the phishing page, those users need the compromised account procedure
  5. 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 -AutoSize

Step 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 SoftDelete

The 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-List

The "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:

  1. Check Microsoft's verdict. If Microsoft agrees it's phishing, the email may already be ZAP'd from other inboxes. Verify with message trace.
  2. Check for other recipients. Same scoping procedure as above — who else got this email?
  3. Check for clicks. Did any recipient click the URL? Check URL trace for the phishing URL.
  4. 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.
  5. Block the sender. Add to Tenant Block List.
  6. 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."

Compliance Myth: "If Safe Links blocked the click, there's no incident — nothing happened"
Safe Links blocking a click IS a security event worth recording. The user's credentials are safe (they didn't enter them on the phishing page), but the phishing email reached the inbox and the user was deceived enough to click. Record it in your incident log: "Phishing email delivered, user clicked, Safe Links blocked. Sender domain blocked, email purged from all mailboxes." This data feeds your quarterly report (phishing campaigns targeting your organization) and your user awareness assessment (which users are clicking phishing links, and could they benefit from additional training). A blocked click is a near-miss, not a non-event.
Decision point

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.

A user reports clicking a link in an email at 14:30. Your investigation shows Safe Links allowed the click (URL was clean at 14:30). At 15:15, Microsoft reclassified the URL as phishing and ZAP removed the email from the inbox. The user may have entered credentials between 14:30 and 15:15. What's your response?
No action needed — ZAP removed the email — ZAP removes the email, not the damage from the click. The user potentially entered credentials 45 minutes ago.
Wait for a sign-in alert — if the attacker uses the credentials, Defender will alert — Waiting gives the attacker time to read emails, create forwarding rules, and establish persistence. Proactive investigation is faster than reactive alerting.
Treat as potential credential compromise: check the sign-in log for post-14:30 sign-ins from unfamiliar IPs. If any appear with "MFA satisfied by claim," execute AD6.2 immediately. If no suspicious sign-ins appear within 2 hours of the click, the user likely didn't enter credentials — close as contained but monitor for 48 hours — Correct. The 45-minute window between click and reclassification is the danger zone. The sign-in log tells you whether the attacker used any captured credentials. If yes, respond immediately. If no, the user may not have entered credentials (closed the page, recognized the phish, entered wrong credentials) — monitor but don't over-react.
Reset the password immediately as a precaution — If no sign-in anomalies exist, a precautionary reset disrupts the user unnecessarily. Check the sign-in log first to determine whether credentials were actually captured.

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