Agent Foskett Academy • SOC Analyst Academy • Module 5 • Lesson 43 • Email & Phishing: From Message to Compromise

Lesson 43 — The Link Was Clicked

The message was suspicious.

The sender domain did not match the organisation the user thought they were dealing with, and the URL inside the email pointed somewhere else entirely.

Then the user added one more detail:

“I clicked the link.”

The investigation had just changed. Agent Foskett was no longer asking only whether the email was malicious.

Now the SOC needed to determine what happened after the click.

A click is a transition point. Move from message evidence into user, browser and endpoint evidence.

Follow the Click Back to SOC Analyst Academy

Agent Foskett following a phishing URL click into endpoint evidence

The user clicked it

The email investigation now has to cross telemetry boundaries and answer what the user, browser and device did next.

✓ Preserve the phishing URL

✓ Confirm click evidence

✓ Identify the device

✓ Inspect post-click activity

Case briefing

PHISHING EMAIL Delivered to user ↓ SUSPICIOUS URL Identified in message telemetry ↓ USER REPORT "I clicked it." ↓ THE INVESTIGATION CHANGES Was the click recorded? Which account clicked? Which device was involved? What happened immediately afterwards? Did a browser create a file or process? Did the device contact suspicious infrastructure?

Investigation objective

Follow a suspicious email from message telemetry into URL-click and endpoint evidence, establish the post-click time window and determine whether the interaction led to additional activity.

Investigator's rule

“The user clicked” is not the end of the investigation. It is the timestamp around which the next investigation begins.

Stage 1 — preserve the URL from the message

123456789

let MessageId = "<NETWORK-MESSAGE-ID>";
EmailUrlInfo
| where NetworkMessageId == MessageId
| project Timestamp,
          NetworkMessageId,
          Url,
          UrlDomain
| order by Timestamp asc

Do not work from memory

Use the URL recorded in telemetry rather than asking the user to reopen the message or revisit the suspicious destination.

Preserve both URL and domain

The complete URL can help correlate a specific interaction, while the domain becomes a broader pivot for related activity.

Stage 2 — look for URL-click evidence

123456789101112

UrlClickEvents
| where Timestamp > ago(7d)
| where AccountUpn =~ "alex@contoso.com"
| where Url has "suspicious-example.com"
| project Timestamp,
          AccountUpn,
          Url,
          ActionType,
          Workload,
          NetworkMessageId
| order by Timestamp asc

Confirm what telemetry proves

A recorded URL-click event provides stronger evidence than a recollection alone. Capture the timestamp, account, URL, workload and message correlation available in the event.

ActionType needs interpretation

Review how the click was handled. Do not reduce every recorded click to the same outcome; the security control's action is part of the evidence.

Stage 3 — build the post-click window

10:02:14 Email delivered ↓ 10:07:31 Suspicious URL clicked ↓ INVESTIGATION WINDOW 10:02 ───────── 10:07 ───────── 10:22 ▲ CLICK Look several minutes before and after the click. WHY BEFORE? Establish baseline and initiating activity. WHY AFTER? Find browser, network, file and process evidence.

The timestamp is your anchor

Once the click time is established, use it to narrow endpoint investigation instead of searching an entire day of device activity.

Do not make the window too narrow

Redirects, downloads and user interaction may occur seconds or minutes after the initial click. Give the timeline enough room to reveal the chain.

Stage 4 — look for endpoint network activity

12345678910111213

let ClickTime = datetime(2026-09-01 10:07:31);
DeviceNetworkEvents
| where Timestamp between (ClickTime - 5m .. ClickTime + 15m)
| where DeviceName =~ "WS-FIN-021"
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          ActionType
| order by Timestamp asc

Look for the browser

Network activity initiated by Edge, Chrome or another browser around the click can help connect the email interaction with endpoint telemetry.

Expect redirects

The domain recorded in the email may not be the final destination. Follow nearby network events and preserve unexpected redirect domains as additional pivots.

Stage 5 — did the browser create or launch anything?

123456789101112

let ClickTime = datetime(2026-09-01 10:07:31);
DeviceProcessEvents
| where Timestamp between (ClickTime - 2m .. ClickTime + 15m)
| where DeviceName =~ "WS-FIN-021"
| project Timestamp,
          DeviceName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Browser child processes matter

A browser launching an unexpected interpreter, script host or executable can materially change the severity of the incident.

Normal activity matters too

If the evidence shows only ordinary browser activity, record that. The analyst's job is to establish what happened, not to force every click into a compromise narrative.

Stage 6 — check for files created after the click

123456789101112

let ClickTime = datetime(2026-09-01 10:07:31);
DeviceFileEvents
| where Timestamp between (ClickTime .. ClickTime + 15m)
| where DeviceName =~ "WS-FIN-021"
| project Timestamp,
          DeviceName,
          FileName,
          FolderPath,
          SHA256,
          InitiatingProcessFileName
| order by Timestamp asc

A click may become a download

If a file appears immediately after the browser interaction, preserve its name, path, hash and initiating process for further investigation.

No file does not mean no risk

Credential-phishing pages may never create a local payload. The absence of a downloaded file does not close the investigation.

Stage 7 — classify what happened after the click

Evidence after click	Likely investigation direction
Click recorded, access blocked	Validate control action and look for alternative interactions.
Browser reached suspicious domain	Inspect redirects and determine what content or action followed.
File created by browser	Pivot into file reputation, hash, execution and endpoint investigation.
Unexpected process launched	Investigate process tree and potential endpoint compromise.
No payload evidence	Consider credential theft or other browser-based interaction.
User reports entering credentials	Move immediately into identity investigation and response.

Stage 8 — build the evidence chain

EMAIL DELIVERED 10:02:14 ↓ URL CLICK 10:07:31 ↓ BROWSER NETWORK ACTIVITY 10:07:32+ ↓ REDIRECT / DESTINATION Investigate ↓ FILE OR PROCESS ACTIVITY? Investigate ↓ CREDENTIAL ENTRY? Ask + investigate identity telemetry ↓ SOC DECISION Email-only incident? Blocked interaction? Credential exposure? Endpoint compromise? Multiple investigation paths?

Stage 9 — write the investigation finding

SOC FINDING The suspicious email contained a URL that was subsequently clicked by the recipient. URL-click telemetry established the interaction time and provided an anchor for post-click analysis. Endpoint network, process and file telemetry was reviewed around the click window to determine whether the browser interaction resulted in additional activity. The final verdict must distinguish between the fact that a click occurred and evidence that the click caused credential exposure, file execution or endpoint compromise.

Lesson 43 key takeaways

A reported click changes the scope of a phishing investigation.
Preserve the URL and NetworkMessageId from email telemetry.
Use URL-click telemetry to establish the account and click timestamp where available.
Anchor post-click investigation around the interaction time.
Follow browser network activity and possible redirects.
Check for files created after the interaction.
Review process activity for unexpected browser child processes.
No downloaded payload does not eliminate credential-phishing risk.
Do not equate a click automatically with compromise.
State separately what was observed and what the evidence proves happened afterwards.

Module 5 — Email & Phishing: From Message to Compromise

Lesson 43 followed a phishing link from the message into click and endpoint evidence. In Lesson 44, the attack path changes again: the suspicious content arrives as an attachment that reaches the inbox.

Next: Lesson 44 — The Attachment Reached the Inbox

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 5: Email & Phishing: From Message to Compromise

Follow phishing evidence from message delivery through clicks, credential exposure, mailbox activity and campaign scope.

← Previous lesson

Lesson 42 — The Display Name Was Familiar — The Domain Wasn't Separate visual trust from sender identity.

✅ Current lesson

Lesson 43 — The Link Was Clicked Follow a message into URL-click and endpoint evidence.

Next lesson →

Lesson 44 — The Attachment Reached the Inbox Trace attachment delivery and execution.

Investigating phishing URL clicks in Microsoft Defender XDR

Lesson 43 of the Agent Foskett SOC Analyst Academy teaches SOC analysts how to correlate EmailUrlInfo and UrlClickEvents with DeviceNetworkEvents, DeviceProcessEvents and DeviceFileEvents after a suspicious email link is clicked.

Follow a phishing link from email to endpoint with KQL

Use Microsoft Defender XDR Advanced Hunting to establish the click timestamp, investigate browser network activity, identify redirects, review post-click processes and files, and distinguish user interaction from evidence of compromise.